Apostila Compass - Fundamentos de Gerenciamento de Projetos

FUNDAMENTOS DE GERENCIAMENTO DE PROJETOS
Sumrio
Conceitos de Gerenciamento de Projetos......................................................................................................5

O QUE UM PROJETO?.............................................................................7 GERENCIAMENTO DE PROJETOS............................................................10
Processos de Iniciao........................................................................................................21 Processo de Planejamento................................................................................................28 Execuo, Monitoramento e Controle do Projeto......................................................................................................83 RELATRIO DE STATUS DO PROJETO....................................................94 Projeto...........................................................................................................94 Data...............................................................................................................94 Nmero..........................................................................................................94 Principais Entregas realizadas...................................................................94 % completo do projeto REALIZADO...........................................................94 % completo do projeto PLANEJADO..........................................................94 Valor Planejado (PV)....................................................................................94 Custo Real (AC)............................................................................................94 Valor Agregado (EV)....................................................................................94 Oramento do Projeto (BAC)......................................................................94 Data de Trmino prevista............................................................................94
Copyright Compass International Knowledge Center
Indicadores ..................................................................................................94 Anterior.........................................................................................................94 Atual..............................................................................................................94 Sinalizador....................................................................................................94 Variao de Custo (CV)................................................................................94 Variao de Prazo (SV)................................................................................94 Performance de Custo (CPI)........................................................................94 Performance de Prazo (SPI) .......................................................................94 Estimativa de Custo no Trmino (EAC)c....................................................94 Estimativa de Prazo no Trmino (EAC)t.....................................................94 Aes Corretivas..........................................................................................94 FORMULRIO DE SOLICITAO DE MUDANA NO PROJETO.............98 Projeto...........................................................................................................98 Data da Solicitao......................................................................................98 Nmero..........................................................................................................98 Solicitante.....................................................................................................98 Descrio da Mudana................................................................................98 Justificava para a Mudana.........................................................................98 Impactos no projeto e medidas para mitigao dos impactos................98 1. Escopo......................................................................................................98 1.1. ...............................................................................................................98 2. Tempo........................................................................................................98 2.1. ...............................................................................................................98 3. Custo.........................................................................................................98 3.1. ...............................................................................................................98 4. Qualidade..................................................................................................98
4.1. ...............................................................................................................98 5. Riscos do projeto.....................................................................................98 5.1. ...............................................................................................................98 Aprovador.....................................................................................................98 Data da Aprovao.......................................................................................98 Encerramento do Projeto.........................................................................................................103
Conceitos de Gerenciamento de Projetos

Ser a atual preocupao das empresas com o tema gesto de projetos um mero modismo? Alguns indicadores observados no contexto empresarial atual nos levam a crer que no. Conseqncia de uma volatilidade cada vez mais acentuada de mercados que aparecem e desaparecem da noite para o dia, a instabilidade econmica, caracterstica no passado de perodos sazonais, hoje uma realidade com a qual as organizaes precisam conviver. Este cenrio torna a competio cada vez mais acirrada e agressiva e faz com que os riscos incorporados aos negcios adquiram dimenses desproporcionais. Neste contexto, os recursos consumidos pelas empresas para realizar suas estratgias tornam-se cada vez mais importantes e precisam ser geridos com o mximo de eficincia. Instrumento indispensvel para o crescimento e sobrevivncia no voltil mercado atual, a capacidade de inovao outro importante fator crtico de sucesso. Inovar, diferentemente de apenas inventar, pressupe um processo estruturado de estudos tcnicos e financeiros at a transformao em aplicaes que traro resultados efetivos para a organizao geradora da inovao. Isto , inovao no meio empresarial transformao de idias em negcios.
O papel dos projetos neste contexto

Se analisarmos como as organizaes estruturam seus planos estratgicos, veremos que as aes ou iniciativas estratgicas que realizam seus objetivos estratgicos de crescimento so de fato materializadas atravs da execuo de projetos. O lanamento de novos produtos, a expanso para uma nova rea de negcios, mudanas estruturais, como o aumento de capacidade de produo ou da produtividade de algum setor da organizao devem ser conduzidas por meio de projetos.
Realizao de objetivos estratgicos atravs de projetos
Portanto, pode-se afirmar que o alcance dos objetivos estratgicos de uma organizao ocorre na medida do sucesso de seus projetos estratgicos. Ou seja, a eficcia de um planejamento estratgico organizacional est diretamente relacionada eficcia de seus projetos estratgicos. Porm, os resultados dos projetos que so realizados atualmente no so nada satisfatrios. Segundo pesquisa de 2004 publicada pelo Standish Group, instituto de pesquisas americano, apenas 34% dos projetos realizados foram considerados concludos com sucesso. Apesar de o conceito de sucesso em projetos no ser simples de ser definido, como veremos posteriormente, fica evidente a necessidade de melhoria no desempenho dos projetos conduzidos nas organizaes. Algumas perguntas que dificilmente encontraro respostas do uma idia da dimenso de recursos envolvidos:
Quantos projetos terminam fora do prazo? Quanto custa o atraso? Quantos projetos terminam acima do oramento? Quanto gasto a mais? Quantos projetos terminam sem completar o escopo? Que perdas so geradas pelo que deixa de ser realizado por projetos que no completam seus escopos? Qual o custo da no-conformidade? Qual o custo do cliente insatisfeito? Da perda de um cliente?
Pode-se concluir, ento, que a preocupao com o gerenciamento de projetos de forma metodolgica para a obteno de resultados estratgicos no um mero modismo ou onda passageira, mas uma necessidade real.
Project Management Institute - PMI

A busca da melhoria no desempenho de projetos teve um marco importante no final da dcada de 60. Neste ano foi criado o Project Management Institute. Instituio no governamental sem fins lucrativos situada na Pensilvnia, Estados Unidos, e que tem como misso fomentar a atividade de gerenciamento de projetos. O PMI tem abrangncia internacional e est organizado em mais de 200 sucursais chamadas de Chapters, distribudos em 125 pases. Atualmente existem cerca de 300.000 afiliados que tm acesso, atravs do site do PMI, a documentos, artigos e informaes sobre gerenciamento de projetos. A filiao pode ser feita, mediante o pagamento de uma taxa no site: www.pmi.org.
Guia PMBOK1 Project Management Body Of Knowledge

O PMI tem, tambm, a responsabilidade de publicar o Conjunto de Conhecimentos em Gerenciamento de Projetos que est em sua quarta edio, lanada em 2008. O Guia PMBOK, como conhecido, um guia de referncia bsica de contedo para profissionais de gerenciamento de projetos e contribui para a divulgao de uma terminologia e vocabulrio, comuns ao ambiente de projetos. construdo a partir da contribuio de descries de BOAS PRTICAS resultantes de experincias
1
PMBOK marca registrada de Project Management Institute.
de profissionais do mundo inteiro que as encaminham a comits responsveis por consolid-las em um documento estruturado. O guia est organizado em 9 reas de conhecimento: gerenciamento do escopo, gerenciamento do tempo, gerenciamento dos custos, gerenciamento da qualidade, gerenciamento dos recursos humanos, gerenciamento das comunicaes, gerenciamento dos riscos, gerenciamento das aquisies e gerenciamento da integrao do projeto, que sero abordadas posteriormente e cujo domnio considerado essencial para um bom gerenciamento de projetos.
Certificao PMP2 Project Management Professional

Outra atribuio do PMI certificar profissionais em gerenciamento de projetos. A certificao PMP concedida aos aprovados em um teste de 200 questes de mltipla escolha que procura avaliar o candidato nas reas de conhecimento do Guia PMBOK e em situaes prticas do dia-a-dia do gerenciamento de projetos. Para habilitar-se a fazer a prova necessrio comprovar 4.500 horas de experincia prtica em projetos, para quem possui graduao superior, e 7.500 horas para profissionais de nvel tcnico e pagar uma taxa de 525 dlares americanos para no afiliados ao PMI, e 425 para afiliados. Alm da certificao PMP o PMI tambm tem outras certificaes relacionadas ao tema gerenciamento de projetos, a saber: PgMP (Program Management Professional) demonstra conhecimento e experincia na conduo de programas. PMI-RMP (Risk Management Professional) demonstra conhecimento e experincia em gerenciamento de riscos de projetos. PMI-SP (Schedulling Professional) demonstra conhecimento e experincia em gerenciamento de cronogramas de projetos. CAPM (Certified Associate of Project Management) demonstra conhecimento em gerenciamento de projetos. Para profissionais que ainda no tm tempo de experincia suficiente para serem certificados como PMP.
O QUE UM PROJETO?
O senso geral utiliza o termo projeto para referir-se a atividades da vida cotidiana tais como: projeto de vida; uma inteno futura; desenhos, plantas, com instrues para construo ou montagem de estruturas, enfim, aplicaes das mais diversas e livres. Para este estudo, vamos considerar o conceito de projeto, de forma tecnicamente restrita, como: o todo de um esforo, ou empreendimento, temporrio para criar um
PMP, PgMP, PMI-RMP, PMI-SP e CAPM so marcas registradas de Project Management Institute.
produto, servio ou resultado exclusivo. Envolve todo o processo desde a identificao da demanda at a entrega do produto, servio ou resultado final. Conceituar projeto tecnicamente importante para que possamos reconhec-los no contexto do dia-a-dia, distinguindo-os das rotinas operacionais e aplicarmos tcnicas de gerenciamento especficas para obter melhores resultados. O Guia PMBOK define projeto como um esforo temporrio para criar um produto, servio ou resultado exclusivo. Temporrio Significa que, comparado com operaes de rotina, um projeto tem incio e fim definidos antes do incio de sua execuo.
PLANO
Obj t
D0
Janela de TEMPO
DDeadline
Produtos, Servios ou Resultados exclusivos Mesmo que haja algumas semelhanas, os resultados dos projetos apresentam diferenas. Prdios com o mesmo nmero de andares, mesmo desenho de planta, executados pela mesma construtora, etc., tero resultados nicos, uma vez que seus processos de construo sero diferentes, suas orientaes em relao ao sol sero diferentes, suas fundaes tero dimenses diferentes, pois estaro em posies de terreno diferentes, etc.
H D I P Q R S
A rvore de deciso, ao lado, representa o processo de escolhas de alternativas em um projeto. A ponderao de prs e contras em cada ponto de deciso um processo de TRADE-OFF (conceito da economia no qual nenhuma alternativa possui apenas vantagens nem apenas desvantagens)
T B E K A L F C M J U V X Y W Z A1 N G O B1 C1 D1 E1
Probabilstico (No Determinstico) Tem Risco (incerteza) No senso comum, a palavra projeto carrega a idia de plano para futuro, previso. Possui sempre uma carga de incerteza de que acontecer o
esperado, ou planejado. Esta caracterstica torna o papel do gerenciamento do projeto mais relevante, pois atua exatamente para reduzir a taxa de desvio entre planejado e executado.
o fator crtico de sucesso de um projeto reside na capacidade de realizao de atividades atravs das pessoas. Determinados tipos de operaes so intensivos em mquinas ou equipamentos, mas em projetos os ativos principais so, de fato, as pessoas que o realizam. Elaborao Progressiva (em Etapas Fases) As caractersticas anteriormente apresentadas conduzem a esta terceira caracterstica de qualquer projeto: no se conhece cabalmente o que ser o projeto assim que o mesmo se inicia. Com o passar do tempo, o conhecimento que se tem dele aumenta. Para lidar com essa caracterstica, que traz incerteza e indefinio para qualquer projeto, costuma-se utilizar o recurso prtico de segment-lo em etapas ou fases para melhorar a capacidade de gerenciamento e aumentar as chances de sucesso do projeto. O princpio analtico de que partes menores so mais facilmente gerenciveis vale muito em projetos. A diviso das fases que marcaro o processo do projeto deve ser feita de acordo com a melhor convenincia do gerenciamento e ir variar de acordo com a caracterstica especfica de cada projeto. Recursos limitados Nas rotinas do dia-a-dia, os recursos so renovados para mant-los em funcionamento permanente. Em um projeto os recursos financeiros e humanos tm limites definidos pelo tempo de sua durao, pelo escopo e pela qualidade do resultado esperado. O conceito de limitao pressupe
quantificao e diferente do conceito de escassez, pois recursos escassos so insuficientes para alcanar os resultados planejados.
Precisa de Administrao Especfica As tcnicas de gesto operacional no so suficientes para dar conta das dificuldades prprias dos projetos. As caractersticas dos projetos tornam as aes de planejamento, programao e controle mais crticas e complexas, exigindo, portanto, tcnicas e ferramentas especficas. Outra maneira de definir o conceito de projetos atravs da comparao com as caractersticas das operaes rotineiras.
Projetos x Operaes
Decises Irreversveis x Decises Reversveis Projetos, por sua natureza temporria, existem durante uma janela de tempo limitada. Isso torna as decises tomadas no mbito do projeto muito mais crticas, pois, na maioria das vezes, no h tempo suficiente para reverter suas conseqncias. Variveis Exgenas x Variveis Endgenas Na operao os fatores que influenciam mais fortemente seu desempenho so oriundos de dentro do ambiente operacional, e, portanto mais passveis de controle. O projeto sofre influncia intensiva de fatores ou agentes externos equipe do projeto. Fluxo de Caixa Negativo x Fluxo de Caixa Positivo A menos que um ambiente operacional esteja passando por uma crise financeira, o montante das receitas geradas supera o de despesas no perodo de tempo do ciclo de operao. Projetos so empreendimentos que geram despesas que s podero ser cobertas quando seus produtos criados gerarem os resultados esperados e conseqentemente as receitas. Mesmo que de forma indireta, como no caso dos projetos de modificaes estruturais desenvolvidos dentro das empresas. Por essa razo torna-se quase que na totalidade dos casos obrigatria a reduo do perodo de existncia do projeto (ciclo de vida).
GERENCIAMENTO DE PROJETOS
Segundo o Guia PMBOK, gerenciamento de projetos a aplicao de conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. O grande desafio comea em ser capaz de gerenciar e no apenas executar ou, como comum ouvir-se, tocar o projeto. O gerenciamento, que queremos tratar aqui, pressupe um processo estruturado e, preferencialmente, com a aplicao de um mtodo, ou metodologia. O gerenciamento de projetos implica em levantar necessidades, e identificar prioridades entre ESCOPO, TEMPO e CUSTO.
10
Priorizar escopo, tempo e custo significa que h uma dificuldade intrnseca de projetos em atender plena e simultaneamente as trs dimenses principais de um projeto, uma vez que projetos so carregados de incertezas geradoras de desvios. Cada projeto tem uma relao de prioridades diferente destas variveis. Em um determinado projeto o vetor prioritrio, ou FATOR CRTICO DE SUCESSO, (tambm conhecido como DRIVER do projeto, ou seja, fator direcionador) ser o custo, ou seja, todas as outras variveis devero ser subordinadas ao cumprimento dos objetivos e metas de custo do projeto. Em outro, poder ser o tempo, significando que as outras variveis sero dimensionadas para que o projeto cumpra o prazo previsto. Projetos de um mesmo tipo, a construo de uma casa, por exemplo, podem ter prioridades diferentes. Vamos analisar trs casos como exemplo. Primeiro caso: o cliente precisa se mudar at uma data especfica porque ter que entregar o apartamento que ocupa no momento. A prioridade do projeto ser o tempo. provvel que prximo da data marcada para a mudana do cliente, se o projeto estiver atrasado, seja necessrio aumentar o custo para cumprir o prazo. Talvez o escopo tenha que ser suprimido em alguns elementos que no sejam essenciais mudana do cliente, pois o prazo o vetor menos flexvel. Segundo caso: o cliente do projeto possui um montante determinado de recursos financeiros e precisa construir uma casa que se encaixe neste valor. Como nesse caso a prioridade o custo, provvel que o cronograma tenha que ser estendido em funo do limite de oramento. Da mesma forma o escopo, se houver necessidade, tenha que ser cortado, naquilo que no impea o funcionamento bsico da residncia. Terceiro caso: o cliente do projeto deseja uma casa com especificaes tais como: nmero de quartos, banheiros, salas, salo de jogos, piscina com caractersticas especficas, etc. Nesse caso, o cronograma, assim como o oramento, na dinmica incerta do projeto, provavelmente, tenha que ser aumentado para cumprir os requisitos de escopo. Porm, estabelecer prioridades no significa descuido ou abandono das variveis que no so a prioritria, pelo contrrio. O bom desempenho no conjunto das variveis de restrio do projeto aumenta a probabilidade de sucesso no vetor prioritrio e consequentemente do projeto. A prioridade de objetivos, porm, no facilmente identificvel. O primeiro impulso dos principais interessados desejar que todas as demandas, variveis, objetivos, ou vetores, sejam atendidos igualmente. O que , quase sempre, invivel. Dada a natureza da atividade projeto, extremamente voltil e carregada de incertezas. O responsvel pelo projeto deve procurar identificar o vetor prioritrio lanando mo de sequncias de perguntas nas quais sejam postas hipteses de situaes limites entre pares de vetores para que possa, gradativamente, identificar as prioridades. Por exemplo, se numa situao limite, para que o escopo seja completado for necessria uma extenso do prazo, e isto for aceitvel, um indcio de que escopo tem prioridade sobre prazo. 11
Os requisitos, portanto, no so simplesmente passados pelo demandante ao gerente do projeto. necessria uma construo conjunta, na qual o gerente do projeto far sugestes, alertar acerca de impossibilidades tcnicas, mostrar conseqncias de opes escolhidas pelo demandante, etc. A descrio deste modelo de relacionamento fica melhor representada pela expresso inglesa: COMAKERSHIP (Processo de relacionamento de parceria para elaborao conjunta). Deste relacionamento desdobra-se, tambm, a equao da qualidade do servio. Na qual a qualidade percebida est diretamente relacionada qualidade esperada pelo cliente e a qualidade daquilo que entregue, ou seja, ofertado. A qualidade esperada reflete a expectativa do cliente que formada por diversos fatores relacionados ao perfil racional e emocional do cliente.
Dependem do background cultural e educacional do cliente, das suas experincias anteriores com projetos, e com projetos de mesma natureza, do ambiente sob o qual ele est vivendo no momento do relacionamento com o projeto, enfim de uma srie de fatores que compem um quadro de expectativa sob a qual o executor do projeto, o gestor do projeto, no tem domnio. Tem, apenas, influncia desde o momento em que comea o relacionamento pessoal para a conduo do projeto. Esta equao confirma o carter subjetivo que permeia toda relao de consumo, seja de um produto, seja de prestao de um servio, no caso, da realizao de um projeto. No h como extrair totalmente este ingrediente subjetivo. Portanto, mesmo que utilizemos mtodos para traduzir requerimentos e desejos e expectativas em fatos e dados sempre haver uma parcela considervel de subjetividade. A interdependncia entre as variveis significa que quando h a alterao dimensional de uma delas implica na modificao de pelo menos mais uma delas. E, uma vez definidas as dimenses adequadas de escopo, tempo e custo do projeto, a qualidade do projeto ser a medida de cumprimento destas dimenses dentro dos limites de tolerncia dos demandantes do projeto.
Quando um projeto tem sucesso?

A avaliao do sucesso de um projeto deve ser vista por duas perspectivas bem distintas: do processo do projeto e do produto do projeto.
Perspectivas de sucesso de um projeto
Na perspectiva do processo de projeto so observados os aspectos de eficincia do processo. Ou seja, se os requisitos de conformidade do processo do projeto foram atendidos. Esta dimenso est ligada organizao executora do projeto. As perdas de eventuais e desvios nos planos de projeto afetaro diretamente o desempenho operacional da organizao executora. J na perspectiva do produto do projeto so observados os aspectos da eficcia. Isto , se o resultado do projeto foi entregue dentro dos requisitos de conformidade do cliente. A avaliao feita pelo cliente do projeto na sua perspectiva. Portanto, um projeto pode ser eficiente e no ser eficaz e vice-versa. Eficcia sem eficincia, ou seja, sucesso apenas para o cliente e processo de projeto com nveis de desvio elevados, estar gerando, em mdio ou longo prazo, desequilbrio de consumo de recursos da organizao executora do projeto. Eficincia sem eficcia resultar em insatisfao do cliente, porque o produto do projeto no atender seus requisitos.
Projeto planejado e gerenciado x projeto tocado

Ao receber o encargo de realizar um empreendimento, o impulso natural de todos ns, seres humanos, comear a executar as atividades que nos parecem necessrias, imediatamente. Vencer este impulso e seguir um processo estruturado ou metodolgico de concepo e elaborao de um plano para s ento execut-lo requer um comportamento programado para tal. A transformao de um mero tocador de projetos para um verdadeiro gerente de projetos profissional tem como premissa bsica esse perfil de trabalho. Na execuo
13
sem planejamento a probabilidade de re-trabalho e desperdcio de recursos maior gerando, em geral, a extenso do tempo e o estouro dos custos. A presuno de profissionais de gerenciamento de projetos, que adotam boas prticas, de que o tempo dedicado ao planejamento seja inversamente proporcional ao acrscimo de tempo de execuo por excesso de retrabalho, ociosidade, etc.
Projeto planejado e gerenciado X Projeto tocado
O Gerente do Projeto
Em primeiro lugar, vale ressaltar que gerente do projeto, aqui, no o nome de um ttulo formal de cargo administrativo. a designao do responsvel pelo gerenciamento do projeto. Responsvel pelo seu sucesso ou fracasso, mesmo quando lhe forem impostas condies absolutamente desfavorveis. Hoje, h profissionais cujo cargo Gerente de Projetos. Significa que este profissional tem como misso institucional gerenciar projetos. comum, porm, que profissionais que ocupam os mais diversos cargos sejam designados, em determinado momento de suas vidas profissionais, como responsveis por um projeto. Neste momento o profissional passa a ser o gerente deste projeto. So atribuies comuns ao gerente do projeto: Entrega do produto do projeto Formao e construo da equipe do projeto Elaborao dos planos do projeto Direo da execuo do projeto Monitoramento e controle do projeto Medio da performance do projeto Relacionamento com os stakeholders do projeto Determinao de aes corretivas e preventivas Gerenciamento do escopo, tempo, custos, qualidade, recursos humanos, riscos, comunicaes e aquisies do projeto Promoo e manuteno da integrao e coeso dos componentes do projeto
14
O Gerente do Projeto deve ter autoridade suficiente para realizar suas atribuies. Esta autoridade, no mbito do projeto, concedida pelo patrocinador do projeto. Sem autoridade suficiente o Gerente do Projeto ter dificuldades em incorporar os recursos necessrios ao cumprimento dos objetivos do projeto.
Perfil e competncias do Gerente do Projeto

Historicamente o Gerente do Projeto vem sendo escolhido para a funo de gerenciar o projeto por suas competncias tecnolgicas da rea de conhecimento no qual o projeto ser conduzido. Nos projetos de engenharia, o gerente do projeto escolhido naturalmente por ser engenheiro, nos de tecnologia da informao, por ser analista de sistemas, e assim por diante. Pressionado pela exigncia por resultados, vem ocorrendo uma modificao nestes requisitos. Pode-se considerar que at da metade dos anos 80, exigia-se do gerente do projeto em torno de 20% de competncias comportamentais, ou gerenciais, e 80% de competncias tcnicas ou tecnolgicas especialistas. Hoje, a relao considera apropriada para um melhor desempenho das funes de gerenciamento de projetos gira em torno de 20% de competncias tcnicas e tecnolgicas e 80% de competncias comportamentais. Esse processo de mudana resulta, tambm, da constatao de que os fatores que contribuem mais significativamente para os fracassos dos projetos so de ordem gerencial e no tcnica.
Processos de Gerenciamento de Projetos

Como processo um conjunto de atividades inter-relacionadas capazes de gerar resultados, o gerenciamento de projetos pode ser estruturado em processos especficos. Na verdade, os efetivos ganhos de eficincia na realizao de projetos ocorrem quando projetos so gerenciados seguindo processos. O PMI, no Guia PMBOK, define cinco grupos de processos: Iniciao Planejamento Execuo Monitoramento e Controle Encerramento Cada grupo de processos contm um conjunto de processos capazes de gerar os resultados esperados do projeto. O Guia PMBOK relaciona os processos utilizados por profissionais e organizaes no mundo inteiro para gerenciar seus projetos. Estes processos por terem demonstrado sua efetividade so considerados BOAS PRTICAS. Cada organizao, porm, dever identificar dentre os processos, ou boas prticas, disponveis, quais sero adequados aos seus projetos especificamente.
15
Grupos de Processos de Gerenciamento de Projetos - Fonte: Guia PMBOK, 2008
Os grupos de processos no so fases do projeto. Processos so genricos, ou seja, aplicam-se a todo e qualquer projeto e repetem-se ao longo do ciclo de vida do projeto. Por exemplo, o processo de iniciao ocorre quando o projeto autorizado e quando cada fase do projeto tem sua autorizao de incio. O processo de planejamento o pensar no que ser feito em cada fase. Seu principal objetivo elaborar o plano de gerenciamento do projeto. Em cada fase do projeto, este plano deve ser consultado e executado no processo de execuo. Os processos de encerramento ocorrero toda vez que uma parte do projeto for concluda, ou seja, realizada uma entrega. O processo de monitoramento e controle ocorre desde que as primeiras aes do projeto so realizadas at o seu trmino. Os grupos de processos de gerenciamento do projeto apresentam interaes entre si ao longo do ciclo de vida do projeto.
Ciclo de Vida e Processos de Gerenciamento de Projetos

Esquematicamente, podemos identificar momentos do projeto nos quais os processos ocorrem com mais intensidade, ou tm entregas marcantes. Por exemplo: o processo de iniciao, quando ocorre no incio do projeto, gera o documento de abertura do projeto (Project Charter, ou Termo de Abertura), o processo de planejamento ocorre mais intensamente quando est se preparando o Plano de gerenciamento do projeto, ou Plano de Gerenciamento do Projeto que ser a base de referncia (baseline) para o processo de execuo das atividades do projeto. O ciclo de vida de cada projeto identificado de acordo com suas fases especficas, ou seja, um projeto de construo de uma casa ter fases prprias de projetos de construo de casas, e seu ciclo de vida ser descrito tipicamente pelas fases: fundaes, estrutura, alvenaria, instalaes, telhado, acabamento e limpeza. J um projeto de desenvolvimento de um sistema de tecnologia da informao poder ter seu ciclo de vida tpico como: levantamento de requisitos, anlise, programao, instalao e homologao.
16
Os processos de gerenciamento tm como finalidade gerenciar (planejando, monitorando e controlando) como sero realizadas as atividades necessrias concretizao do produto do projeto. Em cada fase especfica do projeto, podero ser rodados os processos de gerenciamento. Esta distino til para uma melhor definio da natureza do trabalho que efetivamente estar sendo realizado a cada momento, se de gerenciamento ou de elaborao do produto do projeto.
Desenvolvimento do Projeto
O modelo a seguir representa o desenvolvimento de um projeto desde a identificao da necessidade de realizao do projeto, a partir de um problema ou do aproveitamento de uma oportunidade. As setas descrevem as interaes entre os processos e a lgica de elaborao progressiva com o carregamento de dados e informaes nos componentes do plano que ser executado, monitorado, controlado e encerrado.
17
18
19
reas de Conhecimento Integrao
Escopo
Tempo
Custos
Qualidade
Recursos Humanos
Comunicaes
Riscos
Aquisies
Grupos de Processos de Gerenciamento de Projetos (Guia PMBOK, 2008) Monitoramento Iniciao Planejamento Execuo Encerramento e Controle Desenvolver o Desenvolver o Orientar e Monitorar e Encerrar o Termo de Plano de Gerenciar a Controlar o Projeto ou Fase Abertura do Gerenciamento Execuo do Trabalho do Projeto do Projeto Projeto Projeto Controle Integrado de Mudanas Coletar Verificar o Requisitos Escopo Definir o Controlar o Escopo Escopo Criar EAP Controlar o Definir as Cronograma Atividades Seqenciar as Atividades Estimar os Recursos Estimar a Durao das Atividades Desenvolver o Cronograma Estimar os Controlar os Custos Custos Definir o Oramento Realizar a Planejar a Realizar o Qualidade Garantia da Controle da Qualidade Qualidade Desenvolver o Mobilizar a Plano de Equipe do Projeto Recursos Desenvolver a Humanos Equipe do Projeto Gerenciar a Equipe do Projeto Distribuir as Identificar as Planejar as Reportar o Partes Comunicaes Informaes Desempenho Interessadas Gerenciar as Expectativas das Partes Interessadas Planejar o Monitorar e Gerenciamento Controlar os dos Riscos Riscos Identificar os Riscos Realizar a Anlise Qualitativa dos Riscos Realizar a Anlise Quantitativa dos Riscos Planejar Respostas aos Riscos Planejar as Conduzir as Administrar as Encerrar as Aquisies Aquisies Aquisies Aquisies
20
Processos de Iniciao
Uma vez tomada a deciso de realizar o projeto, necessrio constitu-lo formalmente. Segundo o Guia PMBOK, o grupo de processo iniciao o processo que define e autoriza o projeto ou uma fase projeto. O grupo de processo de iniciao do projeto composto por dois processos: desenvolver o termo de abertura do projeto e identificar stakeholders.
DESENVOLVER O TERMO DE ABERTURA DO PROJETO

O Termo de Abertura do Projeto (project charter), tem como misso principal autorizar formalmente a realizao do projeto. Define os principais elementos do projeto suficientes para indicar os objetivos, o porqu da realizao do projeto (justificativas), a contextualizao do projeto na organizao, enfim o que o projeto. Para cumprir sua misso essencial, um Termo de Abertura pode conter apenas informaes essenciais, tais como um nome para o projeto e uma breve descrio. Este seria um extremo de um Termo de Abertura de um projeto com o mnimo de informaes disponveis no momento de sua constituio formal (autorizao por quem de direito). No outro extremo poderamos ter um Termo de Abertura com o mximo de informaes capazes de descrever elementos integrantes do projeto que auxiliaro o entendimento do que representa o projeto. Um Termo de Abertura com muitas informaes permitir que, durante seu processo de autorizao (aprovao) este conjunto de informaes sejam validadas pelo patrocinador (sponsor - principal signatrio da autorizao) e pelo cliente do projeto. Aquele que dar o aceite formal no produto (resultado) do projeto. Nome ou Ttulo do Projeto Longe de ser uma mera formalidade, a denominao do projeto um elemento de comunicao que pode cumprir um papel importante na divulgao do projeto para a organizao executora e para stakeholders. Pode ser composto apenas com uma forma resumida de descrever o resultado principal do projeto, como: Desenvolvimento e Instalao de Sistema de Gesto Integrada ou utilizar um slogan que sirva de instrumento de marketing para o projeto. Associados ao nome podem ser desenvolvidos identidade visual, logomarcas e outros elementos de comunicao para o projeto.
21
Cliente do Projeto Indivduo que d o aceite formal no resultado (produto) do projeto. Pode no ser, e em geral no , o usurio final do produto. Tambm no , necessariamente, quem paga pelo projeto. O foco da identificao deste importante stakeholder o de garantir que o projeto no fique impedido de ser encerrado por indefinio de quem tenha autoridade e competncia formal para dar o de acordo formal na principal entrega do projeto. A boa prtica recomenda que se busque identificar o indivduo ao invs da designao de um setor, ou diretoria, ou at mesmo uma empresa, para evitar que caso haja uma mudana na estrutura de pessoal, isso gere impasses na entrega do produto do projeto e impea o encerramento formal do projeto. Gerente do Projeto O Termo de Abertura deve designar e atribuir autoridade formal ao responsvel pela realizao do projeto. Na prtica, o prprio gerente do projeto, j indicado conduz o desenvolvimento do documento a partir de informaes fornecidas pelos principais stakeholders do projeto. Patrocinador (Sponsor) O termo patrocinador d a conotao de que este stakeholder seja apenas quem prov recursos financeiros e libera recursos para o projeto, mas ele tem um papel muito mais abrangente. D suporte e cobertura poltica ao projeto, tem o poder de deciso quanto s prioridades do projeto e o principal agente autorizador de mudanas no projeto. Pode exercer, ao mesmo tempo, o papel de cliente. Um patrocinador forte (com poder na organizao) e atuante pode ser decisivo ao sucesso do projeto. Descrio do Projeto Apresentao sumria do projeto. Deve ser sucinta para permitir uma viso geral do que o projeto. Se forem necessrias mais informaes a recomendao que sejam postas em anexos a fim de que no torne o documento extenso. De modo geral, informaes em projetos devem ser postas de forma a serem entendidas o mais rpido possvel. Justificativa do Projeto (Problema/Oportunidade) Um projeto consome recursos, a cada dia, mais escassos, portanto o porqu de sua realizao deve ficar bem claro no documento que registra sua constituio. Um projeto cuja justificativa forte tende a ter mais apoio da organizao executora e consequentemente menos dificuldade em obter os recursos necessrios sua execuo. Se a organizao executora utiliza um processo de seleo e priorizao de projetos para tomar a deciso de executar ou no projetos, a princpio, as razes que justificam o empreendimento j devem ter sido apresentadas. Mas a justificativa para a realizao do projeto vai alm da deciso de execut-lo. Serve como fator de motivao para a equipe do projeto, como argumento em
22
negociaes com stakheolders e para o patrocinador defend-lo poltica e financeiramente. Uma boa justificativa para um projeto deve estar relacionada aos benefcios que ele trar para a organizao que podem ser tangveis ou intangveis, em forma de soluo de um problema ou do aproveitamento de uma oportunidade. Justificativas baseadas na soluo de problemas tendem a ser mais facilmente aceitas do que aquelas que propem o aproveitamento de oportunidades porque, em geral, o problema j existe e j est causando efeitos reais, enquanto que a oportunidade, por natureza, potencial, carrega mais risco. Neste campo a recomendao, tambm de objetividade e sntese. Se forem necessrios dados adicionais ou mais detalhados devem vir em anexos ao Termo de Abertura. Produto do Projeto O resultado principal que ser gerado pelo projeto deve ficar bem claro a fim de evitar expectativas alm da capacidade de realizao do projeto. O produto do projeto a principal entrega produzida pelo projeto. Pode ser um objeto, por exemplo, um projeto de construo de uma residncia. A residncia pronta para morar seria o produto do projeto. Um servio, que seria entregue por um projeto de consultoria. O produto gerado pelo projeto estaria materializado no relatrio com as recomendaes da consultoria. O produto de um projeto pode ser um estado modificado, que seria obtido pela execuo de um projeto de modificao de um layout de um ambiente de trabalho. Deve ser quantificvel. O produto do projeto deve ser identificado e tangibilizado de tal forma que, ao final, permita a verificao de que de fato foi entregue e a avaliao da adequao ao que foi proposto em seu incio. A indefinio do produto do projeto pode levar s partes interessadas no projeto criarem expectativas diferentes em relao quilo que o projeto efetivamente estaria configurado para entregar e causar conflitos, frustraes e prejuzos. Objetivos e Metas do Projeto O objetivo mais amplo do projeto, a inteno do projeto, seu requisito maior, suas prioridades, devem ser expressas em objetivos quantificveis que permitam sua verificao e avaliao do seu desempenho e seus resultados. Devem ser expressos no tempo verbal infinitivo: realizar, entregar, desenvolver. Se o objetivo de desempenho do projeto descreve o qu o projeto far, a meta descreve o quanto. Ou seja, a meta a quantificao de um objetivo. A medida do desempenho do projeto. Pode haver mais de uma meta para um mesmo objetivo, mas no deve haver objetivo que no comporte a atribuio de pelo menos uma meta. Para o objetivo principal do projeto, relacionado principal entrega, recomendvel que se estabeleam metas nas trs principais dimenses do projeto: escopo, tempo
23
e custo. A determinao de objetivos e metas pode seguir a hierarquia das fases e entregas do projeto. No Termo de Abertura, porm, dado que o projeto est no processo de iniciao, os objetivos tendem a ficar em mbito mais geral, sendo, posteriormente, detalhados. Metas devem refletir os compromissos assumidos pelo projeto, portanto, podem ser referenciados a elementos ainda no definidos no momento da redao do Termo de Abertura, mas que sero elaborados no planejamento do projeto. Por exemplo: meta de no ultrapassar o oramento do projeto. Meta de no ultrapassar o cronograma aprovado. Metas relacionadas ao escopo podem vincular necessidades postas na Declarao do Trabalho (Statement Of Work SOW - documento que formula as necessidades postas ao projeto emitido pelos demandantes do projeto), que se tornaro especificaes de escopo. Por exemplo, no projeto de uma escola: nmero de salas de aula, nmero de laboratrios, etc. As metas sero o referencial de comparao para a avaliao do projeto ao seu trmino. Mediro, portanto, seu desempenho e seu sucesso. Estimativa de Custos A finalidade de elaborar uma estimativa de custos ainda no processo de iniciao tentar dimensionar em ordem de grandeza os custos gerais do projeto. Pode ser uma forma de confirmar uma faixa de valor que tenha sido enunciada em um estudo de viabilidade financeira, quando da deciso de realizar ou no o projeto, ou de dar a primeira idia do quanto o projeto poder custar. Neste caso, poder resultar na deciso de no continuar com a realizao do projeto. sempre importante lembrar que, seguindo um princpio geral da administrao, quanto mais cedo, mais prximo da origem, tomar-se a deciso de interromper um processo que no esteja conforme, mais econmica ser esta deciso para a organizao. A idia de validao da viabilidade um pressuposto que permeia todo o processo de iniciao do projeto. Durante o processo de iniciao do projeto deve-se procurar confirmar ou no a deciso de realizao do projeto. Por conveno, que pode variar de acordo com cada organizao, a expectativa de preciso desta estimativa de -50% a +100% do oramento final que ser apurado no processo de planejamento do projeto. A consulta a dados histricos de projetos anteriores semelhantes um recurso de apoio no processo de estimativa de custos do projeto. Porm, se a base histrica no possuir referncias semelhantes, pode-se solicitar apoio a um fornecedor que as tenha ou que possa elaborar uma estimativa. Alm do apoio neste momento, este fornecedor figurar como potencial executor de partes do projeto, no caso de dificuldades da organizao executora. Funciona, portanto como mitigador de riscos.
24
Estimativa de Prazo Infelizmente, a maioria dos projetos conduzidos hoje em dia, no so iniciados a partir de um planejamento, mas de uma reao a uma necessidade, portanto os prazos dos projeto so estabelecidos, e no estimados. O deadline, ou prazo de trmino do projeto j faz parte da demanda. Dessa forma, pode ser classificado como uma restrio imposta. Esta imposio influenciar o modelo de programao do cronograma do projeto no processo de planejamento que ter que ser feito para trs. Ou seja, a partir da data final estabelecida, programar as etapas do projeto. No caso de no haver esta imposio, o prazo pode ser estimado considerando-se referncias histricas de projetos semelhantes, como recomendado para custos. Autorizao Salvo regimentos organizacionais especficos, o principal stakeholder autorizador do projeto o patrocinador (sponsor). No caso de outros membros da organizao executora participarem da autorizao, suas assinaturas sero necessrias aprovao do Termo de Abertura do Projeto. O processo de aprovao do Termo de Abertura pode consumir um tempo considervel em idas e vindas para anlises e avaliaes, porm importante ressaltar que um projeto no deve ser autorizado com dvidas quanto s suas finalidades. Por outro lado, altamente recomendvel que no se comece a realizar, ou seja, tomar decises ou consumir recursos por conta do projeto, sem que o processo de autorizao formal esteja concludo.
STAKEHOLDERS (Partes Interessadas) DO PROJETO

Segundo o dicionrio Random House: detentores (holders) da aposta (stake). Partes interessadas a traduo mais encontrada para essa palavra no contexto de gerenciamento de projetos. Significa: todo indivduo, entidade, enfim qualquer pessoa fsica ou jurdica que de alguma forma tenha relacionamento, seja atingida ou impactada pelo projeto. Pode influenciar ou ser influenciada pelo projeto. No decorrer do projeto ou mesmo aps seu encerramento. A equipe de gerenciamento do projeto tem que identificar os stakeholders, partes interessadas tanto internas quanto externas organizao executora de maneira a determinar os requisitos e expectativas dessas partes. Uma vez identificadas, uma anlise deve ser feita para se determinar estratgias de gerenciamento dessas partes interessadas. As etapas envolvidas em uma anlise de partes interessadas so: Identificao de partes interessadas: desenvolver uma lista com nomes dos interessados chaves do projeto, sua funo, rgo ou empresa. Em alguns casos, podem ser identificados e listados grupos de interessados que tenham um mesmo perfil ou participao no projeto.
25
Classificao de partes interessadas: cada interessado da lista identificado por um cdigo (por exemplo, por letras maisculas) e feita uma avaliao em relao a seu poder de influenciar o projeto e seu interesse. Alm disso, avalia-se se o interesse positivo ou negativo. Elaborao de estratgia: para cada interessado ou grupo de interessados so desenvolvidas estratgias de relacionamento e comunicao.
O grfico abaixo apresenta um exemplo de classificao de partes interessadas que leva em conta o poder e o interesse de cada interessado ou grupo de interessados.
Anlise dos Stakeholders (Partes Interessadas do Projeto)
A informao resultante da anlise pode ser consolidada em um registro de partes interessadas (quadro na prxima pgina). Esse registro primeiramente elaborado no incio do projeto e deve ser mantido atualizado durante todo o ciclo de vida do projeto. Certas informaes relacionadas a uma ou mais das partes interessadas podem ser muito sensveis para serem includas no registro de partes de interessadas que ser tornado pblico como um documento do projeto. A equipe de gerenciamento de projeto deve avaliar cada caso e decidir que nvel de detalhe ser includo no registro e que informao merece divulgao restrita. Em razo dos stakeholders influenciarem positiva ou negativamente o projeto e, consequentemente, seus objetivos, eles so uma fonte primria de riscos ao projeto.
26
Figura 1 - Registro de Partes Interessadas
Registro dos Stakeholders (Partes Interessadas do Projeto)
Concluso do processo de iniciao do projeto Como foi visto, no processo de iniciao so coletadas informaes preliminares e levantadas questes gerais relacionadas capacidade de realizao do projeto. Considera-se que na iniciao faz-se um planejamento de alto nvel, um planejamento macro, que define as linhas gerais do projeto capazes de fornecer o mximo de subsdios para o patrocinador (sponsor) do projeto tomar a deciso de autorizar a continuidade do trabalho em um planejamento em baixo nvel que produzir um plano de gerenciamento do projeto detalhado. Dessa forma, elementos chave, tais como premissas e restries, devero ser revisados, refinados, detalhados e registrados na declarao do escopo do projeto.
27
Processo de Planejamento
A concluso do processo de iniciao indica que o projeto pode seguir em frente e pode-se, ento, investir tempo e recursos na elaborao do Plano de Gerenciamento do Projeto que a principal misso e resultado do processo de planejamento do projeto. Antes de tratarmos do trabalho que compe o processo de planejamento, importante refletirmos sobre algumas questes de ordem prtica que esto longe de serem triviais: por que planejar? Por que dedicar esforo e tempo planejando se j poderamos ir direto execuo do projeto? Qual o benefcio de planejar se as coisas no saem exatamente como planejado? Por que elaborar um plano se a probabilidade de haver mudanas muito alta? Isto no perda de tempo? No h uma resposta nica, mas um posicionamento. preciso considerar que o trabalho, esforo ou recursos, inclusive de tempo, sero menores do que os gastos com as conseqncias de uma execuo sem planejamento. O posicionamento a favor do planejamento vem da presuno de que o retrabalho ser menor se houver planejamento. Por re-trabalho entenda-se todo o trabalho que no poder ser aproveitado para o resultado do projeto. Sabemos que mesmo com o planejamento existe re-trabalho em projetos, dado que uma atividade probabilstica e carregada de incerteza. Porm, a dose de planejamento no pode ser prescrita de forma genrica, mas de acordo com cada caso especfico. Excesso de tempo e esforo dedicados ao planejamento pode representar mais perdas do que ganhos. O desafio, portanto, encontrar o ponto de equilbrio. O processo de planejamento do projeto segue uma sequncia lgica necessria elaborao do plano de gerenciamento do projeto.
Em primeiro lugar, define-se o escopo, que representa aquilo que ser feito pelo projeto, para em seguida dimensionar-se o tempo necessrio para esta realizao, que por sua vez, permitir a quantificao dos custos. Depois, viro as definies da qualidade, dos recursos humanos, da comunicao, dos riscos, enfim, dos demais parmetros do projeto. Apesar de seguir uma lgica de elaborao progressiva, o processo de planejamento interativo, pois seus parmetros so correlacionados, e ao mesmo tempo, iterativo, isto , a definio de um elemento pode implicar na necessidade de ajuste em outro anteriormente definido. Por exemplo: durante a definio dos parmetros da qualidade do projeto pode-se verificar que um item de escopo precisa ser modificado, gerando, assim a necessidade de redefinio do tempo e dos custos. Assim sendo, uma vez identificada a inteno de realizar o projeto, necessrio constitu-lo formalmente e definir seus principais parmetros para uma tomada de deciso quanto sua execuo. Estes parmetros devem ser documentados de tal forma que permitam uma avaliao quanto capacidade do projeto em alcanar seus objetivos e gerar os benefcios para a organizao executora. Uma boa documentao de um projeto fator decisivo para seu bom gerenciamento e para ganhos de produtividade em projetos futuros desenvolvidos pela organizao. muito comum a documentao de projetos ser vista como burocracia no sentido pejorativo do termo, porm, se lembrarmos que projetos so empreendimentos que geram produtos nicos, possvel perceber a utilidade de se ter referncias que diminuam o grau de ineditismo. Metodologia de Gerenciamento de Projetos A sistematizao da documentao de projetos geralmente est associada ao que se denomina metodologia de gerenciamento de projetos. Que nada mais do que a determinao de processos estruturados e conjunto de documentos recomendados para o gerenciamento de projetos com a finalidade de diminuir o grau de improviso das aes de projeto e permitir o alcance de melhores resultados custa de menos esforo. Evidentemente durante o processo de incorporao da tcnica h um esforo que pode, a princpio, ser considerado desproporcional, ou seja, estaria exigindo mais esforo para documentar do que para fazer. Isto de fato um risco que deve ser considerado, pois os limites do que pode ser instrumento gerencial e burocracia excessiva tnue. H um princpio da administrao, enunciado por Henry Fayol (1910), preconizando que: o controle no deve exceder o objeto controlado, isto , no devemos gastar mais energia para gerenciar do que para fazer. Para entendermos a aplicao prtica de uma metodologia de gerenciamento de projetos e a documentao associada, podemos fazer uma analogia com a natao. Um indivduo que incorporou uma tcnica de nado, depois de orientado por um treinador, passa a despender menos esforo e a obter melhores resultados em relao a quem nada por instinto, sem tcnica especfica. No caso da natao, quem domina a tcnica chega mais rpido outra margem com menos esforo.
29
A idia de que o mtodo de trabalho em projetos, metodologia de gerenciamento de projetos, permita o alcance de resultados efetivos com menos esforo. Pode parecer que nos primeiros projetos documentados e gerenciados segundo uma metodologia adotada, o esforo seja desproporcional, mas a tendncia de que os projetos subsequentes exijam menos esforo e gerem melhores resultados, representando o efetivo ganho de produtividade.
Plano de Gerenciamento do Projeto

O plano que ser a base de referncia para a execuo do projeto dever conter todas as orientaes necessrias para completar a entregas do projeto. composto de um conjunto de documentos dedicados ao gerenciamento do projeto. ESCOPO Declarao do ESCOPO WBS EAP Estrutura Analtica do Projeto TEMPO (Cronograma) Grfico de Gantt Diagrama de REDE CUSTO Oramento do projeto Sistema da Qualidade (Parmetros e Procedimentos) Organograma do Projeto e Matriz de Responsabilidades Matriz de Comunicaes Registro de Riscos (Resposta aos Riscos) Sistema de Gerenciamento de Configuraes Controle Integrado de Mudanas Sistema de Documentao Sistema de Gerenciamento de Configuraes necessrio definir como ser realizada a identificao e documentao das caractersticas funcionais e fsicas do produto e subprodutos do projeto, controle das mudanas feitas nessas caractersticas, registro e relato de cada mudana e o andamento da sua implantao, suporte auditoria dos produtos para verificar conformidade com os requisitos. Pode definir, tambm, como ser feita o controle de verses dos documentos do projeto. Controle Integrado de Mudanas Define os procedimentos para efetuar mudanas nas baselines do projeto ou no escopo do produto do projeto. Determina a documentao necessria, os sistemas de acompanhamento e os nveis de aprovao necessrios para autorizar mudanas.
30
Planos Subsidirios O gerenciamento do projeto e a manuteno dos elementos do projeto coesos entre si compem a rea de conhecimento integrao. A boa prtica recomenda que seja elaborado um plano determinando a melhor estratgia a ser adotada para gerenciar cada uma das demais reas de conhecimento necessrias ao gerenciamento do projeto. Plano de Gerenciamento do Escopo Plano de Gerenciamento do Tempo Plano de Gerenciamento dos Custos Plano de Gerenciamento da Qualidade Plano de Gerenciamento dos Recursos Humanos Plano de Gerenciamento das Comunicaes Plano de Gerenciamento dos Riscos Plano de Gerenciamento das Aquisies Alm dos planos de gerenciamento das reas de conhecimento o plano do gerenciamento do projeto deve conter alguns documentos como: contrato (quando for o caso; a definio dos objetivos e metas (se houver mudana em relao ao Termo de Abertura). necessrio, tambm, tratar de aspectos da organizao e da forma como ser conduzido o trabalho do gerenciamento do projeto. Quais processos sero utilizados no gerenciamento. Que artefatos (documentos, grficos, tabelas, etc.) sero elaborados e como ser o processo de elaborao. Como sero realizados os processos de monitoramento e controle do projeto. Outra definio importante quanto ao processo de planejamento, diz respeito s ferramentas e tcnicas que sero utilizadas nos processos. Por exemplo, determinar que o processo de definio do escopo do projeto utilizar reunies de brainstorming e entrevistas com os principais stakeholders do projeto. Linhas de Base (Baselines) de performance do projeto O plano de gerenciamento do projeto definido e aprovado ser a Linha de Base de referncia (baseline) a partir da qual o progresso do projeto ser avaliado. Sendo assim, as variveis definidas de escopo, tempo, custo, qualidade, recursos humanos (equipe do projeto), comunicaes, riscos e aquisies sero as bases de referncia do projeto como um todo. Significa que quaisquer mudanas nestas referncias devero ser tratadas como mudanas, pois geraro impactos no projeto.
31
COLETA DE REQUISITOS O sucesso do projeto diretamente influenciado pela ateno na captura e gerenciamento dos requisitos do projeto e do produto. Estes requisitos precisam ser obtidos, analisados e registrados com detalhe suficientes para sem medidos uma vez que a execuo do projeto se inicie. Coletar requisitos envolve definir e gerenciar as expectativas do cliente. Os requisitos sero o fundamento para o planejamento do escopo do projeto. Os requisitos podem ser categorizados em requisitos do projeto e requisitos do produto. Os requisitos do projeto podem, por sua vez, se encontrar dentro de uma das seguintes subcategorias: Requisitos relacionados com as necessidades de negcio identificadas no Termo de Abertura do Projeto (requisitos de negcio). Requisitos relacionados ao gerenciamento do projeto (requisitos de prazo, de custo e requisitos gerais de gerenciamento de projeto). Requisitos relacionados com a forma pela qual o projeto deve ser realizado, isto , relacionados ao processo do projeto.
Os requisitos do produto so aqueles que o produto do projeto precisa atender desde sua entrega ao cliente, ao final do projeto, at o fim do ciclo de vida do produto. Os requisitos coletados so ento documentados em um Documento de Requisitos, e usados como referncia para o planejamento e a execuo do projeto.
DEFINIO DO ESCOPO DO PROJETO

Apesar de haver uma pretenso j posta pelos demandantes do projeto, a forma do resultado final, assim como os passos intermedirios e o seu processo de elaborao, podem diferir, substancialmente. Como vimos, projetos no so atividades determinsticas, ou seja, no tm seu resultado garantido, pois so atividades que sempre carregaro uma parcela de risco, ou incerteza, so, portanto, atividades probabilsticas. Assim sendo, as escolhas possveis acerca do projeto precisam ser feitas. Este processo faz parte da definio do escopo, tanto de produto quanto de projeto. O desafio conseguir antever as conseqncias de cada escolha e identificar os melhores relaes de custo e benefcio. O escopo do projeto o ponto de partida de todas as outras variveis do projeto. O tempo, os custos, a qualidade, os recursos humanos necessrios, etc., s podero ser dimensionados se o escopo estiver definido. Ou seja, aquilo que para ser feito.
32
Todo o esforo dedicado uma boa definio de escopo ser bem empregado, pois os demais parmetros do projeto dependem diretamente deste. Elementos necessrios para definio do escopo (input) Para melhor realizar o processo de definio do escopo recomendvel que se utilize as informaes que estiverem disponveis at o momento: Histrico de projetos anteriores Declarao do trabalho Project Charter Declarao Preliminar do Escopo Ferramentas e Tcnicas utilizadas no processo de definio do escopo A natureza do produto do projeto ir determinar o conjunto de ferramentas e tcnicas mais adequado para realizar a definio do escopo.
Brainstorming
Se o projeto indito e requer uma contribuio criativa o brainstorming ser uma tcnica recomendada, pois consiste numa seo conduzida por um coordenador que estimula os participantes a terem idias relacionadas ao objeto do projeto sem restries de pertinncia, numa primeira rodada. Ou seja sem censura que reprima a criatividade. Em seguida feita uma avaliao da pertinncia e selecionadas as idias mais teis ao projeto. Opinio de especialistas (presencial ou com a Tcnica Delphi) importante, sempre que possvel, ouvir a opinio de especialistas sobre o tema do projeto. O mtodo Delphi uma tcnica com algumas semelhaas ao brainstorming, porm com algumas diferenas. Ambas devem ser conduzidas por um coordenador, ou facilitador, porm no Delphi os participantes permanecem annimos, portanto no devem estar no mesmo ambiente fsico. O coordenador do processo coloca a questo a ser opinada, recolhe as contribuies de cada participante, consolida, repassa os pontos de convergncia sucessivamente at o grupo chegar ao consenso. Esta tcnica tornou-se especialmente til com a facilidade da comunicao pela internet. Hoje, podemos colher a opinio de um especialista que esteja do outro lado do mundo. Modelos (templates), formulrios, normas, checklists Como apoio ao processo de definio do escopo conveniente lanar mo de quaisquer modelos, formulrios ou listas de verificao que possam ajudar a lembrar de elementos a serem includas no escopo. Listas de verificao (Checklists) que contenham informaes tpicas relacionadas ao tipo do projeto funcionam como uma espcie de roteiro e ajudam, no s a no deixar de esquecer de itens importantes, como a ganhar tempo no processo. Por
33
exemplo, em um projeto de construo de uma residncia os itens: estilo arquitetnico, nmero de quartos, existncia de piscina, etc., so tpicos. Anlise dos Stakeholders No apenas os interessados principais no projeto como o cliente e o patrocinador (sponsor) tm requerimentos que devem ser considerados na composio do escopo do projeto, os demais stakeholders, tambm, podem sofrer impactos, possuem necessidades e expectativas que devem ser consideradas e atendidas, na medida em que no comprometam o cumprimento dos objetivos do projeto. Em um projeto de modificao de layout, um determinado setor da empresa pode ter como requerimento que o trabalho seja interrompido o menor perodo de tempo possvel. Se este requerimento puder ser atendido sem prejudicar a relao de tempo e custo do projeto recomendvel que seja atendido, pois, a princpio, trar economia para a organizao. Metodologia de Desenvolvimento de Produtos Todo projeto ao seu trmino entrega um produto, portanto, as diversas tcnicas sistematizadas para o desenvolvimento de produtos so, na realidade, tcnicas de definio de escopo. Engenharia Robusta, Engenharia Simultnea, Prototipagem, QFD Quality Funtion Deployment, etc. As principais destas tcnicas foram desenvolvidas nos anos 80 e, hoje, j esto maduras em razo da aplicao intensiva com resultados expressivos em diversas reas da economia, com literatura disponvel para estudos mais aprofundados.
Escopo do Produto e Escopo do Projeto A boa prtica recomenda que para uma melhor organizao do trabalho se dividam as informaes de escopo em escopo do produto e escopo do projeto. Escopo do Produto Este primeiro escopo trata das especificaes do resultado que ser gerado pelo projeto na sua concluso. Descreve como ser a principal entrega do projeto. Relaciona caractersticas, funes e atributos. Deve traduzir os requerimentos postos ao projeto em especificaes para o resultado. Especificar o produto do projeto significa diferenci-lo dos demais do mesmo gnero, torn-lo, especial em suas particularidades, especfico. Em um projeto de uma residncia, por exemplo, residncia genrica. A especificao ir definir quantos quartos a residncia ter, quantos banheiros, se ter sala de jantar separada da sala de estar, qual sero as cores, etc. Todos os requisitos que tornam a residncia que ser construda nica. Escopo do Projeto Todo o trabalho necessrio para gerar o produto do projeto com todas as suas caractersticas especificadas no escopo do produto compem o escopo do projeto.
34
Representa todas as entregas intermedirias necessrias para produzir a principal entrega do projeto, para completar o escopo do produto. Para cada especificao de escopo do produto haver pelo menos uma entrega de escopo de projeto associada.
Entregas (Deliverables) e Marcos (Milestones) Alm do produto final ou resultado principal do projeto, ao longo do seu ciclo de vida, sero gerados subprodutos ou resultados parciais. Resultados so gerados por processos que seguem o modelo: entrada (input), processo (process) e sada (output), porm no mbito de projetos necessrio fazer-se uma distino entre as sadas (outputs) dos processos que no sero avaliadas e validadas por um terceiro daquelas que sero avaliadas pelo prprio executor. As primeiras, ou seja, aquelas que sero avaliadas e validadas por outro que no o prprio executor, so consideradas entregas (deliverables). Os demais resultados sero apenas sadas (outputs). Portanto, pode-se considerar que as entregas sero objeto de um controle externo ao executor. So passveis de verificao. O prprio termo remete ao movimento de transmisso do executor para o avaliador. Assim sendo, os momentos em que ocorrem entregas do projeto servem como pontos de referncia para a avaliao do progresso do prprio projeto. Estes pontos de verificao so denominados de marcos ou milestones. A expresso milestone, literalmente pedra da milha, vem da engenharia romana que usava uma pedra para marcar o percurso da estrada a cada de mil ps de um soldado romano. O conceito de marcar a distncia da origem como referncia fundamental para a medio do trabalho realizado no projeto. Se a entrega prevista para ser realizada naquele momento (ponto no tempo marco milestone) tiver sido efetivada, o projeto estar dentro do cronograma. Se no, estar atrasado. Dessa forma, o escopo (o trabalho) do projeto deve ser definido pelas entregas que sero necessrias para que o projeto atenda aos seus requisitos.
35
Critrios de aceitao do produto necessrio que as regras do jogo estejam bem claras desde o incio do projeto. Estes critrios sero a referncia que os demandantes do projeto utilizaro para avaliar se o projeto efetivamente cumpriu aquilo a que se props quanto aos seus objetivos e metas. So os limites de tolerncia para a aceitao formal das entregas do projeto. Sero utilizados no processo de inspeo realizado pelo cliente, denominado no Guia PMBOK de verificao do escopo do projeto. Compara aquilo que foi estabelecido nos requerimentos com o que de fato entregue. As metas do projeto so as referncias para o estabelecimento dos critrios de aceitao. Uma meta de um projeto de desenvolvimento de um software pode prever que 1.000 usurios faam acesso simultneo sem perda de performance, e estabelecer como critrio de aceitao, que se at 900 o projeto ser aceito. Excluses Especficas - Itens NO includos no escopo Procura definir itens que no sero entregues pelo projeto. Este conjunto de informaes faz-se necessrio porque, por melhor que seja a especificao do escopo do projeto, sempre haver possibilidade de dvida quanto a configurao tanto do produto do projeto quanto ao trabalho para realiz-lo. Serve, tambm, para identificar expectativas dos demandantes quanto a entregas, funcionalidades, atributos ou caractersticas que no foram explicitadas na Declarao do Trabalho (Statement of Work). H projetos que, por sua natureza, podem gerar elementos de especificao considerados bvios pelo demandante e por isso no so lanados na Declarao do Trabalho. Neste caso esta relao de itens funciona como uma lista de verificao (checklist) daquilo que efetivamente esperado do projeto. Premissas So fatos assumidos como verdadeiros pelas partes demandantes e os realizadores do projeto. So as regras do jogo. Condies sob as quais o projeto ser conduzido e que, se modificadas, influenciam a capacidade do projeto de alcanar seus resultados. Implicam, portanto, na necessidade de reviso dos parmetros estabelecidos para o projeto. Pode-se elencar como premissas em um projeto de desenvolvimento de um sistema corporativo, por exemplo, que ser necessria a autorizao de acesso a membros da equipe do projeto aos sistemas da empresa. Premissas so alvos primrios de riscos, porque, se atingidas, normalmente, geram alteraes na estrutura do projeto e, conseqentemente, na capacidade de atingir seus objetivos. Restries So fatores, previamente estabelecidos, que limitam as opes do projeto. Podem ser normas organizacionais que precisam ser seguidas, regimentos, legislaes, ou
36
quaisquer obrigaes relacionadas ao objeto do projeto. O regimento interno de um edifcio pode restringir o trabalho que gere rudo durante o perodo noturno. Definio progressiva do escopo H projetos cuja dificuldade de definio de escopo muito grande. Isto ocorre em funo do ineditismo do produto do projeto, do ambiente tecnolgico ser muito voltil, que o caso dos projetos de tecnologia da informao, ou mesmo pelas necessidades serem muito difusas em funo de interesses diversos. Este grau de incerteza pode ser traduzido em funo da distncia entre o ponto de partida e o alvo (escopo) a ser atingido. Geometricamente percebe-se que quanto maior for esta distncia maior ser a possibilidade de desvio do alvo. Ou seja, uma pequena variao no incio pode, dada a distncia ao alvo, tornar-se grande.
Portanto, a recomendao de que se procure identificar, sempre que possvel, pontos de partio do escopo total que possam ser realizados parcialmente. Ou seja, verificar se possvel dividir o projeto em partes e fechar o acordo de definio do escopo da ou das partes que possibilitem a definio de escopo com razovel grau de previsibilidade.
O alvo do projeto passa a ser ento B1 e no o todo Bt (total). O compromisso do projeto entregar B1. Reduzindo o potencial de desvio.
A entrega B1 ser, posteriormente elemento de entrada (input) para o projeto de entrega de B2 e assim sucessivamente at completar a entrega total pretendida (Bt).
37
A natureza integrativa do planejamento exige que reas como escopo, tempo e custo sejam coordenadas cuidadosamente em um processo iterativo. medida que mais informaes ou caractersticas do projeto so reunidas e compreendidas, planejamento adicional pode ser necessrio. O detalhamento progressivo do plano de gerenciamento do projeto geralmente chamado de planejamento em ondas sucessivas, indicando que o planejamento e a elaborao da documentao associada so processos contnuos e repetitivos.
A definio do escopo, dessa forma, permite que a demanda real do projeto, ou seja, a razo de sua realizao, seja elaborada e formulada progressivamente.
O processo de Verificao do Escopo

Uma vez definido o escopo necessrio determinar como o cliente avaliar a sua efetiva realizao. Que procedimentos sero usados para o cliente verificar, constatar se aquilo que foi proposto na declarao do escopo corresponde ao que de fato estar sendo entregue. Ser a aplicao de critrios de aceitao de entregas parciais, ou intermedirias, e do produto final, definidos na declarao do escopo.
ESTRUTURA ANALTICA DO PROJETO (EAP) (Work Breakdown Structure WBS) Os americanos costumam referir-se EAP (WBS) como the big picture of the project, no sentido de que uma imagem que permite a viso do todo, do conjunto completo. Possibilita uma viso holstica do projeto. Que ao olhar a EAP (WBS) consegue-se enxergar tudo aquilo que o projeto ir realizar. Analisar (Estrutura Analtica) significa decompor em partes menores para melhor compreender o todo e as partes que o compem. exatamente essa a misso da EAP que a principal ferramenta para o gerenciamento do escopo do projeto. A decomposio d-se de cima para baixo, da o termo em ingls: breakdown, a partir do projeto, que ser o primeiro nvel, ou nvel zero, como preferem alguns autores. Por ser uma ferramenta de escopo, na EAP no aparecem atividades (aes ou tarefas), so representadas apenas entregas geradas pelo projeto (deliverables).
38
Portanto, nela no so representadas relaes de dependncia temporal de execuo. A hierarquia da EAP diz respeito a um todo (no nvel acima) que composto de partes (no nvel abaixo).
1 N vel : Nome do Projeto 1 Nvel

1. 1. PROJETO PROJETO
2.1 2.1 Fase Fase 1 1
2.2 2.2 Fase Fase 2 2
2.3 2.3 Fase Fase 3 3
3.1 3.1 Entrega Entrega
4.1 4.1 PT PT
4.2 4.2 PT PT
4.3 4.3 PT PT
4.4 4.4 PT PT
4.5 4.5 PT PT
4.6 4.6 PT PT
4.7 4.7 PT PT
4.8 4.8 PT PT
4.9 4.9 PT PT
4.10 4.10 PT PT
4.11 4.11 PT PT
4.12 4.12 PT PT
O segundo nvel da EAP representa o ciclo de vida do projeto, pois determina a primeira partio do projeto, ou seja, suas macro-fases.
2 N vel : Ciclo de Vida do Projeto 2 Nvel

2.1 2.1 Fase Fase 1 1
2.2 2.2 Fase Fase 2 2
2.3 2.3 Fase Fase 3 3
4.1 4.1 PT PT
4.2 4.2 PT PT
4.3 4.3 PT PT
4.4 4.4 PT PT
4.5 4.5 PT PT
4.6 4.6 PT PT
4.7 4.7 PT PT
4.8 4.8 PT PT
4.9 4.9 PT PT
4.10 4.10 PT PT
4.11 4.11 PT PT
4.12 4.12 PT PT
39
3 N vel : Principais entregas do projeto 3 Nvel

2.1 2.1 Fase Fase 1 1
2.2 2.2 Fase Fase 2 2
2.3 2.3 Fase Fase 3 3
4.1 4.1 PT PT
4.2 4.2 PT PT
4.3 4.3 PT PT
4.4 4.4 PT PT
4.5 4.5 PT PT
4.6 4.6 PT PT
4.7 4.7 PT PT
4.8 4.8 PT PT
4.9 4.9 PT PT
4.10 4.10 PT PT
4.11 4.11 PT PT
4.12 4.12 PT PT
2.1 2.1 Fase Fase 1 1
2.2 2.2 Fase Fase 2 2
2.3 2.3 Fase Fase 3 3
4.1 4.1 PT PT
4.2 4.2 PT PT
4.3 4.3 PT PT
4.4 4.4 PT PT
4.5 4.5 PT PT
4.6 4.6 PT PT
4.7 4.7 PT PT
4.8 4.8 PT PT
4.9 4.9 PT PT
4.10 4.10 PT PT
4.11 4.11 PT PT
4.12 4.12 PT PT
ltimo N vel : Pacotes de Trabalho ltimo Nvel

(menor entrega do projeto)
O projeto , ento, sucessivamente sendo quebrado (break), em nveis de entregas cada vez menores at o menor nvel desejado para detalhamento do escopo do projeto. Este nvel denominado no Guia PMBOK de pacote de trabalho. A deciso de at onde decompor determinada por alguns fatores relacionados forma pela qual o projeto ser gerenciado. Novamente se apresenta uma situao de trade-off, ou seja, faz-se necessria uma avaliao de custo/benefcio entre detalhar (decompor) ou no decompor. A favor da maior decomposio pesa o fato de permitir uma melhor identificao (visualizao) das menores partes e com isso aumentar a previsibilidade de projeto. Porm este maior detalhamento implica em maior esforo de planejamento e posterior controle. O ltimo nvel de decomposio da EAP, ou detalhamento do projeto est relacionado ao nvel de domnio e controle que se deseja exercer sobre os elementos de escopo do projeto, isto , se for necessrio que um elemento de escopo seja realizado exatamente de determinada forma, ento ser necessrio o detalhamento. Por exemplo, em um projeto de um evento, onde a EAP for decomposta at o nvel de aquisio das passagens areas dos participantes e no for relevante ou determinante que a entrega seja decomposta em: prospeco, seleo e contratao, isto se os detalhes de como a entrega ser realizada no forem importantes e no requererem um controle de execuo das partes, no h necessidade de decompor esta entrega. Neste caso a superviso e o controle ir at o nvel de entrega das passagens areas.
40
O projeto , ento, sucessivamente quebrado (break), em subprodutos cada vez menores at o menor nvel desejado para detalhamento do escopo do projeto.
Possveis EAP (Estrutura Analtica do Projeto WBS Work Breakdown Structure) para um mesmo projeto.
41
Ainda relacionado ao controle est o princpio 8/80 que recomenda que um pacote de trabalho no tenha menos do que 8 e no mais do que 80 horas de durao. O que equivale recomendar que o menor ciclo de controle do projeto no seja menor do que um dia (8 horas) e no maior do que duas semanas (2 semanas de trabalho de 40 horas) Outro fator determinante para a parada da decomposio se a entrega ser realizada por um terceiro. Mesmo que seja da prpria organizao executora, no caso de um setor de Marketing que ir preparar um plano de marketing para o projeto, nestes casos, o gestor do projeto figurar como um demandante de um projeto (sub-projeto) e no haver necessidade de detalhar o como da entrega terceirizada.
Decomposio dos pacotes de trabalho em atividades que formaro o diagrama de rede do projeto
Formas de EAP A estruturao do projeto pode d-se da maneira mais conveniente para os executores do projeto. Pode ser em formato de uma lista indentada ou em distribuio radial, conforme exemplos abaixo.
42
Funes da EAP Alm da misso de identificar a plenitude do trabalho do projeto, seguindo o princpio dos 100%, que determinam que 100% do trabalho do projeto deve estar representado na EAP, esta permite ou facilita a elaborao de uma srie de elementos do projeto. Por sua estrutura refletir a hierarquia de construo do projeto a EAP permite, com pequenos ajustes, a elaborao do organograma do projeto.
Permite a atribuio especfica de responsabilidades por entregas
PROJETO PROJETO Gerente Gerente do do Projeto Projeto
Fase Fase 2 2
Resp. Resp. Fase Fase 2 2
Entrega Entrega A A
Entrega Entrega B B
Resp.Ent Ent.A .A Resp. Resp.Ent.A
Resp.Ent Ent.B .B Resp. Resp.Ent.B
PT PT 1 1
PT PT 2 2
PT PT 3 3
PT PT 4 4
R.PT R.PT 1 1
R. R. PT PT 2 2
R.PT R.PT 3 3
R.PT R.PT 4 4
A EAP pode servir como referncia para uma identificao e tratamento de riscos a partir de cada entrega.
43
Tratamento de Riscos Associados por entregas
PROJETO PROJETO
Identificao de Riscos Associados por entregas

Fase Fase 2 2
Entrega Entrega
Entrega Entrega
PT PT
PT PT
PT PT
PT PT
Estimativas de custo tornam-se mais simples se seguirem a seqncia inversa da EAP, ou seja de baixo para cima (Bottom Up).
100 100
50 50
50 50
25 25
25 25
25 25
25 25
O ltimo nvel da EAP, os pacotes de trabalho, uma vez decompostos, identificaro as atividades do projeto que , sob o ponto de vista do processo de decomposio, a menor clula do projeto. Com as atividades identificadas ser possvel construir o cronograma do projeto. A EAP est diretamente relacionada natureza do produto do projeto. Significa que projetos de mesma natureza, como por exemplo, projetos de desenvolvimento de software que utilizem a mesma metodologia, tero EAP muito parecidas, podendo, inclusive, ser aproveitadas como modelo.
Dicionrio da EAP (WBS) As entregas indicadas na EAP devem ser descritas de forma sucinta, portanto h a necessidade de descrev-las de forma mais detalhada. Para isso, a boa prtica recomenda que seja elaborado um dicionrio, uma espcie de glossrio da EAP (WBS), no qual sero detalhados os significados e os elementos mais importantes das entregas do projeto.
44
DICIONRIO DA WBS Cdigo # Responsvel Data ltima atualizao Verso #
Descrio da Entrega Produto (Deliverable) Critrios de Aceitao Recursos Durao Predecessor Aprovador da Execuo Custo Sucessor Milestones (Marcos) Restries Data da Aprovao
Aprovador da Entrega
Data da Aprovao
Modelo de Dicionrio da EAP (WBS). As informaes essenciais so o cdigo e a descrio da entrega as demais, inclusive de outras reas de conhecimento, tais como durao, custo etc., sero documentadas na sequncia do processo de planejamento
CRONOGRAMA DO PROJETO O desenvolvimento do cronograma do projeto envolve a definio das atividades e seu sequenciamento, a determinao dos recursos humanos e materiais necessrios realizao das atividades, a estimativa da durao das atividades e o posicionamento em um calendrio real em que sejam consideradas as limitaes de perodos de trabalho. 1- DEFINIO DE ATIVIDADES A decomposio das entregas do ltimo nvel da EAP (pacotes de trabalho) identificar as atividades necessrias para a realizao das entregas previstas pelo projeto. Estas sero as menores unidades de execuo do projeto. As atividades permitiro demonstrar as mais detalhadas relaes de dependncia necessrias elaborao do diagrama de rede do projeto.
45
2- SEQUENCIAMENTO DAS ATIVIDADES Sequenciar as atividades do projeto significa determinar as relaes de dependncia lgica entre as atividades. A dependncia lgica uma relao de causa e efeito entre atividades na qual: a atividade PREDECESSORA a causadora da SUCESSORA. Ou seja, a atividade SUCESSORA determinada, influenciada, pela atividade PREDECESSORA. A dependncia lgica no uma dependncia cronolgica, isto a atividade SUCESSORA pode ser realizada antes no tempo da atividade PREDECESSORA.
As atividades preparao para a prova e a marcao da data da prova podem ilustrar essa diferena, pois dependendo das condies podem assumir o papel tanto de PREDECESSORA como de SUCESSORA.
46
Tipos de dependncias Dependncias Obrigatrias Seguem uma lgica rgida (hard logic). Dada a natureza das atividades, a atividade sucessora depende necessariamente da predecessora. fisicamente impossvel ser invertida. Por exemplo: a pintura de uma parede depende do emboo. Dependncias Facultativas H atividades, porm que no apresentam dependncia lgica entre si, mas por convenincia, ou preferncia, o gestor do projeto estabelece uma relao de dependncia. Tambm denominada de dependncia arbitrada ou discricionria (soft logic), passa a existir por deciso do gestor do projeto em funo de ser uma melhor composio de acordo com as melhores prticas do ramo de atividade relacionada ao projeto, ou de experincias em projetos anteriores. Por deciso gerencial, podem ser desfeitas ou invertidas. Dependncias Externas Fatores externos ao projeto podem ter relacionamentos que gerem restries forma pela qual as atividades podem ser conduzidas. Uma aprovao governamental, por exemplo, ir limitar as atividades que dependam dela.
Relaes de Dependncia entre atividades
47
Todo projeto, por definio, tem incio e fim definidos previamente, ou seja, um ponto de partida e outro de chegada, portanto possvel representar graficamente as atividades do projeto em sequncias determinadas pelas relaes de dependncia entre elas em forma de uma rede.
No diagrama de rede, ou diagrama de precedncia (PDM Precedence Diagramming Method), so identificadas quais atividades sero executadas em srie e quais sero desenvolvidas simultaneamente, ou em paralelo.
Os conjuntos de atividades dependentes entre si so denominados de caminhos. Um projeto pode ter muitos caminhos, mas todos eles partiro do ponto de incio e terminaro no ponto de fim do projeto. A rede acima apresenta os seguintes caminhos: Incio-A-B-D-Fim; Incio-A-B-E-Fim e Incio-A-C-E-Fim. 48
Exemplo da determinao das dependncias entre as atividades e o consequente diagrama de rede
3- ESTIMATIVA DE RECURSOS A fim de poder calcular as duraes das atividades necessrio determinar que recursos humanos, materiais e de equipamentos sero utilizados, ou seja, os recursos executores das atividades. preciso identificar as disponibilidades de cada um dos recursos, a fim de que no haja superalocaes, se o recurso prprio da organizao ou ser contratado de terceiros, assim como suas capacidades de desempenho. Havendo a possibilidade do recurso a ser utilizado na realizao da atividade necessrio que cada recurso seja associado, atribudo, a cada atividade, conforme figura a seguir.
49
No caso de recursos humanos importante identificar suas produtividades que dependem de suas competncias especficas relacionadas natureza da atividade, de suas experincias anteriores, nas suas formaes e perfis profissionais. Quanto aos equipamentos importante, na medida do possvel, diferenciar a capacidade nominal, a prevista no manual, da capacidade real, ou efetiva, pois uma superestimao de desempenho pode gerar falsas expectativas que no momento da execuo sero frustradas. 4- ESTIMATIVA DE DURAO DAS ATIVIDADES Uma vez que os recursos executores com suas respectivas capacidades de desempenho foram determinados, possvel estimar o tempo de durao das atividades.
A durao da atividade como funo da relao entre o trabalho e os recursos determinados para execut-lo faz com que o aumento do nmero de recursos para uma mesma quantidade de trabalho, ou esforo, gere uma reduo na durao, conforme grfico a seguir:
Entretanto, esta relao matemtica, na prtica no se confirma, pois segue o princpio de economia dos lucros cessantes ou retornos decrescentes (Law of Diminushing Returns), que considera que o ganho de produtividade com a adio de recursos no linear, isto , na realidade os recursos tm competncias ou capacidades diferentes, portanto gerando desempenhos diferentes.
50
Sendo assim, estas perdas devem ser compensadas quando forem feitas as estimativas de durao das atividades. Ao realizar o processo de estimar durao das atividades necessrio determinar o grau de preciso requerido. Uma estimativa com maior preciso, se por um lado gera maior confiabilidade, por outro requer mais esforo, utilizao e manipulao de mais dados e informaes, portanto tem maior custo. Em casos onde no possvel obter informaes mais precisas, pode-se estimar a durao por analogia, isto , comparando com experincias anteriores. Vale ressaltar, que se deve ter o cuidado em comparar grandezas de mesma ordem e caractersticas. A melhor condio de confiabilidade para a estimativa que seja obtida do prprio recurso escalado para executar a atividade e que sua produtividade real seja conhecida do gestor do projeto. Na impossibilidade de definio do executor o gestor do projeto ter que realizar a estimativa a partir da opinio de um especialista na matria, de tempos padro em funo do tipo da atividade, ou de clculos paramtricos, ou seja, a multiplicao de quantidades por produtividades. Modelos matemticos que estabelecem correlaes entre variveis: metros por hora, montagens por dia, etc. O processo de elaborao da estimativa, entretanto, determinante na qualidade dos esforos e tempos estimados. Uma simples solicitao de prazo pelo gestor do projeto ao executor pode esconder distores significativas. Vale a pena analisar algumas situaes tpicas e seus efeitos nos parmetros do projeto. Estimativa do Executor
Neste caso, o gestor do projeto solicita ao executor que estime a durao de uma atividade. De modo geral, o executor faz uma anlise superficial, pois, infelizmente, no prtica comum ter-se controles de time sheet ou apontamento de horas correlacionando perodo de trabalho e tarefa ou atividade de projeto. Assim, a partir
51
apenas de uma idia do volume de trabalho j comprometido, o executor fornece uma estimativa maior do que real para se defender de cobranas acerca do no cumprimento do compromisso. O esquema abaixo procura ilustrar esta relao. Nas estimativas fornecidas pelo executor, em geral, h a incluso de uma margem de segurana para o cumprimento do compromisso. O executor no gosta de ter sua estimativa no confirmada, portanto natural que queira se proteger colocando colches (padding). Cabe ao gestor do projeto tentar identificar os excessos e negociar, com base em histricos anteriores ou outras fontes uma maior adequao. Estimativa do Gestor do Projeto Aqui o gestor do projeto estima por sua conta a durao da atividade considerando que o executor a realizar no perodo estabelecido e dedicar seu tempo integralmente a execuo da atividade.
Estimativa Conjunta Gestor do Projeto e Executor Neste caso, o gestor do projeto e o executor da atividade analisam os perodos efetivamente disponveis e que realisticamente sero dedicados ao trabalho na atividade e negociam uma distribuio da carga de trabalho e chegam durao da atividade.
52
Estimativas Probabilsticas - Estimativa a partir de clculos estatsticos que considera trs valores de estimativa (Three points Estimate): a estimativa mais otimista, a mais pessimista, a mais provvel.
F
Esta modelagem foi elaborada para aplicao em projetos no final da dcada de 50 durante o desenvolvimento da srie de submarinos Polaris para a Marinha Americana e foi denominada de PERT (Program Evaluation and Review Technique). Este mtodo de estimar perfeitamente coerente com a natureza da atividade projeto que essencialmente probabilstica. Apresenta as estimativas como faixas de valores possveis e no como um palpite certeiro que dificilmente seria cumprido. No primeiro passo, a formulao estatstica soma os tempos otimistas e pessimistas ao mais provvel multiplicado por 4. O + 4M + P 6
E=
Esta mdia considera a proporo probabilstica de ocorrncia da mais provvel e gera um efeito de compensao dos extremos estimados. Ou seja, uma estimativa que tenderia a ser muito otimista, ao aplicar a frmula compensada em direo a valores pessimistas, e vice e versa.
E>M E=M E<M
M E
E M
Aps esta mediao necessrio estabelecer a faixa de expectativa de preciso, ou seja, o intervalo a partir do qual ser estabelecido o compromisso do projeto. No exemplo a seguir, estimativas calculadas com base na frmula probabilstica.
53
ATIVIDADE A B C D E F G H I J Determinao da data da conferncia Determinao do tema e do programa Escolha do local Obter palestrantes Desenvolver material de divulgao Obter mailling Enviar divulgao Imprimir material para participantes Receber inscries Preparar KITs
Otimista (O) 1 2 4 4 3 3 1 3 4 1
Mdia (M) 2 5 5 6 10 4,5 2 3,5 6 2
Pessimista (P) 3 8 6 8 11 9 3 7 8 3
Estimativa (E) 2 5 5 6 9 5 2 4 6 2
O intervalo de preciso determinado pelos desvios padres considerados. Para um desvio padro a expectativa de cumprimento da estimativa de 68,26%, se forem considerados dois desvios padro, sobe para 95,46% e se forem trs, para 99,73%.
99,73 % 95,46 %
68,26 %
1s 2s 3s
1s 2s 3s
A natureza da atividade, sua complexidade, seu ineditismo, etc., ser determinante para a aplicao de uma faixa maior ou menor de estimativa. Para o clculo do desvio padro pode ser utilizada a frmula emprica onde:
Desvio Padro s
P-O 6
54
ATIVIDADE
Otimista (O)
Mdia (M)
Pessimista (P)
Estimativa (E)
Desvio Padro
Varincia
Range de Estimativa
Range de Estimativa
1s
1,77 7.67 a 10.33
1s
9,00 + ou 1,33
Desenvolver material de divulgao
3,00
10,00
11,00
9,00
1,33
2s
6,34 a 11,66
2s
9,00 + ou 2,66
3s
5,01 a 12,99
3s
9,00 + ou 3,99
Dessa forma a estimativa de durao da atividade E estaria entre 7,67 e 10,33 dias com a preciso de 1 desvio padro, estaria entre 6,34 e 11,66 dias com a preciso de 2 desvios padro e entre 5,01 e 12,99 dias com a preciso de 3 desvios padro de tolerncia. Caminho Crtico O mtodo do caminho crtico (CPM - Critical Path Method) foi uma importante contribuio para o gerenciamento de projetos, desenvolvida, no final da dcada de 50, pelo pessoal da companhia americana Duppont e a inglesa Remington. O conceito baseia-se no modelo de rede que identifica caminhos, que so conjuntos de atividades dependentes entre si. Dos caminhos do projeto um ou mais deles ter ou tero maior durao. Este ou estes caminhos, determinam a durao total do projeto. Este ou estes caminhos, sero considerados crticos porque qualquer atraso nele ou neles resultar em atraso do projeto.
Os demais caminhos tero, portanto, menor durao. Esta diferena de durao ser tratada como folga. Sendo assim o caminho crtico ser aquele ou aqueles com a menor folga ou com folga igual a zero, no caso do tempo permitido ou demandado ao projeto ser igual ao tempo calculado ou estimado. Por exemplo, se o produto de um projeto precisa ser entregue no dia 30 e a estimativa calculada prev que o projeto poder ser entregue no dia 25. Neste caso h uma folga de projeto que ser tambm do caminho crtico. Portanto, o caminho crtico, nesse caso ser o de menor folga.
55
importante ressaltar que as folgas dos demais caminhos, no-crticos so recursos valiosos a serem utilizados pelo gestor do projeto e no tempo disponvel para ser desperdiado. Uma manipulao adequada das folgas de caminhos no-crticos pode gerar economias de tempo e custo significativas ao projeto, como veremos nos mtodos de compresso ou reduo de cronograma. Para calcular o Caminho Crtico necessrio seguir uma rotina que ser descrita passo-a-passo a seguir. Antes de mais nada, necessrio definir o que so incios mais cedo e mais tarde e trminos mais cedo e mais tarde. Considerando-se o conceito de folga, onde haver a possibilidade de executar as atividades de caminhos que no so crticos, que portanto, tm folgas, dentro de um intervalo de tempo igual a folga sem comprometer o projeto, ou seja, sem ultrapassar a durao do caminho crtico. Sendo assim estas atividades podero comear a ser executadas em um momento mais cedo ou em um momento mais tarde no cronograma sem atrasar o projeto. Conseqentemente, somando-se a durao estimada para a atividade teremos seus trminos mais cedo e mais tarde.
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Incio mais CEDO
Trmino mais CEDO
Incio mais TARDE
Trmino mais TARDE
Representao grfica da rede com a Atividade no N (Activiti-on-node AON)
56
Para o clculo do caminho crtico necessrio analisar as atividades do projeto a fim de estabelecer as relaes de dependncia a fim de encontrar os caminhos da rede do projeto.
Atividade A pode comear imediatamente e tem uma estimativa de durao de 3 semanas Atividade B pode comear aps a atividade A ser completada e tem uma estimativa de durao de 3 semanas Atividade C pode comear aps a atividade A ser completada e tem uma estimativa de durao de seis semanas Atividade D pode comear aps a atividade B ser completada e tem uma estimativa de durao de oito semanas Atividade E pode comear aps a atividade C e D serem completadas e tem uma estimativa de durao de quatro semanas
ATIV.
Ant.
Durao
A B C D E
A A B C, D
3 3 6 8 4
A INCIO 0
4 FIM
Em seguida, calcula-se os tempos de incio e trmino mais cedo de cada atividade.
Trmino Mais Cedo de B = Trmino Mais Cedo de A + Durao de B
B 3
3 6
A INCIO 0 0
3 3
4 FIM
57
Incio Mais Cedo de E (Convergncia) = Trmino Mais Cedo da Atividade de Maior Trmino Mais cedo das convergentes 14 > 9
B 3 3 6 D 6 8 14
A INCIO 0 0
3 3
E 14
4 18 18 FIM 18
C 3
6 9
Tempo Total do Projeto Estimado Se houvesse mais tempo permitido Este valor seria diferente Por Exemplo: 20. O Projeto teria uma folga de 2 semanas
Depois o clculo dos tempos mais tarde.

B 3 3 A INCIO 0 0 0 0 3 3 3 3 6 6 D 6 6 8 14 14 E 14 14 4 18 18 18 FIM 18
C 3
6 9 14
Se houvesse folga total para o Projeto Apareceria aqui
3 menor que 8
FOLGA em C 14 9 = 5 83=5
Com isso possvel identificar o caminho crtico do projeto, que, neste caso, tem folga igual a zero. O outro caminho possui folga de 5 semanas.
CAMINHOS Incio-A-B-D-E-Fim Incio-A-C-E-Fim Dur 18 13
B 3 3 A INCIO 0 0 0 0 3 3 3
3 6 6
D 6 6
8 14 14 E 14 14 4 18 18 18 FIM 18
C 3 8
6 9 14
O diagrama de rede, portanto, permite identificar as relaes de dependncia entre as atividades e o caminho crtico do projeto.
58
Grfico de Gantt Cada ferramenta utilizada para o gerenciamento do projeto tem uma finalidade especfica e apresenta um conjunto diferente de informaes. O grfico de barras desenvolvido pelo Engenheiro Gantt no final da dcada de 20 mostra a proporo de durao das atividades em uma escala de tempo. Mostra, tambm, os posicionamentos dos perodos de durao das atividades. Permite visualizar mais facilmente quanto de interseo h entre os momentos de realizao das atividades.
Atividades Atividade A Atividade B Atividade C Atividade D Atividade E 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Grfico de Gantt (ou Barras)
Algumas regras precisam ser respeitadas quando do desenho de um grfico de Gantt. A escala de tempo no deve ser modificada em um mesmo desenho, pois isso geraria perda da visualizao da proporo das duraes. A recomendao de que se faa grficos diferentes para cada escala de visualizao. No caso de um projeto de durao de 5 anos, poderia ser feito um grfico em anos, outro em semestres, outro em trimestres, meses e at semanas. Da mesma forma, no se deve fazer cortes no meio do grfico para encurt-lo.
Grfico de Gantt (ou Barras) e Diagrama de Rede, compondo o Cronograma do Projeto
59
Reduo do Cronograma (Schedule Compression) Aps a elaborao do cronograma pode-se constatar que os prazos calculados no atendem aos requisitos do projeto. Neste caso, deve-se procurar alternativas de reduo do cronograma que mantenham a melhor relao de custo benefcio. Fast Tracking (Paralelismo) A tcnica consiste na anlise de atividades do CAMINHO CRTICO, que foram programadas para serem executadas em seqncia linear a fim de verificar a possibilidade de passarem a ser executadas em paralelo, simultaneamente.
B I Fim A C H D E F G
B I A
E G Fim
C H
As atividades do Caminho Crtico cujas relaes de dependncia so arbitradas e foram planejadas em seqncia linear por convenincia de projeto, sero os alvos primrios da anlise de Fast Tracking, porm as atividades com dependncias obrigatrias tambm podem permitir um Fast Traking parcial. Ou seja uma parte da atividades poder ser executada em paralelo ou simultaneamente.
T - FT
FT
Ganho de tempo com o Fast Traking
O Fast Tracking tanto total quanto parcial aumenta o risco de atraso do projeto, pois aumenta a necessidade de gerenciamento. Atividades ocorrendo em paralelo, simultaneamente, exigem maior superviso. Os pontos de autorizao do incio da sucessora so, em geral, difusos, isto , so obtidos por clculos paramtricos. Por exemplo: aps 1 metro de cola aplicada ser possvel comear a colao do papel de parede. Pode exigir tambm, conforme a natureza das atividades a adio de mais recursos para executar ambas as atividades. No possvel afirmar genericamente que isto, necessariamente, levaria a um aumento de custo, pois os ganhos com o tempo de execuo podem compensar e
60
at mesmo ultrapassarem o valor dos recursos adicionais. Por isso, tanto neste mtodo como no seguinte, necessria uma anlise de trade-off, isto avaliar qual opo trar mais vantagens para o projeto. Crashing (Compresso) Mais uma vez o Caminho Crtico ser o alvo de uma anlise que verificar se a adio, troca ou realocao de recursos poder gerar ganhos de tempo no cronograma. Tambm, neste mtodo as trade-off so necessrias. Na adio de recursos necessrio considerar a influncia nos resultados de alguns fatores. 1- Se a atividade sensvel durao, ou seja, se a adio de recurso de fato diminuir sua durao. Por exemplo, em um projeto de uma casa, a atividade de concretagem da laje requer um nmero necessrio e suficiente de recursos humanos e de equipamentos para a realizao do trabalho de lanamento e assentamento do concreto que determinam sua durao. No haver reduo de durao se houver um acrscimo de recursos nesta atividade. 2- A lei dos retornos decrescentes (Law of Dimininushing Returns), citada anteriormente, deve-se considerar fatores tais como: a maior necessidade de superviso, perdas por processos de setup redundantes, etc. 3- necessrio avaliar (trade-off), se o custo do recurso adicional ir ultrapassar os ganhos de desempenho. Se isto acontecer, e o fator crtico de sucesso do projeto for custo, a adio no ser uma alternativa vivel. CUSTOS DO PROJETO Uma vez definidos o escopo, o que fazer, e o tempo necessrio para fazer o que precisa ser feito no projeto, pode-se estimar o quanto ir custar o projeto. Como em todo o processo de planejamento a modo como o custo ser tratado no projeto precisa ser planejado. Ser necessrio elaborar o plano de gerenciamento de custos do projeto que indicar a estrutura de custos do projeto determinando a classificao dos centros de custos, critrios de rateios, reservas previstas, etc., ou seja, definir a estratgia a ser adotada na oramentao do projeto. Classificao dos Custos A forma geral, contbil, de classificar custos leva em considerao o ponto de vista da empresa, isto , o referencial a empresa. Para uma classificao que sirva ao gerenciamento do projeto, deve-se classificar custos sob a perspectiva do projeto, ou seja, tendo como referencial o projeto e no a empresa. Custos Fixos e Variveis Custos que no variam com o tempo, nem com a intensidade de utilizao, nem com o volume de servios gerados pelo projeto, so classificados como fixos. So custos que, independentemente da durao, ou de quaisquer variveis do projeto, tero o mesmo valor. Se, ao contrrio da situao anterior, os custos variarem de valor conforme o uso eles sero classificados como custos variveis.
61
O custo do transporte de um equipamento, que ser usado no projeto, um exemplo de custo fixo. J o custo de mo-de-obra para a execuo de uma atividade do projeto um exemplo de custo varivel, pois seu valor depender da durao da atividade. Custos Indiretos e Diretos Um custo ser indireto se no conseguirmos atribulo direta e especificamente a uma nica atividade do projeto. Isto , se deste custo beneficiarem-se mais de uma atividade do projeto. Neste caso haver a necessidade de um rateio entre as atividades beneficiadas para que elas absorvam a proporo devida a cada uma do custo. Se, ao contrrio, conseguirmos atribuir diretamente a uma nica atividade um custo este ser classificado como um custo direto. O salrio do coordenador de uma rea do projeto, por exemplo, cujo trabalho ser dedicado a todas as atividades da reas coordenada, um custo indireto que dever ser rateado entre todas as atividades da rea segundo critrios que sejam capazes de representar a verdadeira proporo de dedicao do coordenador. J o custo de um equipamento que ser utilizado exclusivamente para a execuo de uma nica atividade dever ser classificado como um custo direto. Uma classificao de custos realizada de forma indevida pode levar a distores que mascarem a real distribuio dos custos no projeto, podendo gerar decises desfavorveis aos objetivos do projeto. Alocao dos custos no projeto A fim de representar o real impacto dos custos nas partes especficas do projeto necessrio que seja feita a apropriao de custos. A cada atividade do projeto dever ser apropriado os valores correspondente aos seus custos diretos e carga dos custos indiretos que lhes so devidas seguindo critrios de rateio.
Atribuio (vinculao) dos custos a cada atividade do projeto
62
A correta alocao dos custos do projeto gerar uma curva de custos incorporados que ser o balizador de monitoramento e controle dos custos do projeto. Esta curva em razo da natureza geral de projetos, que possuem um comportamento tpico de menor intensidade de consumo de recursos no seu incio, maior consumo nas fases intermedirias e declnio de consumo ao seu final, assume o formato de S, sendo, portanto denominada de curva S do projeto.
Curva S do Projeto Curva de distribuio dos custos acumulados do projeto
Custo 550 500 450 400 350 300 250 200 150 100 50 0 PROJETO 1 Atividade 1 Atividade 2 Atividade 3 Atividade 4 Atividade 5 Atividade 6 Atividade 7 Atividade 8 Atividade 9 Atividade 10
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 36
8- Oramento total do Projeto 7- Reserva de Gerenciamento (Trat. Desconhecidos) 6- Base de Referncia de Custos (Cost Baseline) 5- Reservas de Contingncia (Trat. conhecidos)
1 Custo 40 100 70 10 30 70 30 60 40 60
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 36
280 280
60 60
220 220
Curva S do Projeto Representa a correlao direta entre as atividades e os custos do projeto

20 20
Estrutura hierrquica dos custos do projeto

4- Projeto
200 200
Aps a correta alocao ser obtido o montante geral oramentrio para o projeto ao 100 100 100 qual ser somados os valores 100 relativos s reservas de contingncia do 3- devero Contas de Controle
50 Copyright Compass International Knowledge Center 2- Pacotes de Trabalho 50 50 63 50 50 50 50 50
1- Atividades
25 25
25 25
25 25
25 25
25 25
25 25
25 25
25 25
projeto, ou seja, os valores dos oramentos das aes de respostas aos riscos identificados e classificados como merecedores, dada sua importncia para os objetivos do projeto, de uma resposta ativa. Este somatrio representar a base de referncia de custos do projeto. Significa dizer que se o valor reservado ao plano de contingncia for gasto nas aes do plano no haver estouro de oramento, ou seja este valor faz parte do plano de gerenciamento do projeto. Vide modelo abaixo:
8- Oramento total do Projeto 7- Reserva de Gerenciamento (Trat. Desconhecidos) 6- Base de Referncia de Custos (Cost Baseline) 5- Reservas de Contingncia (Trat. conhecidos) 4- Projeto 3- Contas de Controle 2- Pacotes de Trabalho 1- Atividades
25 25 50 50 100 100
280 280
60 60
220 220
20 20
200 200
100 100
50 50
50 50
50 50
25 25
25 25
25 25
25 25
25 25
25 25
25 25
O item 3 diz respeito a Contas de Controle que devem corresponder s macro entregas do ciclo de vida do projeto e sero as correspondncias que o plano de contas da contabilidade da organizao e o projeto podero fazer sua conciliao.
PLANEJAMENTO DA QUALIDADE DO PROJETO A elaborao do Plano de Gerenciamento do Projeto prossegue e, neste ponto do processo, j devem ter sido definidos o escopo, o tempo e o custo do projeto. Ou seja, as trs principais variveis determinantes do projeto. Outros elementos do plano, porm, ainda no tero sido tratados o que significa que as definies anteriores podero e devero ser reformuladas, uma vez que o processo de elaborao do plano de fato interativo. A seqncia segue uma ordem lgica, mas que deve comportar idas e vindas.
Antes de tudo, importante lembrar que qualidade s pode ser entendida se referenciada a um padro. Isto , no existe qualidade absoluta, mas sim qualidade requerida por algum (sujeito) que espera atendimento dos seus requisitos dentro de certas margens de tolerncia. Estas margens de tolerncia so os limites, fronteiras do padro da qualidade requerida. Plano de Gerenciamento da Qualidade Assim sendo, o plano de gerenciamento da qualidade do projeto deve levar em considerao este cenrio. A fim de encontrar a melhor estratgia para atender s expectativas do cliente deve empreender todos os esforos possveis para descobrir quais so estas expectativas, explicit-las, para, em seguida, encontrar os meios de
64
atend-las. O gerenciamento da qualidade do projeto, segundo o Guia PMBOK, definido como sendo: os processos que cuidam das atividades da organizao
executora que determinam as responsabilidades, os objetivos e as polticas de qualidade para que o projeto satisfaa as necessidades para as quais foi criado.
O plano de gerenciamento da qualidade definir padres e processos que garantam a qualidade do projeto. Determinar como sero tratados a garantia dos processos e o controle da qualidade do produto do projeto. Deve definir, tambm, as responsabilidades especficas dos membros da equipe para conduzir as aes do gerenciamento da qualidade. Quem liderar cada processo, quem far inspees, quem aprovar, autorizar etc. Anlise de Custo x Benefcio O conceito de qualidade enunciado pela ISO 9000:2000 de que qualidade : o
grau no qual um conjunto de caractersticas inerentes satisfaz aos requisitos.

Portanto, no h qualidade absoluta ou total. Em meados dos anos 80, o termo Qualidade Total foi interpretado equivocadamente como sendo qualidade absoluta, quando deveria significar que a totalidade da organizao deve buscar a qualidade como objetivo e no apenas aqueles que tinham como funo zelar pela qualidade. Assim sendo, necessrio, para o planejamento da qualidade do projeto, identificar qual a melhor relao entre as necessidades do cliente e os custos envolvidos para atender a estas necessidades. Haver um ponto de equilbrio indicando que a partir de um determinado ponto, no haver valor percebido pelo cliente.
Nvel de Atendimento aos requerimentos
Gold P lating No Requsitado No Esperado No Contratado
Requisitos do P rojeto (CLIENTE) Valor Esperado (contratado)
Oramento do P rojeto
Custo da Qualidade
As entregas que excederem ao limite do contratado sero consideradas formalmente, alm do requisitado, do esperado pelo cliente. No foi pedido pelo cliente. O jargo da comunidade de gerenciamento de projetos denomina esta prtica de gold plating. Em uma traduo livre, seria a gria: dourar a plula.
65
Significa que no faz parte do escopo muito menos dos requisitos acordados formalmente. No uma boa prtica de gerenciamento de projetos entregar alm do requisitado, pois a premissa de que seja elaborado um plano que atenda aos requisitos e que este plano seja executado. Qualquer diferena a mais ou a menos que no seja fruto da incerteza inerente a qualquer projeto, ou seja, movimentos intencionais de modificaes do plano ser uma quebra do acordo feito com o cliente. Determinao dos Padres da Qualidade do Projeto A qualidade precisa de uma referncia de avaliao. Esta referncia o padro da qualidade que deve ser estabelecido pelo cliente do projeto. funo do gestor do projeto identificar este padro e persegui-lo. Cada padro, porm, possui uma probabilidade de ser atingido que depender das caractersticas de processamento e gerao do produto. Esta probabilidade, ou possibilidade, de cumprimento do padro que deve ser reconhecida e aceita pelo cliente ser tratada como TOLERNCIA. Portanto, necessrio para estabelecer os acordos relacionados qualidade que sejam determinantes do padro, ou seja a tolerncia do cliente variabilidade dos resultados das entregas. Na figura abaixo temos a descrio de um padro, ou tolerncia, para a fabricao de uma pea mecnica. Esta , certamente, uma situao de grau de facilidade alto para a determinao destas variveis, pois quanto mais abstrato for o objeto da entrega mais difcil a determinao dos padres e tolerncias envolvidos. o caso por exemplo de projetos que geram solues para um problema, ou melhorias. O que no exime o gestor do projeto de faz-lo.
Tolerncia = PADRO DA QUALIDADE
DD D
D+
Procedimentos, mtricas e indicadores da qualidade Uma vez que tenham definidos os padres de referncia do projeto ser preciso determinar os procedimentos necessrios para que eles sejam atingidos, assim como
66
as unidades de medida, mtricas, para cada parmetro da qualidade e os indicadores que permitiro monitorar o quanto eles estaro sendo cumpridos e tomar as medidas preventivas e corretivas necessrias. A medida da qualidade do projeto ser a medida do cumprimento dos parmetros estabelecidos nas variveis de escopo, tempo de custo do projeto. Cada especificao do projeto passa a ser uma referncia a ser seguida e medida da qualidade do projeto. A determinao de que uma parede em um projeto de construo de uma casa ser pintada com uma tinta especfica e com uma determinada densidade so itens de escopo, mas a medida do cumprimento destas especificaes, isto , a garantia de que a tinta e a densidade especificadas sejam cumpridas assunto do gerenciamento da qualidade.
PAPIS E RESPONSABILIDADES DAS PESSOAS NO PROJETO Atividades e ramos da economia, conforme sua natureza, so intensivos em capital, caso das instituies financeiras, intensivos em tecnologia, caso das empresas de telecomunicaes, intensivas em equipamentos caso de empresas que dependam fortemente de mquinas, etc. Projetos so intensivos em pessoas. Significa que o sucesso de um projeto depende diretamente do desempenho das pessoas que o realizam. O planejamento dos recursos humanos do projeto tem como objetivo criar o Plano de Gerenciamento de Pessoal que estabelece a forma como as pessoas do projeto sero incorporadas, organizadas, distribudas pelas partes do projeto, como sero capacitadas e coordenadas para alcanarem os objetivos do projeto. Contratao ou Mobilizao da Equipe do Projeto De acordo com os requisitos de desempenho do projeto o plano indicar critrios e processos necessrios para a busca e a escolha dos profissionais que integraro a equipe do projeto. O tipo de vnculo que o profissional ter com o projeto, ser determinado pela sua origem. Se for pessoal da prpria organizao ser uma mobilizao, mas se for externo organizao executora do projeto ser uma contratao. Para tal necessrio que o gestor do projeto identifique as competncias que a equipe deve ter a fim de realizar as atividades do projeto necessrias ao seu sucesso. A primeira dificuldade na identificao de competncias reside no fato de que competncia diferente de qualificao, isto , competncia segundo Felipe Perrenoud (1999), Capacidade de agir eficazmente em um determinado tipo de situao, apoiando-se em conhecimentos, mas sem limitar-se a eles. O currculo do profissional apresenta conhecimentos adquiridos em formao acadmica e experincias anteriores, mas no consegue garantir que ele seja competente para a atividade requerida.
67
O conhecimento um dos componentes da competncia, assim como as habilidades que so desenvolvidas na prtica de atividades que requeiram a aplicao de tcnicas conhecidas. De forma simplificada competncias podem ser definidas como o conjunto de conhecimentos, habilidades e atitudes de um profissional. Esquematicamente podese dizer que conhecimentos so o saber, as habilidades o saber fazer, e as atitudes o querer fazer. Este ltimo elemento refere-se ao posicionamento que o profissional frente aos desafios das atividades. Nele esto contidos o comprometimento, o envolvimento e a motivao para agir no momento adequado mobilizando conhecimentos e habilidades. A identificao de competncias necessrias execuo do projeto assim como dos potenciais membros da equipe de um projeto no da tarefa trivial. Exige, portanto, que o gestor do projeto invista esforo considervel j que uma equipe competente fator crtico de sucesso para o projeto. As competncias necessrias ao projeto precisam ser traduzidas de forma mais explicita e prtica possvel atravs da anlise da natureza de cada tarefa. Por exemplo, ser necessrio elaborar um cronograma composto de: um grfico de Gantt e de um Diagrama de Rede inseridos em um calendrio, utilizando o software X. O profissional candidato posio precisa ser capaz de executar esta atividade utilizando a referida ferramenta. Aps a identificao das competncias exigidas para execuo de cada tarefa o gestor deve especificar o conjunto de competncias que sero necessrias para cada profissional do projeto, determinando, assim um perfil desejado. Este perfil profissional desejado ser o instrumento que servir de guia para a busca na prpria organizao, para uma mobilizao, ou no mercado, para uma contratao. Uma vez recrutados os candidatos, ser necessria a seleo. Para esta etapa, Seguindo uma orientao focada em competncias, o gestor do projeto pode solicitar que o candidato se submeta a um teste ou que obtenha informaes de fontes abalizadas que atestem seu desempenho em tarefas equivalentes s que sero necessrias, ou seja, que obtenha uma comprovao das competncias e no haja apenas uma demonstrao de currculos. Organograma e Matriz de Responsabilidades do Projeto Como resultado estruturado do processo de especificao das pessoas em suas respectivas posies, atribuies e relaes hierrquicas um organograma e uma matriz de atividades por pessoas alocadas no projeto, conhecida como Matriz de Responsabilidades.
68
Sponsor Sponsor Sponsor do do Projeto Projeto
Gerente Gerente do do Projeto Projeto
Apoio Apoio Apoio Adm Adm
Resp. Resp. Resp.Fase FaseA A
Resp. Resp. Fase FaseB B
Resp. Resp.Contratos Contratos
Consultor Consultor
Membro Membro 1 1
Membro Membro 2 2
Membro Membro 3 3
Resp Resp. . Ent Ent. .n Resp. Ent. n
Organograma do Projeto
- Resp. Atividade A - Resp. Atividade B - Resp. Atividade n
No organograma devem estar demonstradas as relaes de subordinao funcional no projeto. Devem estabelecer o papel de todas as pessoas que participaro ativamente no projeto, inclusive pessoas externas organizao executora. Para deixar claro que este organograma do projeto e no reflete necessariamente a hierarquia da empresa, costuma-se denomin-lo de organograma virtual do projeto. A matriz de responsabilidades tem uma abordagem mais operacional, pois as referncias so as atividades do projeto e o papel que cada membro da equipe do projeto desempenho em relao a elas. Alguns princpios devem nortear a elaborao da matriz, entre eles o da unicidade de comando. Isto , cada atividade deve ter apenas um responsvel. Mesmo que haja dois membros da equipe que dividam a responsabilidade pela execuo da atividade, recomendvel que o gerente do projeto nomeie um deles como o responsvel.
Matriz de Responsabilidades do Projeto
69
PLANEJAMENTO DAS COMUNICAES DO PROJETO O recente estudo de benchmarking realizado pelo PMI aponta a comunicao um problema importante em projetos. Um dos principais fatores de fracassos em projetos. Tratar as comunicaes de forma planejada, portanto, um caminho para diminuir a probabilidade de dificuldades no gerenciamento do projeto. Projeto algo que precisa ser criado para resolver um problema ou aproveitar uma oportunidade. Estas necessidades ou requisitos precisam ser transmitidos, comunicados, a quem ser encarregado de realiz-lo. Sendo assim, a comunicao elemento chave neste relacionamento que dever identificar os objetivos e definir o escopo do projeto. Portanto, se analisadas em mais profundidade as causas de objetivos, escopo e outras varveis de projeto mal definidos, pode-se chegar com freqncia ao componente comunicao como fator preponderante. Muitos dos problemas ligados comunicao so identificados pela compreenso dos elementos presentes no processo, conforme demonstra a figura a seguir.
Modelo Bsico de Comunicao (fonte: Guia PMBOK, 2008)
A partir deste modelo fundamental deixar claro que a responsabilidade pela qualidade, eficcia, da comunicao do emissor. Ou seja, de quem transmite a mensagem. Sendo assim, ele deve cuidar para que eventuais desvios, diferenas, rudos, barreiras ou lacunas na comunicao no ocorram. E se ocorrerem dar o melhor tratamento. Jogar a responsabilidade pela no compreenso da mensagem para o receptor, no prtica recomendvel. Ponto sensvel em ambientes de projeto, a escolha do cdigo utilizado pelo emissor para encapsular a mensagem fator decisivo na eficcia da comunicao. O cdigo escolhido pelo emissor deve ser de domnio do receptor. Como guardio da eficcia da comunicao, o emissor, antes de mais nada, deve certificar-se de que o receptor domina o cdigo que ser usado na transmisso da mensagem. Jarges tcnicos de domnio de ambientes tecnolgicos restritos, com siglas e abreviaturas especficas, muito comuns em projetos de reas intensivas em tecnologia, so pontos de ateno para cdigos desconhecidos pelo receptor. A presuno de que o jargo deve ser dominado, por quem do meio, perigosa. Projetos so atividades de relacionamentos internos e externos organizao executora. Hoje, dado o grau de especializao tecnolgico e a velocidade das
70
mudanas, profissionais de uma mesma rea podem ter srias dificuldades de compreender os termos usados na comunicao de um projeto. O problema se agrava se levarmos em considerao a interao que os executores de projetos precisam ter com membros da alta direo empresarial. Um diretor recm contratado pela organizao pode se sentir constrangido em demonstrar desconhecimento de um jargo e por isso no externar que no compreendeu adequadamente uma informao valiosa para sua tomada de deciso. O mesmo pode ocorrer com um fornecedor ou outro stakeholder do projeto. Assumindo o papel de responsvel pela eficcia da comunicao no projeto o emissor deve, inclusive procurar garantir que o retorno (feedback) dado pelo receptor seja ativo. Feedback ativo, no o mesmo que o receptor responder entendi, porque pode ter sido entendido algo diferente do contedo que o emissor desejava comunicar. Feedback ativo, portanto, requer a confirmao do significado da mensagem nas palavras do receptor, afim de que seja possvel ao emissor verificar se houve divergncia entre o que foi entendido e o que precisava ser comunicado. A ttulo de exemplo de uma estratgia para provocar feedback ativo de stakeholders importantes tais como o cliente ou o sponsor, o gestor do projeto, durante uma entrevista de levantamento de requisitos ou de definio de escopo, pode testar o entendimento, induzir ao feedback ativo, lendo em voz alta o que foi acertado e anotado e solicitando ao interlocutor que identifique alguma divergncia. Portanto, o planejamento das comunicaes do projeto dever determinar: O que deve ser comunicado. Que documentos e informaes do projeto devem ser transmitidas. O Termo de Abertura, a declarao do escopo, o plano de gerenciamento do projeto, variaes de prazo, de custo, novos riscos identificados, mudanas, etc. Quem deve enviar e receber a comunicao. Os stakeholders (partes interessadas) do projeto devem ser o alvo de um plano de comunicao de um projeto. A boa tcnica da comunicao recomenda, para maior eficcia, a seletividade. Isto , a comunicao deve ser direcionada ao receptor especfico. Se a comunicao no for seletiva pode causar o efeito que os e-mails spam (comunicao em massa). A distribuio indiscriminada, no seletiva, desvaloriza tanto a mensagem quanto o emissor. Outras mensagens do emissor no seletivo tendem a ser desconsideradas. Este processo, portanto, depende de um bom mapeamento, identificao precisa das necessidades e interesses, de cada stakeholder do projeto. Quando deve ser feita a comunicao. A periodicidade ou momentos especficos do projeto que deve ser realizada. Uma vez que o princpio do planejamento prevalea e o plano de gerenciamento do projeto determine um ciclo de controle, o calendrio de reunies de progresso programadas j deve ser divulgado a quem delas ir participar.
71
Como ser feita a comunicao. Que meios ou canais sero utilizados a fim de que haja maior eficcia. Aqui tambm, o princpio da seletividade se faz necessrio. Cada informao a ser comunicada a um stakeholder especfico deve ser entregue pelos meios, canais, ou veculos especficos. Determinada informao para alguns stakeholders pode ser suficiente a publicao em um jornal de grande circulao ou em um dirio oficial regional. Para outro stakeholder pode ser mais indicado uma apresentao presencial em sua prpria sala. Cabe ao gestor do projeto, apoiado pelo sponsor, identificar estas especificidades que so fatores crticos de sucesso para a comunicao do projeto.
Documento Termo de Abertura
Stakeholder Sponsor, Cliente, Equipe, Gerentes Funcionais,... Sponsor e Equipe Sponsor e Cliente Sponsor, Cliente, Equipe Gerentes Funcionais Sponsor, cliente e equipe Equipe
Quando? Na abertura do projeto
Como? Cpia em papel entregue em mos Cpia em papel entregue em mos Cpia em papel entregue em mos Cpia em papel entregue em mos Memorando interno Cpia em papel entregue em mos E-mail E-mail (...)
Plano do Projeto Contrato WBS Cronograma de Utilizao de recursos Riscos Identificados
Na conluso do planejamento Na assinatura do contrato Na gerao do documento No trmino do planejamento Na abertura do projeto e na concluso do plano Na identificao de novos riscos Na identificao de problemas
Problemas identificados (...)
Equipe (...)
Matriz de Comunicaes
GERENCIAMENTO DOS RISCOS DO PROJETO Risco de projeto, segundo o Guia PMBOK, um evento ou condio incerta que, se ocorrer, ter um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade. Projetos so atividades probabilsticas e no determinsticas, isto , seus resultados possuem considervel grau de incerteza. Projetos so realizados para a criao de algo que no existe ou para a aplicao de uma soluo a um problema presente. Em ambos os casos no possvel garantir com absoluta certeza que acontecero. So eventos futuros sobre os quais possvel, no mximo, fazer estimativas e previses com taxas de probabilidades associadas. Neste cenrio o gerenciamento dos riscos constitui-se no conjunto de processos que aumentem a possibilidade de sucesso do projeto, aumentando a probabilidade e o impacto dos riscos positivos, e diminuir a probabilidade e o impacto dos riscos negativos do projeto. Aumentar a dimenso das oportunidades, ou fatores favorveis
72
ao projeto alcanar seus objetivos e diminuir as ameaas, ou fatores desfavorveis ao alcance dos objetivos do projeto. Um risco origina-se de uma fonte, o evento materializa-se por uma causa que gera conseqncias, impactos nos objetivos do projeto.
Configurao do Risco em projetos
O evento ser potencial, portanto, risco, se possuir uma probabilidade de ocorrncia. Se a probabilidade for nula no ser considerado como hiptese, ou se for de 100% ser um fato que pode configurar-se como uma certeza, restrio ou irrelevante para o projeto. Havendo probabilidade de ocorrncia e a presuno de que o evento venha a causar impactos, efeitos nos objetivos do projeto, ser considerado risco. Portanto, um risco deve ser avaliado sempre considerando-se as duas variveis: a probabilidade e o impacto. Plano de Gerenciamento dos Riscos O planejamento do gerenciamento dos riscos produzir um plano que determinar como sero realizados os demais processos do gerenciamento dos riscos, que so: Identificar os riscos Realizar a anlise qualitativa de riscos Realizar a anlise quantitativa de riscos Planejar respostas aos riscos Monitorar e controlar os riscos Determinar, tambm, a abordagem, estratgia, que ser dada aos riscos de acordo com suas caractersticas: se pr-ativa, agindo antecipadamente, ou reativa, agindo se e quando, o evento incerto ocorrer. Imediatamente aps a elaborao do plano de gerenciamento dos riscos, ainda no processo de planejamento, ser necessrio realizar os processos do gerenciamento dos riscos, exceto o de monitoramento e controle dos riscos que ser realizado ao longo do processo de execuo do plano de gerenciamento do projeto. Identificar os riscos Determinao, atravs de uma abordagem organizada, dos riscos positivos e negativos que podem afetar os objetivos do projeto. Este processo envolve, tambm, o levantamento e documentao de informaes que caracterizem os eventos ao ponto de permitir aes especficas sobre eles.
73
Para um melhor resultado neste processo, visto que envolve a identificao de hipteses de eventos potenciais, recomendvel utilizar mtodos de trabalho em grupo que estimulem a criatividade, tais como brainstorming, delphi, modelagens mentais e de associao de idias, diagramas de causa e efeito (Ishikawa), anlise de Foras, Oportunidades, Fraquezas e Ameaas (SWOT Strengths, Weaknesses, Opportunities, and Threats) etc. Modelos de categorizao elaborados no planejamento dos riscos, tais como estruturas hierrquicas em forma de organogramas, neste caso, denominadas de estrutura analtica de riscos (EAR), podem ajudar na induo de identificao de riscos. O principal resultado do processo de identificao de riscos um documento denominado Registro de Riscos (Risk Register) que contm a lista de riscos, com suas respectivas causas, efeitos e potenciais respostas. Dicas para documentar bem os riscos do projeto: 1. Descrever o risco de maneira estruturada, utilizando uma descrio em 3 partes: Devido a <uma ou mais causas>, <risco> poder ocorrer, o que levaria a <um ou mais efeitos>. 2. Quanto mais especfica for a descrio do evento de risco, mais facilmente conseguiremos planejar uma resposta e monitor-lo posteriormente. Descrio genrica de um risco: Devido situao atual do cliente, podero ocorrer mudanas de escopo, o que levaria a um atraso do projeto. Descrio especfica de um risco: Devido quantidade de dvidas do cliente em relao s possibilidades de utilizao do ambiente a ser construdo, poder ocorrer um aumento na rea de construo prevista originalmente para o auditrio, o que levaria a um atraso na fase de desenho do projeto. 3. Quando possvel, identifique alertas (triggers) que indiquem que o risco est prestes a ocorrer. Eles o ajudaro futuramente no monitoramento e controle daquele risco. Descrio do Risco: Devido falta de experincia do pessoal com o equipamento XYZ, um desempenho ruim na execuo dos testes deste equipamento poder ocorrer, o que levaria a um aumento da durao prevista dos testes, que de 20 dias. Alerta: Progresso dos testes inferior a 20% aps 4 dias de teste. 74
Exemplo de EAR (Estrutura Analtica de Riscos)
Realizar a anlise qualitativa de riscos Priorizao dos riscos identificados para anlise ou ao adicional subseqente atravs de avaliao e combinao de sua probabilidade de ocorrncia e impacto.
Classificao para priorizao dos riscos em funo da probabilidade e do impacto
75
Para o processo de anlise qualitativa de riscos podem ser utilizadas escalas relacionadas s duas principais variveis do risco: a probabilidade de ocorrncia e o impacto sobre os objetivos. A ferramenta denominada Matriz de Probabilidade x Impacto permite uma melhor visualizao da classificao dos riscos do projeto. Os graus ou as faixas das escalas de probabilidade e de impacto devem ser determinados de acordo com o perfil de tolerncia ou averso a riscos da organizao executora do projeto.
Exemplo de Escala de PROBABILIDADES
Exemplo de Escala de IMPACTOS
76
Exemplo de MATRIZ DE PROBABILIDADE X IMPACTOS (P x I)
Na matriz os eventos so posicionados de acordo com as estimativas de probabilidade e impacto a fim de que sejam classificados segundo o produto das duas variveis. Esta classificao servir de orientao estratgia de resposta que ser elaborada no processo de Planejamento de Resposta aos Riscos. Os riscos com classificao ALTA, por exemplo, alta probabilidade e alto impacto podem ser considerados de prioridade mxima e exijam tratamento agressivo. J para os de classificao BAIXA, a estratgia pode ser passiva, ou seja, apenas monitor-los a partir de uma lista de observao (Watchlist). Realizar a anlise quantitativa de riscos Anlise numrica do efeito dos riscos identificados nos objetivos gerais do projeto. Tem por objetivo analisar numericamente os riscos mais significantes estabelecidos durante a anlise qualitativa, e a interao entre eles, para estimar a faixa de possveis resultados para o projeto como um todo. Este processo utiliza tcnicas como a simulao de Monte Carlo e a anlise da rvore de Deciso para: Quantificar os possveis resultados do projeto e suas probabilidades Avaliar a probabilidade de atingir objetivos especficos do projeto Identificar os riscos que exigem mais ateno quantificando sua contribuio relativa para o risco total do projeto. Identificar metas realistas e alcanveis de custo, cronograma ou escopo, quando fornecidos os riscos do projeto Determinar a melhor deciso de gerenciamento de projetos Planejar respostas aos riscos Desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto. Formas de responder a riscos NEGATIVOS de um projeto: Eliminar o risco, planejando uma forma de exclu-lo completamente. 77
Mitigar o risco, buscando uma forma de reduzir a probabilidade de sua ocorrncia ou do seu impacto, caso o mesmo venha a ocorrer. Transferir o risco, normalmente repassando-o para um terceiro. Formas de responder a riscos POSITIVOS de um projeto: Explorar o risco, eliminando a incerteza associada a um risco positivo fazendo com que a oportunidade efetivamente acontea. Melhorar o risco, modificando o tamanho da oportunidade aumentando a probabilidade e/ou impacto (valor esperado) do risco positivo. Compartilhar o risco, atribuindo a sua propriedade a terceiros que possam capturar melhor a oportunidade do risco acontecer em benefcio do projeto. Formas de responder a riscos POSITIVOS e NEGATIVOS de um projeto: Aceitar Ativamente, buscando se preparar com reservas de tempo ou de dinheiro caso o risco venha a ocorrer. Aceitar Passivamente, simplesmente no fazendo nada e torcendo para que o risco no venha a ocorrer. Respostas de Contingncia, elaborando planos de contingncia que s sero executados se algum alerta, sintoma ou trigger (gatilho) ocorrer, ou se o prprio risco ocorrer.
Estratgias de Resposta aos Riscos
78
Dicas para documentar bem um plano de respostas a riscos: 1. Planos de resposta a riscos devem ser mais do que simples desejos de que as coisas dem certo. Plano de ao ou apenas um desejo?: Garantir que o equipamento seja entregue no prazo.
Plano de ao objetivo: Negociar com o fornecedor visitas quinzenais fbrica para verificao do progresso da fabricao do equipamento. Disponibilizar linha de comunicao direta (hot-line) com a fbrica para agilizar comunicao de eventuais problemas durante a fabricao.
2. Evite que os planos de resposta descrevam apenas o que j parte das atividades cotidianas do trabalho. Descrio do Risco: Quebra da alavanca cdigo BHYZPT durante instalao do quadro eltrico n 21A. Plano de ao ou trabalho do dia-a-dia?: Seguir as especificaes de instalao do quadro eltrico.
O que poderia ser feito de diferente, em relao ao que j costume, para mitigar ou prevenir a ocorrncia do risco? 3. Cuidado com aes de resposta que exijam acompanhamento durante toda a extenso do projeto: Em lugar de: Prefira: Elaborar procedimento para acompanhamento das atividades do fornecedor atravs de gesto integrada. Acompanhar as atividades do fornecedor atravs de gesto integrada.
Monitorar e controlar os riscos Acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificao dos novos riscos, execuo de planos de respostas a riscos e avaliao da sua eficcia durante todo o ciclo de vida do projeto.
79
80
PROCESSOS DE AQUISIES O projeto precisa de recursos para conseguir realizar seus objetivos. Dessa forma, os processos de aquisio determinaro como ser a aquisio de bens e servios de fora da organizao executora do projeto. Planejar Aquisies Realizar Aquisies Administrar Aquisies Encerrar Aquisies Deciso de Comprar ou Fazer (Make or Buy) Como parte do processo de planejamento das aquisies, necessrio analisar as alternativas para cada recurso necessrio ao projeto entre adquirir de fora da organizao ou produzir internamente. Considerar prs e contras, preferencialmente utilizando mtodos de tomada de deciso. Indicaes de FAZER Facilidade de integrao com operaes de rotina Utilizao de capacidade ociosa Falta de fornecedores confiveis Necessidade de controle direto Indicaes de COMPRAR Fornecimento especializado Pequenos volumes Capacidade limitada Ampliar leque de fornecedores Transferncia de risco ao fornecedor Seleo do Tipo de Contrato 1- Contratos com Preo Fixo e com Pagamento Integral 2- Contratos com Reembolso de Despesas 3- Contratos de Mo-de-Obra e Material Especificao do Servio (SOW Statement of Work) A fim de que as necessidades especficas do projeto sejam atendidas importante identificar todas as caractersticas de cada item a ser adquirido. Neste momento do projeto o gestor do projeto estar atuando como um cliente. Quanto mais especificaes forem passadas aos fornecedores maiores sero as chances de que as aquisies sejam adequadas. O nvel de definio do escopo de cada parte do projeto determinar a possibilidade de especificao da aquisio e conseqentemente do modelo de contrato que poder ser firmado. Se o escopo no estiver bem definido o contrato dificilmente poder ser por preo fixo, o que acarreta mais risco para o comprador, neste caso o gestor do projeto.
81
Critrios e Mtodos de Avaliao de Fornecedores A melhor prtica de aquisies recomenda que se utilizem mtodos de tomada de deciso que diminuam a subjetividade da escolha de fornecedores. Esta prtica pode diminuir, tambm, a influncia do fator preo sobre a escolha do fornecedor, o que em muitos casos no sinnimo de qualidade nem de melhor soluo tcnica.
APROVAO DO PLANO DE GERENCIAMENTO DO PROJETO Todo este trabalho que at agora analisamos de desenvolvimento do plano de gerenciamento do projeto precisou ser AUTORIZADO. Autorizao esta necessria para que o gestor do projeto e, dependendo da situao, uma equipe de gerenciamento do projeto, pudessem trabalhar na configurao do plano de gerenciamento do projeto. O trabalho de desenvolvimento foi AUTORIZADO, entretanto o plano desenvolvido precisa ser APROVADO. A instncia aprovadora do plano de gerenciamento do projeto depender de cada projeto. Tipicamente, o Patrocinador (Sponsor) do projeto teria esta prerrogativa, mas pode ser aprovado por uma diretoria ou constitudo um comit especialmente para esse fim. Cabe lembrar que a aprovao do plano pressupe a concordncia com todos os parmetros do projeto incluindo, prazo e oramento. Conceitualmente, a partir de sua aprovao, o plano de gerenciamento do projeto passa a representar a referncia para a execuo do projeto, a linha de base do projeto (Project baseline). A integridade desta referncia, linha de base, passa a ser responsabilidade do gestor do projeto, isto , uma vez aprovado o plano, criada a linha de base, toda mudana em qualquer dos parmetros do projeto deve ser tratada como modificao do plano. Significa que dever ser conduzido um processo de aprovao das mudanas pelas instncias autorizadas para tal. REUNIO DE PARTIDA DA EXECUO DO PROJETO KICKOFF MEETING A boa prtica recomenda que o incio da execuo do plano de gerenciamento do projeto seja marcado, isto , COMUNICADO aos principais stakeholders do projeto e organizao executora como um todo. Este pontap inicial tem a finalidade de esclarecer dvidas relacionadas ao plano de gerenciamento do projeto, a estratgias utilizadas, sistemas de controle adotados, pontos crticos, objetivos especficos, metas, enfim, o momento e a oportunidade de confirmar a participao e o comprometimento dos principais envolvidos com os objetivos do projeto e angariar apoio de reas fornecedoras de recursos.
82
Execuo, Monitoramento e Controle do Projeto

Uma vez elaborado o plano de gerenciamento do projeto, necessrio realiz-lo, cumpri-lo. Esta afirmativa est longe de ser uma obviedade, porque comum que no calor dos acontecimentos o plano seja esquecido e o processo de execuo passe a ser uma sucesso de improvisos. O processo de execuo consiste na integrao das pessoas e recursos materiais para realizar o plano de gerenciamento do projeto. A concentrao dos esforos necessrios para atingir os objetivos estabelecidos para o projeto. Os processos de monitoramento e controle ocorrem desde o primeiro momento do projeto, porm, quando o plano estiver sendo executado, as exigncias de monitorar, isto , verificar como est sendo executado o plano, e quando necessrio, tomar medidas corretivas, ou seja, controlar, tornam-se mais prementes. A execuo do projeto envolve essencialmente: Executar, seguir o PLANO DE GERENCIAMENTO DO PROJETO Realizar o ESCOPO do projeto Entregar os PRODUTOS INTERMEDIRIOS Gerenciar os RECURSOS Gerenciar MUDANAS Corrigir DESVIOS Atualizar o PLANO DE GERENCIAMENTO DO PROJETO
Equipe de execuo do projeto o momento de incorporar os membros da equipe que o plano de gerenciamento de pessoal determinou como necessria realizao do projeto. Mobilizar, se for pessoal interno organizao ou contratar, se forem externos. Em ambos os casos o gestor dever apia reas de suporte no recrutamento, conduzir entrevistas e avaliar as competncias dos candidatos.
83
Faz parte das atribuies do gestor neste momento do projeto, o desenvolvimento de competncias que ainda no estejam plenamente incorporadas pelos membros da equipe, seguindo estratgias e mtodos de desenvolvimento profissional. Ciclo de Controle do Projeto A freqncia com que o projeto ser, de forma programada, monitorado e controlado pode ser decisivo para o sucesso do projeto, pois determinar o nvel de esforo empreendido nestes processos. Ciclo muito frequente Mais uma vez coloca-se uma situao em que faz-se necessrio encontrar o ponto de equilbrio, pois uma frequncia muito alta ir requerer um esforo que talvez inviabilize o trabalho de monitoramento e controle. Pode inviabilizar, por exemplo, a atualizao dos documentos do projeto. Levando situao na qual o controle excede o objeto controlado, princpio de Henry Fayol, que em outras palavras, significa consumir mais esforo para monitorar e controlar do que para fazer.
Ciclo pouco frequente Por outro lado, demorar para monitorar o projeto pode levar a desvios de tal ordem que no possam mais ser corrigidos, isto , no seja mais possvel s aes corretivas fazerem o projeto voltar sua linha de base. Desvios impossveis de serem corrigidos levam necessidade de mudana para que o projeto continue com uma linha de base factvel. Uma linha de base que sirva, efetivamente de referncia para a execuo do projeto.
84
O monitoramento e controle do projeto A cada ponto do ciclo de controle de acordo com o previsto no plano de gerenciamento do projeto devem ser realizadas medies para a coleta de dados para a determinao do status do projeto. A data em que as medies so realizadas denominada DATA DATE (Data dos Dados). A sequncia de grficos, a seguir,
As atividades em vermelho pertencem ao caminho crtico. No primeiro ponto do Ciclo de Controle (C1), na DATA DATE, os dados de execuo do projeto devero ser
85
Dados coletados: Atividade A concluda e sem variao de custo
Os dados indicam, portanto que no primeiro Ciclo (C1) o projeto est de acordo com o planejado. Cronograma e Oramentos cumpridos. No segundo ponto do Ciclo (C2)
Impactos no PRAZO
1- Atraso na Atividade B (Caminho Crtico) gera atraso no projeto 2- Atraso na Atividade C no gera atraso por ter FOLGA de 5 dias
CRONOGRAMA ATRASADO Impactos no CUSTO

1- Atividade B gastou mais 20% do orado para fazer apenas 80% de 100% planejados 2- Atividade C gastou mais 30% do orado para fazer apenas 30% de 50% planejados
ORAMENTO ESTOURADO
Se nenhuma ao corretiva for tomada o projeto sofrer os impactos totais identificados, mas papel do gerente do projeto identificar aes que neutralizem ou
86
minimizem os impactos dos desvios e tragam o projeto as previses de prazo e custo originais, ou seja, voltar linha de base.
87
GERENCIAMENTO DO VALOR AGREGADO EARNED VALUE MANAGEMENT O ponto de partida para medidas de gesto efetivas uma correta avaliao do desempenho do projeto. Uma forma estruturada de avaliar o desempenho de projetos a tcnica do Gerenciamento do Valor Agregado, que oferece uma ampla viso dos desvios existentes, tanto de custo como de prazo, utilizando como base informaes de custo do AVANO FSICO ou ESCOPO REALIZADO. O Valor agregado tem foco na relao entre CUSTOS reais incorridos e o trabalho realizado no projeto (ESCOPO) dentro de um determinado perodo de TEMPO. O foco est em comparar o quanto foi efetivamente gasto com o quanto foi efetivamente produzido (agregado Avano Fsico ESCOPO realizado) e no o quanto foi gasto com o quanto se esperava gastar. Valor agregado pode ser definido como a avaliao entre o que foi obtido em relao ao que foi realmente gasto e ao que se planejava gastar, onde se prope que o valor a ser agregado inicialmente para uma atividade o valor orado para ela. Na medida em que cada atividade realizada, aquele valor inicialmente orado para a atividade passa, agora, a constituir o Valor Agregado do Projeto. O EVM como conhecido o mtodo do Gerenciamento do Valor Agregado, portanto, disponibiliza um sistema de controle gerencial unificado confivel, propicia a integrao do trabalho, prazos e custos utilizando a EAP do projeto (WBS) e permite anlises comparativas com projetos j concludos. O EVM permite ao gerente do projeto responder a perguntas como: O cronograma est adiantado ou atrasado? O oramento est acima ou abaixo? A ttulo de exemplo, consideremos um projeto com durao de 7 meses e que possua trs fases. Cada uma com seu oramento especfico, e os valores, em Reais, acumulados ao fim de cada fase e do projeto. Poderamos representar estes valores no grfico da Curva S do projeto.
88
Ao final do segundo ms, no primeiro ciclo de controle (C1), efetuada a verificao e constata-se que o que estava previsto foi efetivamente realizado. Sendo assim, o avano fsico foi de 100%. Podemos considerar, portanto, que o valor agregado ao
Quanto ao avano fsico o projeto est em dia, isto , o cronograma est sendo cumprido. Entretanto, ao verificarem-se os gastos reais, constatou-se que foram de R$ 1.200. Ou seja, R$ 200. acima do oramento de R$ 1.000. para a fase.
89
Entretanto, ao final do quinto ms, no segundo ciclo de controle (C2), as medies indicam que apenas metade do que estava planejado foi efetivamente realizado. Significa que o avano fsico foi de 50%, equivalendo a um valor agregado de
Neste ciclo, porm, os gastos reais, o custo real apurado, foi equivalente ao valor agregado, ou seja, os gastos forma proporcionais ao que foi efetivamente realizado. Sendo, ento, de R$ 1.500.
90
Neste ponto, o projeto est atrasado, pois agregou apenas R$ 2.500. quando deveria ter agregado R$ 4.000. e est, tambm, com o oramento estourado, pois gastou R$ 2.700. para agregar apenas R$ 2.500. comum gestores de projetos que no utilizam o EVM interpretarem, erradamente, o gasto real de R$ 2.700. como bom desempenho ao compararem com os R$ 4.000. previstos. Porm a comparao deve ser do gasto real com o valor agregado, ou seja, com o que foi efetivamente realizado. O mtodo do Valor Agregado permite, portanto, uma avaliao da sade do projeto de maneira analtica considerando as principais variveis do projeto: ESCOPO, TEMPO e CUSTO comparadas duas a duas, sempre tendo como ponto de partida o ESCOPO completado, ou avano fsico, ou VALOR AGREGADO. A partir da medio fsica do quanto foi efetivamente realizado em termos de ESCOPO (Avano Fsico), esta grandeza comparada no ponto do tempo (milestone) para avaliar o desempenho de TEMPO e comparada com os gastos reais, CUSTO real, naquele ponto, para avaliar o desempenho de CUSTO do projeto. Indicadores do EVM PV Valor Planejado (Planned Value) (COTA Custo Orado do Trabalho Agendado) Nomenclatura Antiga: BCWS Budget Cost of Work Scheduled O que planejamos executar at esta data? No exemplo: Em C1= 1.000. C2= 4.000. EV Valor Agregado (Earned Value) (COTR Custo Orado do Trabalho Realizado) Nomenclatura Antiga: BCWP Budget Cost of Work Performed Quanto efetivamente executamos do que planejamos? Em C1= 1.000. C2= 2.500. AC Custo Real (Actual Cost) (CRTR Custo Real do Trabalho Realizado) Nomenclatura Antiga: ACWP Actual Cost of Work Performed Quanto efetivamente gastamos naquilo que executamos? Em C1= 1.200. C2= 2.700. BAC Orado na Concluso (Budget at Completion) Qual o valor total orado para o projeto? No exemplo = 5.000. CV Variao de Custo (Cost Variance) CV=EV AC Em C1 = 1.000 1.200 = (- 200). C2 = 2.500 2.700 = (-200) SV Variao de Prazo (Schedule Variance) SV=EV - PV Em C1 = 1.000 1.000 = 0 (sem variao). C2 = 2.500 4.000 = (- 1.500) Variaes Negativas so sinal de ALERTA !!! CPI Indicador de Desempenho de Custo CPI=EV/AC (Cost Performance Index) Em C1 = 1.000 / 1.200 = 0,83. C2 = 2.500 / 2.700 = 0,93 (estourado)
91
SPI Indicador de Desempenho de Prazo SPI=EV/PV (Schedule Performance Index) Em C1 = 1.000 / 1000 = 1 (OK). C2 = 2.500 / 4.000 = 0,63 (atrasado) ndices menores que 1 so sinal de ALERTA !!! ETC Estimado para Completar (Estimated to Completion) Valor total estimado que falta para completar o projeto Quanto falta para completar. Em C1= 5.000 1.000 = 4.000. C2= 5.000 2.500 = 2.500 EAC Estimativa na Concluso (Estimate at Completion) Valor total estimado para o projeto O quanto gastaremos no total NOVO ORAMENTO ETC = BAC EV
EAC = AC + ETC
O quanto gastaremos no total (EAC) ser sempre igual a o quanto j gastamos (AC) + o quanto gastaremos (ETC). Em C1 = 1.200 + 4.000 = 5.200. C2 = 2.700 + 2.500 = 5.200 (estouro de 200)
Parmetros do EVM na Curva S do projeto
92
MTODOS DE MEDIO DO TRABALHO (VALOR AGREGADO) A base de todo o mtodo do Gerenciamento do Valor Agregado (EVM) reside na medio do avano fsico, do escopo completado, trabalho efetivamente realizado. Todos os indicadores partem do valor agregado (EV) para os clculos, portanto a maneira como ser medido o valor agregado precisa seguir mtodos que estabeleam padres confiveis. 12345Percentual (%) completo Marcos Ponderados Frmula Fixa Esforo Associado Nvel de Esforo
Cada mtodo dever ser utilizado de acordo com a natureza da atividade. 1- Percentual (%) completo Pode ser aplicado quando a atividade permite a medio precisa do avano fsico. Caso de atividades cujo trabalho tangvel e de dimenses fsicas expressas em unidades paramtricas. Por exemplo: rea, comprimento, altura, volume, etc. Aps a medio fsica, uma regra de trs permite encontrar o percentual completado do todo. Por exemplo: foram completados 3 metros da pintura de uma parede de 10 metros, portanto, o avano fsico foi de 30%. Em seguida, necessrio calcular o Valor Agregado, que ser o Valor dos 30% completos da pintura da parede. 2- Marcos Ponderados Este mtodo aplicado quando no possvel ter parmetros de dimenses precisas que permitam medir o percentual completo. Consiste em determinar a proporo das partes do todo (100%) que possam ser identificados, marcados, por entregas do projeto. A ponderao, atribuio de pesos que segmentem o todo de forma proporcional, carrega certa dose de subjetividade, pois dependo do julgamento em funo de um parmetro indireto. No caso da construo de uma residncia, o parmetro tempo pode servir de base para a ponderao e determinar a seguinte distribuio por fases: fundaes (10%), estrutura (30%) alvenaria (20%), instalaes (10%) e acabamento (30%). 3- Frmula Fixa Em casos de dificuldade de medio precisa ou de atividades de curta durao, cuja diferena entre medidas no gere conseqncias significativas para a avaliao do desempenho do projeto, pode-se utilizar valores padronizados para estabelecer os percentuais de avano fsico tais como: 20/80 25/75 - 50/50 0/100. O primeiro nmero do padro atribudo quando a atividade comea a ser executada, portanto, no caso do 50/50, quando houvesse a informao de que a atividade foi iniciada seria considerada como estando 50% completa. Ao seu trmino ela receberia os 50% restantes. 4- Esforo Associado Empregado quando uma atividade tem relao direta ou com carter de suporte em relao a outra que denominada base de medida. Caso de atividades de garantia da qualidade, de inspeo ou fiscalizao. Neste caso o valor agregado da atividade associada ser igual ao da atividade base.
93
5- Nvel de Esforo Utilizado para medir o avano de trabalhos indiretos realizados no projeto, tipicamente o trabalho de gerenciamento do projeto ou de suporte ao projeto que no pode ser isolado como contribuinte de uma parte especfica da gerao do produto do projeto. Por conveno adota-se que o Valor Agregado (EV) destas atividades ser sempre igual ao Valor Planejado (PV) para elas. Relatrio de Status Os principais parmetros do desempenho do projeto devem ser periodicamente informados aos principais stakeholders do projeto. A boa prtica recomenda que relatrios de status sejam sintticos e objetivos.
RELATRIO DE STATUS DO PROJETO
Projeto Principais Entregas realizadas % completo do projeto REALIZADO % completo do projeto PLANEJADO Valor Planejado (PV) Custo Real (AC) Valor Agregado (EV) Oramento do Projeto (BAC) Data de Trmino prevista Anterior Atual Data Nmero
Indicadores Variao de Custo (CV) Variao de Prazo (SV) Performance de Custo (CPI) Performance de Prazo (SPI) Estimativa de Custo no Trmino (EAC)c Estimativa de Prazo no Trmino (EAC)t Aes Corretivas
Sinalizador
O relatrio de status deve ser tratado sob duas perspectivas: a situao atual do projeto (status), e as recomendaes de providncias a serem tomadas para que o projeto volte possibilidade de cumprir seus objetivos de escopo, prazo, custo, qualidade, etc. A situao atual uma constatao do desempenho do projeto at o ponto do ciclo de controle, ou data, em que foram realizadas as medies de avano fsico e do custo real do projeto. Dessa forma, a equipe do projeto pode traduzir o status utilizando os indicadores de desempenho do EVM (Gerenciamento do Valor Agregado). Um recurso prtico para relatrios de status utilizar sinalizadores coloridos do tipo painel de controle que seguem a conveno de: vermelho, amarelo e verde de acordo com a condio do indicador.
94
Para os indicadores cujo sinalizador esteja em amarelo ou vermelho medidas de gerenciamento, ou MEDIDAS CORRETIVAS devem propostas e submetidas a aprovao. MEDIDAS CORRETIVAS O mtodo do Valor Agregado permitir uma avaliao da sade do projeto com certo grau de preciso, porm, uma vez que foram identificados desvios no plano de gerenciamento do projeto ser necessrio tomar medidas corretivas que faam o projeto voltar condio de alcanar seus objetivos. As perguntas que surgem quando so constatados os desvios so: Gastar mais para melhorar prazo? Gastar menos para melhorar custo? Cortar escopo? Propor mudanas? A resposta s poder ser dada pelo FATOR CRTICO DE SUCESSO DO PROJETO. O DRIVER do projeto que estabelece as prioridades para o projeto dentre suas variveis. Qual a prioridade, basicamente, entre ESCOPO, TEMPO e CUSTO? Esta prioridade, como vimos deve ser identificada no incio do projeto, pois ela determinar, direcionar, todas as aes do projeto. Entretanto, se ela ainda no estiver clara ser explicitada neste momento, pois os demandantes do projeto (patrocinador sponsor e cliente) rejeitaro quaisquer solues para os desvios do projeto que contrariem a prioridade real do projeto. No caso de um projeto cujo fator crtico de sucesso seja custo, e o projeto estiver com desvios de prazo de custo, por exemplo, uma proposta do gerente do projeto para reduo do atraso que implique em aumento de custos ser, certamente, rejeitada pela alta direo do projeto. Portanto, o gerenciamento do projeto, considerando todo o processo desde sua iniciao, planejamento, execuo, monitoramento e controle at o encerramento, deve ser direcionado pelos reais interesses do projeto, por suas reais prioridades, que permitam o melhor aproveitamento dos recursos limitados com os quais seu condutor (gerente do projeto) poder contar para produzir a entrega final dentro dos parmetros esperados por seus demandantes.
95
Processo de Ao Corretiva A BOA PRTICA recomenda que ao corretiva, ao contrrio da prtica geral, seja, submetida aprovao da autoridade responsvel. Seja o sponsor do projeto, uma diretoria, ou um comit constitudo especialmente. importante lembrar que os critrios, limites e aladas j devem ter sido estabelecidos no plano de gerenciamento do escopo e impedem que as decises do projeto fiquem engessadas.
Controle Integrado de Mudanas A natureza de elaborao progressiva e de uma projeo a um ponto futuro do projeto faz com que esteja sujeito a mudanas. Mudanas em projetos podem originar-se por muitas razes: podem ser fruto de uma maior compreenso do produto a ser entregue em razo do avano de partes do projeto que permitiram uma nova viso; por uma mudana no ambiente no qual o projeto est inserido que fez com que a estratgia que deu origem ao projeto tenha mudado; por riscos que materializaram-se e tornaram o plano de gerenciamento do projeto invivel, enfim, antes de impedir mudanas, o gestor do projeto deve gerenci-las, ou seja, tomar as providncias necessrias para que elas sejam incorporadas devidamente ao projeto. Assim sendo, necessrio seguir procedimentos rigorosos de formalizao das solicitaes, de avaliao dos impactos que a mudana gerar nos outros componentes do projeto e em seu sucesso, informar os stakeholders, e atualizar toda a documentao do projeto atingida.
96
Processo de Mudana
O processo de mudana inicia-se na solicitao da mudana, portanto altamente recomendvel que as solicitaes sejam formais, isto , feitas atravs de documentos reconhecidos pela organizao executora. Idealmente deve-se utilizar formulrios padronizados.
97
FORMULRIO DE SOLICITAO DE MUDANA NO PROJETO

Projeto Solicitante Descrio da Mudana Data da Solicitao Nmero
Justificava para a Mudana
Impactos no projeto e medidas para mitigao dos impactos 1. Escopo 1.1. 2. Tempo 2.1. 3. Custo 3.1. 4. Qualidade 4.1. 5. Riscos do projeto 5.1. Aprovador Data da Aprovao
Um risco associado a mudanas em projetos o tratamento inadequado, em geral, gerado pela confuso entre mudana e correo de desvio, medida corretiva, que leva a distores do plano de gerenciamento do projeto. A medida de gesto, ao corretiva ou correo de desvio tem origem diferente da mudana. Vem de uma constatao feita a partir do monitoramento do projeto, enquanto que a mudana uma nova demanda posta ao projeto, novo input. Solicitao - Definio do procedimento formal para a solicitao de mudanas no escopo Avaliao - Definio do processo para avaliao dos impactos causados pelas mudanas solicitadas, a fim de propiciar a informao necessria para a tomada de deciso quanto a autorizao da mudana Autorizao - Definio do processo e dos envolvidos na autorizao das mudanas solicitadas (Comit de Controle de Mudanas) Documentao - Definio do processo de atualizao da documentao do projeto, em decorrncia da mudana solicitada Comunicao - Comunicao aos envolvidos ou impactados pela mudana
Distribuio das Informaes do projeto O plano de comunicaes estabeleceu o que deve ser comunicado, pra quais stakeholders, em que momentos, e os meios que devem ser utilizados, portanto, o gestor do projeto, utilizar como guia a matriz de comunicaes.
98
As reunies, um dos meios de comunicao essenciais para um projeto, que so, na verdade instrumentos poderosos de gesto, devem ser conduzidas pelo gestor do projeto com muito rigor seguindo tcnicas de coordenao de reunies que garantam que o tempo e recursos envolvidos sejam aproveitados da melhor forma possvel, isto , tenham eficcia. Considerando-se que o tempo em projetos recurso , por definio, limitado e de influncia direta nas outras variveis do projeto, obrigao primria do gestor do projeto, administr-lo com o mximo de cuidado. recomendvel para a estabilidade na funo que o gestor do projeto seja, e transmita aparncia de ser, organizado. Uma reunio que consuma mais tempo que o necessrio e que no cumpra seus objetivos, passa mensagens que atingem a reputao de profissional capaz de elaborar planos e realizar estes planos, que expectativa bsica de competncia de um gestor de projetos. Assim sendo, essencial que sejam tomadas providncias que garantam a eficincia e eficcia das reunies de projeto.
Coordenao de Reunies Objetivo da Reunio. Em um projeto h diversos tipos de reunies necessrias ao seu gerenciamento: reunio de Kickoff (partida da execuo), de avaliao de membros da equipe, de solues tcnicas, de lies aprendidas, de identificao de riscos, de brainstorming para definio do escopo, de progresso, para citar as principais. Portanto, fundamental para a eficcia e especificao dos principais elementos da reunio, tais como, a pauta e convocados, que seja bem definido o objetivo da reunio. Coordenador da Reunio. Elemento essencial para a eficcia da reunio deve ter conscincia de que o responsvel pelo sucesso ou fracasso da reunio. No caso do projeto, na maior parte das reunies esta coordenao ser exercida pelo gestor do projeto que ter, neste papel, as seguintes atribuies: Preparar pauta e distribuir previamente aos participantes Convocar participantes (necessrios e suficientes) Abrir a reunio (ltima reunio - fazer apresentaes) Conduzir a pauta (prioridade de assuntos) Promover processos de tomada de decises (votao) Administrar conflitos e disputas de poder Fechar a reunio (fazer resumo dos assuntos abordados) Durao. Este talvez seja o fator mais crtico para o sucesso de uma reunio. Na verdade o fato dela, a durao, no ser definida com clareza e, principalmente, cumprida. A indefinio dos horrios de incio trmino e o no cumprimento destes limites, faz com que os participantes cheguem atrasados, consome mais tempo do
99
que o necessrio e joga o instrumento gerencial reunio no descrdito. Em analogia ao projeto como um todo, a durao est para a reunio, assim como o prazo limite est para o projeto. Pauta. A pauta de uma reunio o contedo, ou conjunto de assuntos que sero tratados na reunio. Se mantivermos a analogia com o projeto, a pauta equivaleria ao escopo do projeto. Neste caso, se o cumprimento da durao for considerado fator crtico de sucesso, a pauta dever subordinar-se durao. Isto , a pauta dever ter o tamanho que caiba na durao estabelecida para a reunio. Os estudiosos do assunto afirmam que reunies tendem a ter pautas extensas na medida em que os problemas ou questes a serem tratadas se acumulam. Sendo assim, um projeto que estabelea e siga um ciclo de controle adequado tender a ter menos necessidade de pauta por reunio. Outra prtica que conduz a reunies mais rpidas a adoo de um roteiro de pauta padronizado em formato de lista de verificao (checklist). Agenda. Ainda na analogia, deve-se distribuir o tempo disponvel determinando perodos de tempo proporcionais e especficos a cada assunto da pauta. Isto determinar milestones, ou marcos nos quais o coordenador da reunio dever promover processos de tomada de deciso, por votao, se for o caso, e passar ao assunto seguinte. Ou seja, se a pauta o escopo, a agenda passa a ser o cronograma da reunio. Que, tambm, deve ser cumprido. A dificuldade de estabelecer limites de tempo por assunto a mesma que se tem em dimensionar duraes para realizaes do escopo. Analogamente, deve-se aprender (lies aprendidas), melhorar esta distribuio de proporo com o planejamento e a prtica avaliada e estudada. Periodicidade. muito provvel que haja necessidade de uma reunio extraordinria, ou emergencial para solucionar problemas, riscos que se materializam, em um projeto, mas por princpio, as reunies de um projeto devem ser planejadas. Isto , ao trmino da elaborao do plano de gerenciamento do projeto, o gestor do projeto j deve ter o calendrio das reunies programadas. Sendo assim, este calendrio deve ser divulgado com antecedncia a fim de que os participantes convocados possam programar-se registrando em suas agendas. Se esta boa prtica for adotada conveniente que haja uma previso de comunicao com antecedncia de adiamentos e cancelamentos. No esqueamos que a reputao de planejador competente do gestor do projeto est em jogo. Local. Informado e preparado previamente, o local da reunio, evita atrasos dos participantes e at mesmo do incio possvel da reunio. Deve, tambm, ser adequado em termos de espao e conforto, mas deve ser respeitado o princpio da economicidade. Isto , locais desproporcionalmente grandes para o nmero de pessoas e cujas instalaes consumas muita energia, so contra-indicados. Responsvel pela Ata. Esta providncia permitir que os participantes que tenham contribuies ativas na reunio possam concentra-se nos assuntos e no se distraiam tendo que registrar o que tratado na reunio. Em seguida, recomendvel que a assistente administrativa (contra-indicado que seja um tcnico de valor-hora, em geral maior) responsvel pela redao da ata, envie aos stakeholders determinados na matriz de comunicaes para receb-la.
100
Reunies de Progresso O monitoramento do projeto prov informaes acerca do desempenho do projeto e seus desvios em relao ao plano. As providncias de controle podem ser tomadas isoladamente, mas avaliaes do progresso, isto , o quanto foi realizado do que foi planejado, como esto sendo aplicados os recursos do projeto, qual a magnitude dos desvios, que previses podem ser feitas para o restante do projeto, enfim, o gerenciamento do projeto em equipe deve ser realizado nas reunies de andamento do projeto, segundo o Guia PMBOK, ou de progresso. Devem ser realizadas de acordo com o CICLO DE CONTROLE do projeto. O foco deve ser avaliar o executado comparando com o planejado. O status ou situao, ou posio do projeto deve ser insumo para a reunio de progresso, isto , deve ser levado pelos participantes em forma de relatrios para anlise. No boa prtica utilizar a reunio de progresso para levantar o status do projeto. A reunio de progresso uma reunio para anlise de dados, e tomada de decises. Devem ser analisados os pontos de ateno, riscos identificados e riscos que perderam a potencialidade, e elaborar previses de desempenho e de status futuros, preferencialmente utilizando a tcnica do valor agregado que foi vista.
O processo de Verificao do Escopo e Aceitao Formal A cada etapa concluda, antes de realizar a entrega, a equipe do projeto deve realizar uma inspeo, isto , uma comparao entre o que est prestes a ser entregue ao cliente e os requisitos definidos da qualidade. Se resultado estiver dentro dos limites de tolerncia estabelecidos, ento a entrega poder ser efetivada. Se o trabalho no estiver conforme, correes devem ser realizadas at que os requisitos sejam atendidos, para s ento, ser entregue ao cliente. A prtica de inspecionar o trabalho antes de entregar ao cliente segue o princpio de administrao geral que prega a economicidade de processo, ou seja, quanto mais distante identificada uma no-conformidade mais custo ela gera. Dessa forma, se a no-conformidade for identificada ainda no mbito do projeto, sua correo gerar menos custo do que se for identificada nas mos do cliente. O cliente, por sua vez, ao receber o trabalho (a entrega), deve verificar a conformidade com os parmetros da qualidade acordados. Estes parmetros serviro de Critrios de Aceitao da entrega para o cliente. Este processo de gerenciamento do projeto, realizado pelo cliente, denominado de Verificao do Escopo, pois basicamente verifica se o escopo est completo e se foi realizado dentro dos critrios de aceitao. Se o trabalho estiver dentro dos critrios de aceitao, isto , conforme, o cliente deve, ento dar o ACEITE FORMAL no trabalho.
101
Podem ser utilizados outros termos para designar a verificao do escopo: reviso de produto, auditoria, homologao, etc.
102
Encerramento do Projeto
O processo de encerramento de projetos, por diversas razes, no conduzido com o devido cuidado que sua importncia requer. Alguns membros da equipe j esto dividindo seu tempo com outro projeto, conflitos podem ter ocorrido e gerado desgaste emocional, cansao fsico, os gerentes funcionais que cederam seus subordinados pressionam para os terem de volta, enfim, muitos fatores conspiram para que o projeto seja abandonado e no encerrado formalmente. Um processo de encerramento mal realizado, porm, causa danos no s ao projeto em si, mas organizao executora que perde a oportunidade valiosa de gerar dados, informaes e conhecimentos para aplicao nos projetos subsequentes, alm de ficar sujeita a aes judiciais movidas pelo cliente por descumprimento do contrato, gerando prejuzos financeiros. O encerramento do projeto consiste basicamente do encerramento administrativo e do encerramento dos contratos. Se a administrao dos contratos tiver sido realizada, ao longo do projeto, com a prtica de acompanhamento atravs de uma planilha com as informaes do contrato, e as obrigaes tiverem sido cumpridas, os procedimentos de encerramento dos contratos sero bastante facilitados. Deixar qualquer contrato do projeto em aberto, gera um risco grave organizao executora do projeto. O encerramento administrativo confirmar que o trabalho foi realizado de acordo com os requerimentos e obter a aceitao formal do cliente. A partir da entrega do produto final do projeto e da verificao do escopo, realizada pelo cliente. Se no houver correes de no-conformidades, poder ser formalizada a aceitao do resultado do projeto, permitindo, ento que sejam tomadas as demais providncias administrativas tais como: Preparar o relatrio de performance final do projeto Indexar e arquivar documentos Realizar a reunio de balano final de Lies Aprendidas (Lessons Learned) Desmobilizar os recursos do projeto Lies Aprendidas Os estudiosos afirmam que o desenvolvimento de competncias organizacionais no gerenciamento de projetos ocorre por processo histrico. Significa que a organizao deve aprender com os projetos que realiza. Este aprendizado transformado em conhecimento em gerenciamento de projetos considerado pelo Guia PMBOK como sendo ativos organizacionais. Bens de valor. Recursos que podem gerar riqueza e, conseqentemente crescimento para a organizao. 103
Dois elementos so fundamentais para que este processo de aprendizado acontea: Registro Anlise O registro a documentao da histria do projeto. A descrio com o maior nvel de detalhes das ocorrncias do projeto. Como problemas e dificuldades foram superados, como desvios foram corrigidos, como solues tcnicas foram encontradas, enfim, Visto que um processo de aprendizado coletivo, sees de lies aprendidas so mais produtivas se o foco no aspecto positivo, isto , foco nas solues e no nos erros. O Dr. Joseph Juran j recomendava que problemas possuem causas e no culpados. Esta uma boa postura a ser assumida pelo gestor do projeto se o objetivo for criar um clima favorvel ao aprendizado. A busca por culpados pode transformar o processo de lies aprendidas em uma troca de acusaes e defesas que no traro benefcio. recomendvel que sejam conduzidos processos, ou sees de lies aprendidas ao longo de todo o processo do projeto, porque alguns membros da equipe deixaro o projeto quando forem concludas suas atividades, porque quanto mais prximo do fato gerador, mais preciso o relato das ocorrncias, e, por fim, o processo sendo realizado desde o comeo do projeto permite que os ganhos do aprendizado sejam aproveitados para o prprio projeto.
104
BIBLIOGRAFIA AMBRIZ, Rodolfo. Dynamic Scheduling with Microsoft Office Project 2007. Florida, J. Ross Publishing, 2007. CHAPMAN, Chris. Project Risk Management. New York, John Wiley, 1997. DINSMORE, Paul C at al. The AMA Handbook of Project Management. New York, Amacom, 2009. DINSMORE, Paul C at al. Projetos Brasileiros Casos Reais de Gerenciamento. Rio de Janeiro, Brasport, 2007. GOLDRATT, Eliyahu M.. Corrente Crtica. So Paulo, Nobel, 1998. HAMILTON, Albert. Management by Projects - Achieving Success in a Changing World. London, Thomas Telford, 2003. HELDMAN, Kim. Gerncia de Projetos Fundamentos. Rio de Janeiro, Campus, 2005. KERZNER, Harold. Gesto de Projetos As Melhores Prticas. So Paulo, Bookman, 2005. KERZNER, Harold. Project Management - A Systems Approach to Planning, Scheduling and Controlling. New York, John Wiley & Sons, 2008. MEREDITH, Jack R.. Project Management: A Managerial Approach. New York, John Wiley, 2002. PROJECT MANAGEMENT INSTITUTE - PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK), 4 Edio. Pennsylvania, PMI, 2008. PROJECT MANAGEMENT INSTITUTE PMI. Practice Standard for Project Risk Management. Pennsylvania, PMI, 2009. PROJECT MANAGEMENT INSTITUTE - PMI. The Standard for Program Management. Pennsylvania, PMI, 2008. PROJECT MANAGEMENT INSTITUTE - PMI. The Standard for Portfolio Management. Pennsylvania, PMI, 2008. PINTO, Amrico. Benchmarking em Gerenciamento de Projetos Brasil: Relatrio 2004. Rio de Janeiro, Editora SENAI, 2005. SHTUB, Avraham. Project Management - Engineering, Implementation. New Jersey, Prentice-Hall, 1994. Links: Softwares sobre gerenciamento de projetos: http://en.wikipedia.org/wiki/List_of_project_management_software Technology, and
105

Apostila Compass - Fundamentos de Gerenciamento de Projetos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apostila Compass - Fundamentos de Gerenciamento de Projetos

Загружено:

Авторское право:

Доступные форматы

FUNDAMENTOS DE GERENCIAMENTO DE PROJETOS

Conceitos de Gerenciamento de Projetos......................................................................................................5

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Conceitos de Gerenciamento de Projetos

O papel dos projetos neste contexto

Copyright Compass International Knowledge Center

Realizao de objetivos estratgicos atravs de projetos

Project Management Institute - PMI

Guia PMBOK1 Project Management Body Of Knowledge

PMBOK marca registrada de Project Management Institute.

Copyright Compass International Knowledge Center

Certificao PMP2 Project Management Professional

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Quando um projeto tem sucesso?

Perspectivas de sucesso de um projeto

Projeto planejado e gerenciado x projeto tocado

Projeto planejado e gerenciado X Projeto tocado

Perfil e competncias do Gerente do Projeto

Processos de Gerenciamento de Projetos

Copyright Compass International Knowledge Center

Grupos de Processos de Gerenciamento de Projetos - Fonte: Guia PMBOK, 2008

Ciclo de Vida e Processos de Gerenciamento de Projetos

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

reas de Conhecimento Integrao

Copyright Compass International Knowledge Center

DESENVOLVER O TERMO DE ABERTURA DO PROJETO

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

STAKEHOLDERS (Partes Interessadas) DO PROJETO

Copyright Compass International Knowledge Center

Anlise dos Stakeholders (Partes Interessadas do Projeto)

Copyright Compass International Knowledge Center

Figura 1 - Registro de Partes Interessadas

Registro dos Stakeholders (Partes Interessadas do Projeto)

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Plano de Gerenciamento do Projeto

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

DEFINIO DO ESCOPO DO PROJETO

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

Copyright Compass International Knowledge Center

O processo de Verificao do Escopo

1 N vel : Nome do Projeto 1 Nvel

2.1 2.1 Fase Fase 1 1

2.2 2.2 Fase Fase 2 2

2.3 2.3 Fase Fase 3 3

3.1 3.1 Entrega Entrega

3.2 3.2 Entrega Entrega

3.3 3.3 Entrega Entrega

3.4 3.4 Entrega Entrega

3.5 3.5 Entrega Entrega

3.6 3.6 Entrega Entrega

2 N vel : Ciclo de Vida do Projeto 2 Nvel

2.1 2.1 Fase Fase 1 1

2.2 2.2 Fase Fase 2 2

2.3 2.3 Fase Fase 3 3