Apostila Compass - Fundamentos de Gerenciamento de Projetos

FUNDAMENTOS DEGERENCIAMENTO DE PROJETOS

Sumário

Conceitos de Gerenciamento

de Projetos ...................................................................................................... 5

O QUE É UM PROJETO? ............................................................................. 7

GERENCIAMENTO DE PROJETOS ............................................................ 10

Processos

de

Iniciação ........................................................................................................ 21

Processo

de

Planejamento ................................................................................................ 28

Execução,

Monitoramento

e Controle

do Projeto ...................................................................................................... 83

RELATÓRIO DE STATUS DO PROJETO .................................................... 94

Projeto ........................................................................................................... 94

Data ............................................................................................................... 94

Número .......................................................................................................... 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

Orçamento do Projeto (BAC) ...................................................................... 94

Data de Término prevista ............................................................................ 94

© Copyright Compass – International Knowledge Center 2

Indicadores .................................................................................................. 94

Anterior ......................................................................................................... 94

Atual .............................................................................................................. 94

Sinalizador .................................................................................................... 94

Variação de Custo (CV) ................................................................................ 94

Variação de Prazo (SV) ................................................................................ 94

Performance de Custo (CPI) ........................................................................ 94

Performance de Prazo (SPI) ....................................................................... 94

Estimativa de Custo no Término (EAC)c .................................................... 94

Estimativa de Prazo no Término (EAC)t ..................................................... 94

Ações Corretivas .......................................................................................... 94

FORMULÁRIO DE SOLICITAÇÃO DE MUDANÇA NO PROJETO ............. 98

Projeto ........................................................................................................... 98

Data da Solicitação ...................................................................................... 98

Número .......................................................................................................... 98

Solicitante ..................................................................................................... 98

Descrição da Mudança ................................................................................ 98

Justificava para a Mudança ......................................................................... 98

Impactos no projeto e medidas para mitigação dos im pactos ................ 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 Aprovação ....................................................................................... 98

Encerramento

do

Projeto ......................................................................................................... 103


Conceitos deGerenciamento de Projetos

Será a atual preocupação das empresas com o tema gestão deprojetos um mero modismo? Alguns indicadores observados no contexto empresarialatual nos levam a crer que não. Conseqüência de uma volatilidade cada vez maisacentuada de mercados que aparecem e desaparecem da noite para o dia, ainstabilidade econômica, característica no passado de períodos sazonais, hoje é umarealidade com a qual as organizações precisam conviver. Este cenário torna acompetição cada vez mais acirrada e agressiva e faz com que os riscos incorporadosaos negócios adquiram dimensões desproporcionais. Neste contexto, os recursosconsumidos pelas empresas para realizar suas estratégias tornam-se cada vez maisimportantes e precisam ser geridos com o máximo de eficiência.

Instrumento indispensável para o crescimento e sobrevivência no volátil mercadoatual, a capacidade de inovação é outro importante fator crítico de sucesso. Inovar,diferentemente de apenas inventar, pressupõe um processo estruturado de estudostécnicos e financeiros até a transformação em aplicações que trarão resultadosefetivos para a organização geradora da inovação. Isto é, inovação no meioempresarial é transformação de idéias em negócios.

O papel dos projetos neste contexto

Se analisarmos como as organizações estruturam seus planos estratégicos, veremosque as ações ou iniciativas estratégicas que realizam seus objetivos estratégicos decrescimento são de fato materializadas através da execução de projetos. Olançamento de novos produtos, a expansão para uma nova área de negócios,mudanças estruturais, como o aumento de capacidade de produção ou daprodutividade de algum setor da organização devem ser conduzidas por meio deprojetos.


Realização de objetivos estratégicos através de projetos

Portanto, pode-se afirmar que o alcance dos objetivos estratégicos de umaorganização ocorre na medida do sucesso de seus projetos estratégicos. Ou seja, aeficácia de um planejamento estratégico organizacional está diretamente relacionadaà eficácia de seus projetos estratégicos. Porém, os resultados dos projetos que sãorealizados atualmente não são nada satisfatórios. Segundo pesquisa de 2004publicada pelo Standish Group, instituto de pesquisas americano, apenas 34% dosprojetos realizados foram considerados concluídos com sucesso.

Apesar de o conceito de sucesso em projetos não ser simples de ser definido, comoveremos posteriormente, fica evidente a necessidade de melhoria no desempenhodos projetos conduzidos nas organizações. Algumas perguntas que dificilmenteencontrarão respostas dão uma idéia da dimensão de recursos envolvidos:

� Quantos projetos terminam fora do prazo? Quanto custa o atraso?� Quantos projetos terminam acima do orçamento? Quanto é gasto a mais?� Quantos projetos terminam sem completar o escopo?� Que perdas são geradas pelo que deixa de ser realizado por projetos que não

completam seus escopos?� Qual o custo da não-conformidade? � Qual o custo do cliente insatisfeito? Da perda de um cliente?

Pode-se concluir, então, que a preocupação com o gerenciamento de projetos deforma metodológica para a obtenção de resultados estratégicos não é um meromodismo ou onda passageira, mas uma necessidade real.

Project Management Institute - PMI

A busca da melhoria no desempenho de projetos teve um marco importante no finalda década de 60. Neste ano foi criado o Project Management Institute. Instituiçãonão governamental sem fins lucrativos situada na Pensilvânia, Estados Unidos, e quetem como missão fomentar a atividade de gerenciamento de projetos.

O PMI tem abrangência internacional e está organizado em mais de 200 sucursaischamadas de Chapters, distribuídos em 125 países. Atualmente existem cerca de300.000 afiliados que têm acesso, através do site do PMI, a documentos, artigos einformações sobre gerenciamento de projetos. A filiação pode ser feita, mediante opagamento de uma taxa no site: www.pmi.org.

Guia PMBOK®1 – Project Management Body Of Knowledge

O PMI tem, também, a responsabilidade de publicar o Conjunto de Conhecimentosem Gerenciamento de Projetos que está em sua quarta edição, lançada em 2008.

O Guia PMBOK®, como é conhecido, é um guia de referência básica de conteúdopara profissionais de gerenciamento de projetos e contribui para a divulgação deuma terminologia e vocabulário, comuns ao ambiente de projetos. É construído apartir da contribuição de descrições de “BOAS PRÁTICAS” resultantes de experiências

1 PMBOK é marca registrada de Project Management Institute.


de profissionais do mundo inteiro que as encaminham a comitês responsáveis porconsolidá-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 comunicações,gerenciamento dos riscos, gerenciamento das aquisições e gerenciamento daintegração do projeto, que serão abordadas posteriormente e cujo domínio éconsiderado essencial para um bom gerenciamento de projetos.

Certificação PMP®2 – Project Management Professional

Outra atribuição do PMI é certificar profissionais em gerenciamento de projetos. Acertificação PMP® é concedida aos aprovados em um teste de 200 questões demúltipla escolha que procura avaliar o candidato nas áreas de conhecimento do GuiaPMBOK® e em situações práticas do dia-a-dia do gerenciamento de projetos.

Para habilitar-se a fazer a prova é necessário comprovar 4.500 horas de experiênciaprática em projetos, para quem possui graduação superior, e 7.500 horas paraprofissionais de nível técnico e pagar uma taxa de 525 dólares americanos para nãoafiliados ao PMI, e 425 para afiliados.

Além da certificação PMP® o PMI também tem outras certificações relacionadas aotema gerenciamento de projetos, a saber:

• PgMP® (Program Management Professional) – demonstra conhecimento eexperiência na condução de programas.

• PMI-RMP® (Risk Management Professional) – demonstra conhecimento eexperiência em gerenciamento de riscos de projetos.

• PMI-SP® (Schedulling Professional) – demonstra conhecimento e experiênciaem gerenciamento de cronogramas de projetos.

• CAPM® (Certified Associate of Project Management) – demonstraconhecimento em gerenciamento de projetos. Para profissionais que aindanão têm tempo de experiência suficiente para serem certificados comoPMP®.

O QUE É UM PROJETO?O senso geral utiliza o termo projeto para referir-se a atividades da vida cotidianatais como: projeto de vida; uma intenção futura; desenhos, “plantas”, cominstruções para construção ou montagem de estruturas, enfim, aplicações das maisdiversas e livres.

Para este estudo, vamos considerar o conceito de projeto, de forma tecnicamenterestrita, como: o todo de um esforço, ou empreendimento, temporário para criar um

2 PMP, PgMP, PMI-RMP, PMI-SP e CAPM são marcas registradas de Project Management Institute.


produto, serviço ou resultado exclusivo. Envolve todo o processo desde aidentificação da demanda até a entrega do produto, serviço ou resultado final.

Conceituar projeto tecnicamente é importante para que possamos reconhecê-los nocontexto do dia-a-dia, distinguindo-os das rotinas operacionais e aplicarmos técnicasde gerenciamento específicas para obter melhores resultados.

O Guia PMBOK® define projeto como um esforço temporário para criar um produto,serviço ou resultado exclusivo.

� TemporárioSignifica que, comparado com operações de rotina, um projeto tem início efim definidos antes do início de sua execução.

� Produtos, Serviços ou Resultados exclusivosMesmo que haja algumas semelhanças, os resultados dos projetosapresentam diferenças. Prédios com o mesmo número de andares, mesmodesenho de planta, executados pela mesma construtora, etc., terãoresultados únicos, uma vez que seus processos de construção serãodiferentes, suas orientações em relação ao sol serão diferentes, suasfundações terão dimensões diferentes, pois estarão em posições de terrenodiferentes, etc.

A árvore de decisão, ao lado,representa o processo de escolhas dealternativas em um projeto. A ponderação de prós e contras emcada ponto de decisão é um processode TRADE-OFF (conceito da economiano qual nenhuma alternativa possuiapenas vantagens nem apenasdesvantagens)

� É Probabilístico (Não é Determinístico) Tem Risco (incerteza)No senso comum, a palavra projeto carrega a idéia de plano para futuro,previsão. Possui sempre uma carga de incerteza de que acontecerá o


A

∆t

B

∆Obj

PLANO

Janela de TEMPOD0 DDeadline

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

X

Y

W

Z

A1

B1

C1

D1

E1

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

X

Y

W

Z

A1

B1

C1

D1

E1

esperado, ou planejado. Esta característica torna o papel do gerenciamentodo projeto mais relevante, pois atua exatamente para reduzir a taxa dedesvio entre planejado e executado.

�

o fator crítico de sucesso de um projeto reside na capacidade de realizaçãode atividades através das pessoas. Determinados tipos de operações sãointensivos em máquinas ou equipamentos, mas em projetos os ativosprincipais são, de fato, as pessoas que o realizam.

� Elaboração Progressiva (em Etapas – Fases)As características anteriormente apresentadas conduzem a esta terceiracaracterística de qualquer projeto: não se conhece cabalmente o que será oprojeto assim que o mesmo se inicia. Com o passar do tempo, oconhecimento que se tem dele aumenta. Para lidar com essa característica,que traz incerteza e indefinição para qualquer projeto, costuma-se utilizar orecurso prático de segmentá-lo em etapas ou fases para melhorar acapacidade de gerenciamento e aumentar as chances de sucesso do projeto.

O princípio analítico de que partes menores são mais facilmente gerenciáveisvale muito em projetos. A divisão das fases que marcarão o processo doprojeto deve ser feita de acordo com a melhor conveniência dogerenciamento e irá variar de acordo com a característica específica de cadaprojeto.

� Recursos limitadosNas rotinas do dia-a-dia, os recursos são renovados para mantê-los emfuncionamento permanente. Em um projeto os recursos financeiros ehumanos têm limites definidos pelo tempo de sua duração, pelo escopo epela qualidade do resultado esperado. O conceito de limitação pressupõe


quantificação e é diferente do conceito de escassez, pois recursos escassossão insuficientes para alcançar os resultados planejados.

� Precisa de Administração EspecíficaAs técnicas de gestão operacional não são suficientes para dar conta dasdificuldades próprias dos projetos. As características dos projetos tornam asações de planejamento, programação e controle mais críticas e complexas,exigindo, portanto, técnicas e ferramentas específicas.

Outra maneira de definir o conceito de projetos é através da comparação com ascaracterísticas das operações rotineiras.

Projetos x Operações

� Decisões Irreversíveis x Decisões ReversíveisProjetos, por sua natureza temporária, existem durante uma janela de tempolimitada. Isso torna as decisões tomadas no âmbito do projeto muito maiscríticas, pois, na maioria das vezes, não há tempo suficiente para revertersuas conseqüências.

� Variáveis Exógenas x Variáveis EndógenasNa operação os fatores que influenciam mais fortemente seu desempenhosão oriundos de dentro do ambiente operacional, e, portanto mais passíveisde controle. O projeto sofre influência intensiva de fatores ou agentesexternos à equipe do projeto.

� Fluxo de Caixa Negativo x Fluxo de Caixa PositivoA menos que um ambiente operacional esteja passando por uma crisefinanceira, o montante das receitas geradas supera o de despesas no períodode tempo do ciclo de operação. Projetos são empreendimentos que geramdespesas que só poderão ser cobertas quando seus produtos criados geraremos resultados esperados e conseqüentemente as receitas. Mesmo que deforma indireta, como no caso dos projetos de modificações estruturaisdesenvolvidos dentro das empresas. Por essa razão torna-se quase que natotalidade dos casos obrigatória a redução do período de existência doprojeto (ciclo de vida).

GERENCIAMENTO DE PROJETOSSegundo o Guia PMBOK®, gerenciamento de projetos é a aplicação deconhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim deatender aos seus requisitos.

O grande desafio começa em ser capaz de gerenciar e não apenas executar ou,como é comum ouvir-se, “tocar o projeto”. O gerenciamento, que queremos trataraqui, pressupõe um processo estruturado e, preferencialmente, com a aplicação deum método, ou metodologia. O gerenciamento de projetos implica em levantarnecessidades, e identificar prioridades entre ESCOPO, TEMPO e CUSTO.


Priorizar escopo, tempo e custo significa que há uma dificuldade intrínseca deprojetos em atender plena e simultaneamente as três dimensões principais de umprojeto, uma vez que projetos são carregados de incertezas geradoras de desvios.

Cada projeto tem uma relação de prioridades diferente destas variáveis. Em umdeterminado projeto o vetor prioritário, ou FATOR CRÍTICO DE SUCESSO,(também conhecido como DRIVER do projeto, ou seja, fator direcionador) será ocusto, ou seja, todas as outras variáveis deverão ser subordinadas ao cumprimentodos objetivos e metas de custo do projeto. Em outro, poderá ser o tempo,significando que as outras variáveis serão dimensionadas para que o projeto cumprao prazo previsto.

Projetos de um mesmo tipo, a construção de uma casa, por exemplo, podem terprioridades diferentes. Vamos analisar três casos como exemplo.

Primeiro caso: o cliente precisa se mudar até uma data específica porque terá queentregar o apartamento que ocupa no momento. A prioridade do projeto será otempo. É provável que próximo da data marcada para a mudança do cliente, se oprojeto estiver atrasado, seja necessário aumentar o custo para cumprir o prazo.Talvez o escopo tenha que ser suprimido em alguns elementos que não sejamessenciais à mudança do cliente, pois o prazo é o vetor menos flexível.

Segundo caso: o cliente do projeto possui um montante determinado de recursosfinanceiros e precisa construir uma casa que se “encaixe” neste valor. Como nessecaso a prioridade é o custo, é provável que o cronograma tenha que ser estendidoem função do limite de orçamento. Da mesma forma o escopo, se houvernecessidade, tenha que ser cortado, naquilo que não impeça o funcionamento básicoda residência.

Terceiro caso: o cliente do projeto deseja uma casa com especificações tais como:número de quartos, banheiros, salas, salão de jogos, piscina com característicasespecíficas, etc. Nesse caso, o cronograma, assim como o orçamento, na dinâmicaincerta do projeto, provavelmente, tenha que ser aumentado para cumprir osrequisitos de escopo.

Porém, estabelecer prioridades não significa descuido ou abandono das variáveis quenão são a prioritária, pelo contrário. O bom desempenho no conjunto das variáveisde restrição do projeto aumenta a probabilidade de sucesso no vetor prioritário econsequentemente do projeto.

A prioridade de objetivos, porém, não é facilmente identificável. O primeiro impulsodos principais interessados é desejar que todas as demandas, variáveis, objetivos, ouvetores, sejam atendidos igualmente. O que é, quase sempre, inviável. Dada anatureza da atividade projeto, extremamente volátil e carregada de incertezas.

O responsável pelo projeto deve procurar identificar o vetor prioritário lançando mãode sequências de perguntas nas quais sejam postas hipóteses de situações limitesentre pares de vetores para que possa, gradativamente, identificar as prioridades.Por exemplo, se numa situação limite, para que o escopo seja completado fornecessária uma extensão do prazo, e isto for aceitável, é um indício de que escopotem prioridade sobre prazo.


Os requisitos, portanto, não são simplesmente “passados” pelo demandante aogerente do projeto. É necessária uma construção conjunta, na qual o gerente doprojeto fará sugestões, alertará acerca de impossibilidades técnicas, mostraráconseqüências de opções escolhidas pelo demandante, etc. A descrição destemodelo de relacionamento fica melhor representada pela expressão inglesa:COMAKERSHIP (Processo de relacionamento de parceria para elaboração conjunta).

Deste relacionamento desdobra-se, também, a equação da qualidade do serviço. Naqual a qualidade percebida está diretamente relacionada à qualidade esperada pelocliente e a qualidade daquilo que é entregue, ou seja, ofertado. A qualidadeesperada reflete a expectativa do cliente que é formada por diversos fatoresrelacionados ao perfil racional e emocional do cliente.

Dependem do background cultural e educacional do cliente, das suas experiênciasanteriores com projetos, e com projetos de mesma natureza, do ambiente sob o qualele está vivendo no momento do relacionamento com o projeto, enfim de uma sériede fatores que compõem um quadro de expectativa sob a qual o executor doprojeto, o gestor do projeto, não tem domínio. Tem, apenas, influência desde omomento em que começa o relacionamento pessoal para a condução do projeto.

Esta equação confirma o caráter subjetivo que permeia toda relação de consumo,seja de um produto, seja de prestação de um serviço, no caso, da realização de umprojeto. Não há como extrair totalmente este ingrediente subjetivo. Portanto, mesmoque utilizemos métodos para traduzir requerimentos e desejos e expectativas emfatos e dados sempre haverá uma parcela considerável de subjetividade.

A interdependência entre as variáveis significa que quando há a alteraçãodimensional de uma delas implica na modificação de pelo menos mais uma delas. E,uma vez definidas as dimensões adequadas de escopo, tempo e custo do projeto, aqualidade do projeto será a medida de cumprimento destas dimensões dentro doslimites de tolerância dos demandantes do projeto.

Quando um projeto tem sucesso?

A avaliação do sucesso de um projeto deve ser vista por duas perspectivas bemdistintas: do processo do projeto e do produto do projeto.

Perspectivas de sucesso de um projeto

Na perspectiva do processo de projeto são observados os aspectos de eficiência doprocesso. Ou seja, se os requisitos de conformidade do processo do projeto foramatendidos. Esta dimensão está ligada à organização executora do projeto. As perdasde eventuais e desvios nos planos de projeto afetarão diretamente o desempenhooperacional da organização executora.

Já na perspectiva do produto do projeto são observados os aspectos da eficácia. Istoé, se o resultado do projeto foi entregue dentro dos requisitos de conformidade docliente. A avaliação é feita pelo cliente do projeto na sua perspectiva.

Portanto, um projeto pode ser eficiente e não ser eficaz e vice-versa. Eficácia semeficiência, ou seja, sucesso apenas para o cliente e processo de projeto com níveisde desvio elevados, estará gerando, em médio ou longo prazo, desequilíbrio deconsumo de recursos da organização executora do projeto. Eficiência sem eficáciaresultará em insatisfação do cliente, porque o produto do projeto não atenderá seusrequisitos.

Projeto planejado e gerenciado x projeto “tocado”

Ao receber o encargo de realizar um empreendimento, o impulso natural de todosnós, seres humanos, é começar a executar as atividades que nos parecemnecessárias, imediatamente. Vencer este impulso e seguir um processo estruturadoou metodológico de concepção e elaboração de um plano para só então executá-lorequer um comportamento programado para tal.

A transformação de um mero “tocador” de projetos para um verdadeiro gerente deprojetos profissional tem como premissa básica esse perfil de trabalho. Na execução


sem planejamento a probabilidade de re-trabalho e desperdício de recursos é maiorgerando, em geral, a extensão do tempo e o estouro dos custos. A presunção deprofissionais de gerenciamento de projetos, que adotam boas práticas, é de que otempo dedicado ao planejamento seja inversamente proporcional ao acréscimo detempo de execução 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, não é o nome de umtítulo formal de cargo administrativo. É a designação do responsável pelogerenciamento do projeto. Responsável pelo seu sucesso ou fracasso, mesmoquando lhe forem impostas condições absolutamente desfavoráveis.

Hoje, há profissionais cujo cargo é Gerente de Projetos. Significa que esteprofissional tem como missão institucional gerenciar projetos. É comum, porém, queprofissionais que ocupam os mais diversos cargos sejam designados, emdeterminado momento de suas vidas profissionais, como responsáveis por umprojeto. Neste momento o profissional passa a ser o gerente deste projeto.

São atribuições comuns ao gerente do projeto:

� Entrega do produto do projeto� Formação e construção da equipe do projeto� Elaboração dos planos do projeto� Direção da execução do projeto� Monitoramento e controle do projeto� Medição da performance do projeto� Relacionamento com os stakeholders do projeto� Determinação de ações corretivas e preventivas� Gerenciamento do escopo, tempo, custos, qualidade, recursos humanos,

riscos, comunicações e aquisições do projeto� Promoção e manutenção da integração e coesão dos componentes do projeto


O Gerente do Projeto deve ter autoridade suficiente para realizar suas atribuições.Esta autoridade, no âmbito do projeto, é concedida pelo patrocinador do projeto.Sem autoridade suficiente o Gerente do Projeto terá dificuldades em incorporar osrecursos necessários ao cumprimento dos objetivos do projeto.

Perfil e competências do Gerente do Projeto

Historicamente o Gerente do Projeto vem sendo escolhido para a função degerenciar o projeto por suas competências tecnológicas da área de conhecimento noqual o projeto será conduzido. Nos projetos de engenharia, o gerente do projeto éescolhido “naturalmente” por ser engenheiro, nos de tecnologia da informação, porser analista de sistemas, e assim por diante.

Pressionado pela exigência por resultados, vem ocorrendo uma modificação nestesrequisitos. Pode-se considerar que até da metade dos anos 80, exigia-se do gerentedo projeto em torno de 20% de competências comportamentais, ou gerenciais, e80% de competências técnicas ou tecnológicas especialistas. Hoje, a relaçãoconsidera apropriada para um melhor desempenho das funções de gerenciamento deprojetos gira em torno de 20% de competências técnicas e tecnológicas e 80% decompetências comportamentais.

Esse processo de mudança resulta, também, da constatação de que os fatores quecontribuem mais significativamente para os fracassos dos projetos são de ordemgerencial e não técnica.

Processos de Gerenciamento de Projetos

Como processo é um conjunto de atividades inter-relacionadas capazes de gerarresultados, o gerenciamento de projetos pode ser estruturado em processosespecíficos. Na verdade, os efetivos ganhos de eficiência na realização de projetosocorrem quando projetos são gerenciados seguindo processos.

O PMI, no Guia PMBOK®, define cinco grupos de processos:

� Iniciação� Planejamento� Execução� Monitoramento e Controle� Encerramento

Cada grupo de processos contém um conjunto de processos capazes de gerar osresultados esperados do projeto. O Guia PMBOK® relaciona os processos utilizadospor profissionais e organizações no mundo inteiro para gerenciar seus projetos. Estesprocessos por terem demonstrado sua efetividade são considerados “BOASPRÁTICAS”. Cada organização, porém, deverá identificar dentre os processos, ouboas práticas, disponíveis, quais serão adequados aos seus projetos especificamente.


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

Os grupos de processos não são fases do projeto. Processos são genéricos, ouseja, aplicam-se a todo e qualquer projeto e repetem-se ao longo do ciclo de vida doprojeto. Por exemplo, o processo de iniciação ocorre quando o projeto é autorizado equando cada fase do projeto tem sua autorização de início. O processo deplanejamento é 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 planodeve ser consultado e executado no processo de execução. Os processos deencerramento ocorrerão toda vez que uma parte do projeto for concluída, ou seja,realizada uma entrega. O processo de monitoramento e controle ocorre desde que asprimeiras ações do projeto são realizadas até o seu término. Os grupos de processosde gerenciamento do projeto apresentam interações entre si ao longo do ciclo devida do projeto.

Ciclo de Vida e Processos de Gerenciamento de Projetos

Esquematicamente, podemos identificar momentos do projeto nos quais osprocessos ocorrem com mais intensidade, ou têm entregas marcantes. Por exemplo:o processo de iniciação, quando ocorre no início do projeto, gera o documento deabertura do projeto (Project Charter, ou Termo de Abertura), o processo deplanejamento ocorre mais intensamente quando está se preparando o Plano degerenciamento do projeto, ou Plano de Gerenciamento do Projeto que será a basede referência (baseline) para o processo de execução das atividades do projeto.

O ciclo de vida de cada projeto é identificado de acordo com suas fases específicas,ou seja, um projeto de construção de uma casa terá fases próprias de projetos deconstrução de casas, e seu ciclo de vida será descrito tipicamente pelas fases:fundações, estrutura, alvenaria, instalações, telhado, acabamento e limpeza. Já umprojeto de desenvolvimento de um sistema de tecnologia da informação poderá terseu ciclo de vida típico como: levantamento de requisitos, análise, programação,instalação e homologação.


Os processos de gerenciamento têm como finalidade gerenciar (planejando,monitorando e controlando) como serão realizadas as atividades necessárias àconcretização do produto do projeto. Em cada fase específica do projeto, poderãoser “rodados” os processos de gerenciamento. Esta distinção é útil para uma melhordefinição da natureza do trabalho que efetivamente estará sendo realizado a cadamomento, se de gerenciamento ou de elaboração do produto do projeto.

Desenvolvimento do Projeto

O modelo a seguir representa o desenvolvimento de um projeto desde aidentificação da necessidade de realização do projeto, a partir de um problema ou doaproveitamento de uma oportunidade.

As setas descrevem as interações entre os processos e a lógica de elaboraçãoprogressiva com o carregamento de dados e informações nos componentes do planoque será executado, monitorado, controlado e encerrado.




Áreas deConhecimento

Grupos de Processos de Gerenciamento de Projetos (Guia PMBOK®, 2008)

Iniciação Planejamento Execução Monitoramento e Controle

Encerramento

Integração � Desenvolver oTermo deAbertura doProjeto

� Desenvolver oPlano deGerenciamentodo Projeto

� Orientar eGerenciar aExecução doProjeto

� Monitorar eControlar oTrabalho doProjeto� ControleIntegrado deMudanças

� Encerrar oProjeto ou Fase

Escopo � ColetarRequisitos� Definir oEscopo� Criar EAP

� Verificar oEscopo� Controlar oEscopo

Tempo � Definir asAtividades� Seqüenciar asAtividades� Estimar osRecursos� Estimar aDuração dasAtividades� Desenvolver oCronograma

� Controlar oCronograma

Custos � Estimar osCustos� Definir oOrçamento

� Controlar osCustos

Qualidade � Planejar aQualidade

� Realizar aGarantia daQualidade

� Realizar oControle daQualidade

RecursosHumanos

� Desenvolver oPlano deRecursosHumanos

� Mobilizar aEquipe do Projeto� Desenvolver aEquipe do Projeto� Gerenciar aEquipe do Projeto

Comunicações � Identificar asPartesInteressadas

� Planejar asComunicações

� Distribuir asInformações� Gerenciar asExpectativas dasPartesInteressadas

� Reportar oDesempenho

Riscos � Planejar oGerenciamentodos Riscos� Identificar osRiscos� Realizar aAnáliseQualitativa dosRiscos� Realizar aAnáliseQuantitativa dosRiscos� PlanejarRespostas aosRiscos

� Monitorar eControlar osRiscos

Aquisições � Planejar asAquisições

� Conduzir asAquisições

� Administrar asAquisições

� Encerrar asAquisições


Processos de Iniciação

Uma vez tomada a decisão de realizar o projeto, é necessárioconstituí-lo formalmente. Segundo o Guia PMBOK®, o grupo de processo iniciação éo processo que define e autoriza o projeto ou uma fase projeto. O grupo de processode iniciação do projeto é composto por dois processos: desenvolver o termo deabertura do projeto e identificar stakeholders.

DESENVOLVER O TERMO DE ABERTURA DO PROJETO

O Termo de Abertura do Projeto (project charter), tem como missão principalautorizar formalmente a realização do projeto. Define os principais elementos doprojeto suficientes para indicar os objetivos, o porquê da realização do projeto(justificativas), a contextualização do projeto na organização, enfim o que é oprojeto.

Para cumprir sua missão essencial, um Termo de Abertura pode conter apenasinformações essenciais, tais como um nome para o projeto e uma breve descrição.Este seria um extremo de um Termo de Abertura de um projeto com o mínimo deinformações disponíveis no momento de sua constituição formal (autorização porquem de direito). No outro extremo poderíamos ter um Termo de Abertura com omáximo de informações capazes de descrever elementos integrantes do projeto queauxiliarão o entendimento do que representa o projeto. Um Termo de Abertura commuitas informações permitirá que, durante seu processo de autorização (aprovação)este conjunto de informações sejam validadas pelo patrocinador (sponsor - principalsignatário da autorização) e pelo cliente do projeto. Aquele que dará o aceite formalno produto (resultado) do projeto.

Nome ou Título do Projeto

Longe de ser uma mera formalidade, a denominação do projeto é um elemento decomunicação que pode cumprir um papel importante na divulgação do projeto para aorganização executora e para stakeholders. Pode ser composto apenas com umaforma resumida de descrever o resultado principal do projeto, como:Desenvolvimento e Instalação de Sistema de Gestão Integrada ou utilizar um sloganque sirva de instrumento de marketing para o projeto. Associados ao nome podemser desenvolvidos identidade visual, logomarcas e outros elementos de comunicaçãopara o projeto.


Cliente do Projeto

Indivíduo que dá o aceite formal no resultado (produto) do projeto. Pode não ser, eem geral não é, o usuário final do produto. Também não é, necessariamente, quempaga pelo projeto. O foco da identificação deste importante stakeholder é o degarantir que o projeto não fique impedido de ser encerrado por indefinição de quemtenha autoridade e competência formal para dar o de acordo formal na principalentrega do projeto. A boa prática recomenda que se busque identificar o indivíduoao invés da designação de um setor, ou diretoria, ou até mesmo uma empresa, paraevitar que caso haja uma mudança na estrutura de pessoal, isso gere impasses naentrega do produto do projeto e impeça o encerramento formal do projeto.

Gerente do Projeto

O Termo de Abertura deve designar e atribuir autoridade formal ao responsável pelarealização do projeto. Na prática, o próprio gerente do projeto, já indicado conduz odesenvolvimento do documento a partir de informações fornecidas pelos principaisstakeholders do projeto.

Patrocinador (Sponsor)

O termo patrocinador dá a conotação de que este stakeholder seja apenas quemprovê recursos financeiros e libera recursos para o projeto, mas ele tem um papelmuito mais abrangente. Dá suporte e cobertura política ao projeto, tem o poder dedecisão quanto às prioridades do projeto e é o principal agente autorizador demudanças no projeto. Pode exercer, ao mesmo tempo, o papel de cliente. Umpatrocinador forte (com poder na organização) e atuante pode ser decisivo aosucesso do projeto.

Descrição do Projeto

Apresentação sumária do projeto. Deve ser sucinta para permitir uma visão geral doque é o projeto. Se forem necessárias mais informações a recomendação é quesejam postas em anexos a fim de que não torne o documento extenso. De modogeral, informações em projetos devem ser postas de forma a serem entendidas omais rápido possível.

Justificativa do Projeto (Problema/Oportunidade)

Um projeto consome recursos, a cada dia, mais escassos, portanto o porquê de suarealização deve ficar bem claro no documento que registra sua constituição. Umprojeto cuja justificativa é forte tende a ter mais apoio da organização executora econsequentemente menos dificuldade em obter os recursos necessários à suaexecução.

Se a organização executora utiliza um processo de seleção e priorização de projetospara tomar a decisão de executar ou não projetos, a princípio, as razões quejustificam o empreendimento já devem ter sido apresentadas.

Mas a justificativa para a realização do projeto vai além da decisão de executá-lo.Serve como fator de motivação para a equipe do projeto, como argumento em


negociações com stakheolders e para o patrocinador defendê-lo política efinanceiramente.

Uma boa justificativa para um projeto deve estar relacionada aos benefícios que eletrará para a organização que podem ser tangíveis ou intangíveis, em forma desolução de um problema ou do aproveitamento de uma oportunidade. Justificativasbaseadas na solução de problemas tendem a ser mais facilmente aceitas do queaquelas que propõem o aproveitamento de oportunidades porque, em geral, oproblema já existe e já está causando efeitos reais, enquanto que a oportunidade,por natureza, é potencial, carrega mais risco.

Neste “campo” a recomendação, também é de objetividade e síntese. Se foremnecessários dados adicionais ou mais detalhados devem vir em anexos ao Termo deAbertura.

Produto do Projeto

O resultado principal que será gerado pelo projeto deve ficar bem claro a fim deevitar expectativas além da capacidade de realização do projeto. O produto doprojeto é a principal entrega produzida pelo projeto.

Pode ser um objeto, por exemplo, um projeto de construção de uma residência. Aresidência pronta para morar seria o produto do projeto. Um serviço, que seriaentregue por um projeto de consultoria. O produto gerado pelo projeto estariamaterializado no relatório com as recomendações da consultoria. O produto de umprojeto pode ser um estado modificado, que seria obtido pela execução de umprojeto de modificação de um layout de um ambiente de trabalho. Deve serquantificável.

O produto do projeto deve ser identificado e tangibilizado de tal forma que, ao final,permita a verificação de que de fato foi entregue e a avaliação da adequação ao quefoi proposto em seu início.

A indefinição do produto do projeto pode levar às partes interessadas no projetocriarem expectativas diferentes em relação àquilo que o projeto efetivamente estariaconfigurado para entregar e causar conflitos, frustrações e prejuízos.

Objetivos e Metas do Projeto

O objetivo mais amplo do projeto, a intenção do projeto, seu requisito maior, suasprioridades, devem ser expressas em objetivos quantificáveis que permitam suaverificação e avaliação do seu desempenho e seus resultados. Devem ser expressosno tempo verbal infinitivo: realizar, entregar, desenvolver.

Se o objetivo de desempenho do projeto descreve o quê o projeto fará, a metadescreve o quanto. Ou seja, a meta é a quantificação de um objetivo. A medida dodesempenho do projeto. Pode haver mais de uma meta para um mesmo objetivo,mas não deve haver objetivo que não comporte a atribuição de pelo menos umameta.

Para o objetivo principal do projeto, relacionado à principal entrega, é recomendávelque se estabeleçam metas nas três principais dimensões do projeto: escopo, tempo


e custo. A determinação de objetivos e metas pode seguir a hierarquia das fases eentregas do projeto. No Termo de Abertura, porém, dado que o projeto está noprocesso de iniciação, os objetivos tendem a ficar em âmbito mais geral, sendo,posteriormente, detalhados.

Metas devem refletir os compromissos assumidos pelo projeto, portanto, podem serreferenciados a elementos ainda não definidos no momento da redação do Termo deAbertura, mas que serão elaborados no planejamento do projeto. Por exemplo: metade não ultrapassar o orçamento do projeto. Meta de não ultrapassar o cronogramaaprovado.

Metas relacionadas ao escopo podem vincular necessidades postas na Declaração doTrabalho (Statement Of Work – SOW - documento que formula as necessidadespostas ao projeto emitido pelos demandantes do projeto), que se tornarãoespecificações de escopo. Por exemplo, no projeto de uma escola: número de salasde aula, número de laboratórios, etc.

As metas serão o referencial de comparação para a avaliação do projeto ao seutérmino. Medirão, portanto, seu desempenho e seu sucesso.

Estimativa de Custos

A finalidade de elaborar uma estimativa de custos ainda no processo de iniciação étentar dimensionar em ordem de grandeza os custos gerais do projeto. Pode ser umaforma de confirmar uma faixa de valor que tenha sido enunciada em um estudo deviabilidade financeira, quando da decisão de realizar ou não o projeto, ou de dar aprimeira idéia do quanto o projeto poderá custar. Neste caso, poderá resultar nadecisão de não continuar com a realização do projeto.

É sempre importante lembrar que, seguindo um princípio geral da administração,quanto mais cedo, mais próximo da origem, tomar-se a decisão de interromper umprocesso que não esteja conforme, mais econômica será esta decisão para aorganização.

A idéia de validação da viabilidade é um pressuposto que permeia todo o processode iniciação do projeto. Durante o processo de iniciação do projeto deve-se procurarconfirmar ou não a decisão de realização do projeto.

Por convenção, que pode variar de acordo com cada organização, a expectativa deprecisão desta estimativa é de -50% a +100% do orçamento final que será apuradono processo de planejamento do projeto.

A consulta a dados históricos de projetos anteriores semelhantes é um recurso deapoio no processo de estimativa de custos do projeto. Porém, se a base histórica nãopossuir referências semelhantes, pode-se solicitar apoio a um fornecedor que astenha ou que possa elaborar uma estimativa. Além do apoio neste momento, estefornecedor figurará como potencial executor de partes do projeto, no caso dedificuldades da organização executora. Funciona, portanto como mitigador de riscos.


Estimativa de Prazo

Infelizmente, a maioria dos projetos conduzidos hoje em dia, não são iniciados apartir de um planejamento, mas de uma reação a uma necessidade, portanto osprazos dos projeto são estabelecidos, e não estimados. O deadline, ou prazo detérmino do projeto já faz parte da demanda. Dessa forma, pode ser classificadocomo uma restrição imposta. Esta imposição influenciará o modelo de programaçãodo cronograma do projeto no processo de planejamento que terá que ser feito paratrás. Ou seja, a partir da data final estabelecida, programar as etapas do projeto.

No caso de não haver esta imposição, o prazo pode ser estimado considerando-sereferências históricas de projetos semelhantes, como recomendado para custos.

Autorização

Salvo regimentos organizacionais específicos, o principal stakeholder autorizador doprojeto é o patrocinador (sponsor). No caso de outros membros da organizaçãoexecutora participarem da autorização, suas assinaturas serão necessárias àaprovação do Termo de Abertura do Projeto.

O processo de aprovação do Termo de Abertura pode consumir um tempoconsiderável em idas e vindas para análises e avaliações, porém é importanteressaltar que um projeto não deve ser autorizado com dúvidas quanto às suasfinalidades.

Por outro lado, é altamente recomendável que não se comece a realizar, ou seja,tomar decisões ou consumir recursos por conta do projeto, sem que o processo deautorização formal esteja concluído.

STAKEHOLDERS (Partes Interessadas) DO PROJETO

Segundo o dicionário Random House: detentores (holders) da aposta (stake). Partesinteressadas é a tradução mais encontrada para essa palavra no contexto degerenciamento de projetos. Significa: todo indivíduo, entidade, enfim qualquerpessoa física ou jurídica que de alguma forma tenha relacionamento, seja atingidaou impactada pelo projeto. Pode influenciar ou ser influenciada pelo projeto. Nodecorrer do projeto ou mesmo após seu encerramento.

A equipe de gerenciamento do projeto tem que identificar os stakeholders, partesinteressadas tanto internas quanto externas à organização executora de maneira adeterminar os requisitos e expectativas dessas partes. Uma vez identificadas, umaanálise deve ser feita para se determinar estratégias de gerenciamento dessas partesinteressadas.

As etapas envolvidas em uma análise de partes interessadas são:

– Identificação de partes interessadas: desenvolver uma lista comnomes dos interessados chaves do projeto, sua função, órgão ouempresa. Em alguns casos, podem ser identificados e listados gruposde interessados que tenham um mesmo perfil ou participação noprojeto.


– Classificação de partes interessadas: cada interessado da lista éidentificado por um código (por exemplo, por letras maiúsculas) e éfeita uma avaliação em relação a seu poder de influenciar o projeto eseu interesse. Além disso, avalia-se se o interesse é positivo ounegativo.

– Elaboração de estratégia: para cada interessado ou grupo deinteressados são desenvolvidas estratégias de relacionamento ecomunicação.

O gráfico abaixo apresenta um exemplo de classificação de partes interessadas queleva em conta o poder e o interesse de cada interessado ou grupo de interessados.

Análise dos Stakeholders (Partes Interessadas do Projeto)

A informação resultante da análise pode ser consolidada em um registro de partesinteressadas (quadro na próxima página). Esse registro é primeiramente elaboradono início do projeto e deve ser mantido atualizado durante todo o ciclo de vida doprojeto.

Certas informações relacionadas a uma ou mais das partes interessadas podem sermuito sensíveis para serem incluídas no registro de partes de interessadas que serátornado público como um documento do projeto. A equipe de gerenciamento deprojeto deve avaliar cada caso e decidir que nível de detalhe será incluído noregistro e que informação merece divulgação restrita.

Em razão dos stakeholders influenciarem positiva ou negativamente o projeto e,consequentemente, seus objetivos, eles são uma fonte primária de riscos ao projeto.


Figura 1 - Registro de Partes Interessadas

Registro dos Stakeholders (Partes Interessadas do Projeto)

Conclusão do processo de iniciação do projeto

Como foi visto, no processo de iniciação são coletadas informações preliminares elevantadas questões gerais relacionadas à capacidade de realização do projeto.

Considera-se que na iniciação faz-se um planejamento de “alto nível”, umplanejamento “macro”, que define as linhas gerais do projeto capazes de fornecer omáximo de subsídios para o patrocinador (sponsor) do projeto tomar a decisão deautorizar a continuidade do trabalho em um planejamento em baixo nível queproduzirá um plano de gerenciamento do projeto detalhado. Dessa forma, elementoschave, tais como premissas e restrições, deverão ser revisados, refinados,detalhados e registrados na declaração do escopo do projeto.


Processo de Planejamento

A conclusão do processo de iniciação indica que o projeto podeseguir em frente e pode-se, então, investir tempo e recursos na elaboração do Planode Gerenciamento do Projeto que é a principal missão e resultado do processo deplanejamento do projeto.

Antes de tratarmos do trabalho que compõe o processo de planejamento, éimportante refletirmos sobre algumas questões de ordem prática que estão longe deserem triviais: por que planejar? Por que dedicar esforço e tempo planejando se jápoderíamos ir direto à execução do projeto? Qual o benefício de planejar se as coisasnão saem exatamente como planejado? Por que elaborar um plano se aprobabilidade de haver mudanças é muito alta? Isto não é perda de tempo?

Não há uma resposta única, mas um posicionamento. É preciso considerar que otrabalho, esforço ou recursos, inclusive de tempo, serão menores do que os gastoscom as conseqüências de uma execução sem planejamento.

O posicionamento a favor do planejamento vem da presunção de que o retrabalhoserá menor se houver planejamento. Por re-trabalho entenda-se todo o trabalho quenão poderá ser aproveitado para o resultado do projeto. Sabemos que mesmo com oplanejamento existe re-trabalho em projetos, dado que é uma atividadeprobabilística e carregada de incerteza.

Porém, a “dose” de planejamento não pode ser prescrita de forma genérica, mas deacordo com cada caso específico. Excesso de tempo e esforço dedicados aoplanejamento pode representar mais perdas do que ganhos. O desafio, portanto, éencontrar o ponto de equilíbrio.

O processo de planejamento do projeto segue uma sequência lógica necessária àelaboração do plano de gerenciamento do projeto.

Em primeiro lugar, define-se o escopo, que representa aquilo que será feito peloprojeto, para em seguida dimensionar-se o tempo necessário para esta realização,que por sua vez, permitirá a quantificação dos custos. Depois, virão as definições daqualidade, dos recursos humanos, da comunicação, dos riscos, enfim, dos demaisparâmetros do projeto.

Apesar de seguir uma lógica de elaboração progressiva, o processo de planejamentoé interativo, pois seus parâmetros são correlacionados, e ao mesmo tempo, éiterativo, isto é, a definição de um elemento pode implicar na necessidade de ajusteem outro anteriormente definido. Por exemplo: durante a definição dos parâmetrosda qualidade do projeto pode-se verificar que um item de escopo precisa sermodificado, gerando, assim a necessidade de redefinição do tempo e dos custos.

Assim sendo, uma vez identificada a intenção de realizar o projeto, é necessárioconstituí-lo formalmente e definir seus principais parâmetros para uma tomada dedecisão quanto à sua execução. Estes parâmetros devem ser documentados de talforma que permitam uma avaliação quanto à capacidade do projeto em alcançarseus objetivos e gerar os benefícios para a organização executora.

Uma boa documentação de um projeto é fator decisivo para seu bom gerenciamentoe para ganhos de produtividade em projetos futuros desenvolvidos pela organização.É muito comum a documentação de projetos ser vista como burocracia no sentidopejorativo do termo, porém, se lembrarmos que projetos são empreendimentos quegeram produtos únicos, é possível perceber a utilidade de se ter referências quediminuam o grau de ineditismo.

Metodologia de Gerenciamento de Projetos

A sistematização da documentação de projetos geralmente está associada ao que sedenomina metodologia de gerenciamento de projetos. Que nada mais é do que adeterminação de processos estruturados e conjunto de documentos recomendadospara o gerenciamento de projetos com a finalidade de diminuir o grau de improvisodas ações de projeto e permitir o alcance de melhores resultados à custa de menosesforço.

Evidentemente durante o processo de incorporação da técnica há um esforço quepode, a princípio, ser considerado desproporcional, ou seja, estaria exigindo maisesforço para documentar do que para fazer. Isto de fato é um risco que deve serconsiderado, pois os limites do que pode ser instrumento gerencial e burocraciaexcessiva é tênue. Há um princípio da administração, enunciado por Henry Fayol(1910), preconizando que: o controle não deve exceder o objeto controlado, isto é,não devemos gastar mais energia para gerenciar do que para fazer.

Para entendermos a aplicação prática de uma metodologia de gerenciamento deprojetos e a documentação associada, podemos fazer uma analogia com a natação.

Um indivíduo que incorporou uma técnica de nado, depois de orientado por umtreinador, passa a despender menos esforço e a obter melhores resultados emrelação a quem nada por instinto, sem técnica específica. No caso da natação, quemdomina a técnica chega mais rápido à outra margem com menos esforço.


A idéia é de que o método de trabalho em projetos, metodologia de gerenciamentode projetos, permita o alcance de resultados efetivos com menos esforço.

Pode parecer que nos primeiros projetos documentados e gerenciados segundo umametodologia adotada, o esforço seja desproporcional, mas a tendência é de que osprojetos subsequentes exijam menos esforço e gerem melhores resultados,representando o efetivo ganho de produtividade.

Plano de Gerenciamento do Projeto

O plano que será a base de referência para a execução do projeto deverá contertodas as orientações necessárias para completar a entregas do projeto. É compostode um conjunto de documentos dedicados ao gerenciamento do projeto.

� ESCOPO

� Declaração do ESCOPO

� WBS – EAP – Estrutura Analítica do Projeto

� TEMPO (Cronograma)

� Gráfico de Gantt

� Diagrama de REDE

� CUSTO

� Orçamento do projeto

� Sistema da Qualidade (Parâmetros e Procedimentos)

� Organograma do Projeto e Matriz de Responsabilidades

� Matriz de Comunicações

� Registro de Riscos (Resposta aos Riscos)

� Sistema de Gerenciamento de Configurações

� Controle Integrado de Mudanças

� Sistema de Documentação

Sistema de Gerenciamento de Configurações

É necessário definir como será realizada a identificação e documentação dascaracterísticas funcionais e físicas do produto e subprodutos do projeto, controle dasmudanças feitas nessas características, registro e relato de cada mudança e oandamento da sua implantação, suporte à auditoria dos produtos para verificarconformidade com os requisitos. Pode definir, também, como será feita o controle deversões dos documentos do projeto.

Controle Integrado de Mudanças

Define os procedimentos para efetuar mudanças nas baselines do projeto ou noescopo do produto do projeto. Determina a documentação necessária, os sistemasde acompanhamento e os níveis de aprovação necessários para autorizar mudanças.


Planos Subsidiários

O gerenciamento do projeto e a manutenção dos elementos do projeto coesos entresi compõem a área de conhecimento integração. A boa prática recomenda que sejaelaborado um plano determinando a melhor estratégia a ser adotada para gerenciarcada uma das demais áreas de conhecimento necessárias ao gerenciamento doprojeto.

� 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 Comunicações

� Plano de Gerenciamento dos Riscos

� Plano de Gerenciamento das Aquisições

Além dos planos de gerenciamento das áreas de conhecimento o plano dogerenciamento do projeto deve conter alguns documentos como: contrato (quandofor o caso; a definição dos objetivos e metas (se houver mudança em relação aoTermo de Abertura).

É necessário, também, tratar de aspectos da organização e da forma como seráconduzido o trabalho do gerenciamento do projeto. Quais processos serão utilizadosno gerenciamento. Que artefatos (documentos, gráficos, tabelas, etc.) serãoelaborados e como será o processo de elaboração. Como serão realizados osprocessos de monitoramento e controle do projeto.

Outra definição importante quanto ao processo de planejamento, diz respeito àsferramentas e técnicas que serão utilizadas nos processos. Por exemplo, determinarque o processo de definição do escopo do projeto utilizará reuniões de brainstorminge 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 dereferência (baseline) a partir da qual o progresso do projeto será avaliado. Sendoassim, as variáveis definidas de escopo, tempo, custo, qualidade, recursos humanos(equipe do projeto), comunicações, riscos e aquisições serão as bases de referênciado projeto como um todo. Significa que quaisquer mudanças nestas referênciasdeverão ser tratadas como mudanças, pois gerarão impactos no projeto.


COLETA DE REQUISITOS

O sucesso do projeto é diretamente influenciado pela atenção na captura egerenciamento dos requisitos do projeto e do produto. Estes requisitos precisam serobtidos, analisados e registrados com detalhe suficientes para sem medidos uma vezque a execução do projeto se inicie. Coletar requisitos envolve definir e gerenciar asexpectativas do cliente. Os requisitos serão o fundamento para o planejamento doescopo do projeto.

Os requisitos podem ser categorizados em requisitos do projeto e requisitos doproduto.

Os requisitos do projeto podem, por sua vez, se encontrar dentro de uma dasseguintes subcategorias:

• Requisitos relacionados com as necessidades de negócio identificadas noTermo de Abertura do Projeto (requisitos de negócio).

• Requisitos relacionados ao gerenciamento do projeto (requisitos de prazo, decusto 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 são aqueles que o produto do projeto precisa atenderdesde sua entrega ao cliente, ao final do projeto, até o fim do ciclo de vida doproduto.

Os requisitos coletados são então documentados em um Documento de Requisitos, eusados como referência para o planejamento e a execução do projeto.

DEFINIÇÃO DO ESCOPO DO PROJETO

Apesar de haver uma pretensão já posta pelos demandantes do projeto, a forma doresultado final, assim como os passos intermediários e o seu processo de elaboração,podem diferir, substancialmente.

Como vimos, projetos não são atividades determinísticas, ou seja, não têm seuresultado garantido, pois são atividades que sempre carregarão uma parcela derisco, ou incerteza, são, portanto, atividades probabilísticas.

Assim sendo, as escolhas possíveis acerca do projeto precisam ser feitas. Esteprocesso faz parte da definição do escopo, tanto de produto quanto de projeto. Odesafio é conseguir antever as conseqüências de cada escolha e identificar osmelhores relações de custo e benefício.

O escopo do projeto é o ponto de partida de todas as outras variáveis do projeto. Otempo, os custos, a qualidade, os recursos humanos necessários, etc., só poderãoser dimensionados se o escopo estiver definido. Ou seja, aquilo que é para ser feito.


Todo o esforço dedicado à uma boa definição de escopo será bem empregado, poisos demais parâmetros do projeto dependem diretamente deste.

Elementos necessários para definição do escopo (input)

Para melhor realizar o processo de definição do escopo é recomendável que se utilizeas informações que estiverem disponíveis até o momento:

� Histórico de projetos anteriores� Declaração do trabalho� Project Charter� Declaração Preliminar do Escopo

Ferramentas e Técnicas utilizadas no processo de definição do escopo

A natureza do produto do projeto irá determinar o conjunto de ferramentas etécnicas mais adequado para realizar a definição do escopo.

Brainstorming

Se o projeto é inédito e requer uma contribuição criativa o brainstorming será umatécnica recomendada, pois consiste numa seção conduzida por um coordenador queestimula os participantes a terem idéias relacionadas ao objeto do projeto semrestrições de pertinência, numa primeira rodada. Ou seja sem censura que reprima acriatividade. Em seguida é feita uma avaliação da pertinência e selecionadas asidéias mais úteis ao projeto.

Opinião de especialistas (presencial ou com a Técnica Delphi)

É importante, sempre que possível, ouvir a opinião de especialistas sobre o tema doprojeto. O método Delphi é uma técnica com algumas semelhaças ao brainstorming,porém com algumas diferenças.

Ambas devem ser conduzidas por um coordenador, ou facilitador, porém no Delphios participantes permanecem anônimos, portanto não devem estar no mesmoambiente físico. O coordenador do processo coloca a questão a ser opinada, recolheas contribuições de cada participante, consolida, repassa os pontos de convergênciasucessivamente até o grupo chegar ao consenso.

Esta técnica tornou-se especialmente útil com a facilidade da comunicação pelainternet. Hoje, podemos colher a opinião de um especialista que esteja do outro ladodo mundo.

Modelos (templates), formulários, normas, checklists

Como apoio ao processo de definição do escopo é conveniente lançar mão dequaisquer modelos, formulários ou listas de verificação que possam ajudar a lembrarde elementos a serem incluídas no escopo.

Listas de verificação (Checklists) que contenham informações típicas relacionadas aotipo do projeto funcionam como uma espécie de roteiro e ajudam, não só a nãodeixar de esquecer de itens importantes, como a ganhar tempo no processo. Por


exemplo, em um projeto de construção de uma residência os itens: estiloarquitetônico, número de quartos, existência de piscina, etc., são típicos.

Análise dos Stakeholders

Não apenas os interessados principais no projeto como o cliente e o patrocinador(sponsor) têm requerimentos que devem ser considerados na composição do escopodo projeto, os demais stakeholders, também, podem sofrer impactos, possuemnecessidades e expectativas que devem ser consideradas e atendidas, na medida emque não comprometam o cumprimento dos objetivos do projeto. Em um projeto demodificação de layout, um determinado setor da empresa pode ter comorequerimento que o trabalho seja interrompido o menor período de tempo possível.Se este requerimento puder ser atendido sem prejudicar a relação de tempo e custodo projeto é recomendável que seja atendido, pois, a princípio, trará economia paraa organização.

Metodologia de Desenvolvimento de Produtos

Todo projeto ao seu término entrega um produto, portanto, as diversas técnicassistematizadas para o desenvolvimento de produtos são, na realidade, técnicas dedefinição de escopo. Engenharia Robusta, Engenharia Simultânea, Prototipagem,QFD – Quality Funtion Deployment, etc.

As principais destas técnicas foram desenvolvidas nos anos 80 e, hoje, já estãomaduras em razão da aplicação intensiva com resultados expressivos em diversasáreas da economia, com literatura disponível para estudos mais aprofundados.

Escopo do Produto e Escopo do Projeto

A boa prática recomenda que para uma melhor organização do trabalho se dividamas informações de escopo em escopo do produto e escopo do projeto.

Escopo do Produto

Este primeiro escopo trata das especificações do resultado que será gerado peloprojeto na sua conclusão. Descreve como será a principal entrega do projeto.Relaciona características, funções e atributos. Deve traduzir os requerimentos postosao projeto em especificações para o resultado.

Especificar o produto do projeto significa diferenciá-lo dos demais do mesmo gênero,torná-lo, especial em suas particularidades, específico. Em um projeto de umaresidência, por exemplo, residência é genérica. A especificação irá definir quantosquartos a residência terá, quantos banheiros, se terá sala de jantar separada da salade estar, qual serão as cores, etc. Todos os requisitos que tornam a residência queserá construída única.

Escopo do Projeto

Todo o trabalho necessário para gerar o produto do projeto com todas as suascaracterísticas especificadas no escopo do produto compõem o escopo do projeto.


Representa todas as entregas intermediárias necessárias para produzir a principalentrega do projeto, para completar o escopo do produto. Para cada especificação deescopo do produto haverá pelo menos uma entrega de escopo de projeto associada.

Entregas (Deliverables) e Marcos (Milestones)

Além do produto final ou resultado principal do projeto, ao longo do seu ciclo devida, serão gerados subprodutos ou resultados parciais. Resultados são gerados porprocessos que seguem o modelo: entrada (input), processo (process) e saída(output), porém no âmbito de projetos é necessário fazer-se uma distinção entre assaídas (outputs) dos processos que não serão avaliadas e validadas por um terceirodaquelas que serão avaliadas pelo próprio executor. As primeiras, ou seja, aquelasque serão avaliadas e validadas por outro que não o próprio executor, sãoconsideradas entregas (deliverables). Os demais resultados serão apenas saídas(outputs).

Portanto, pode-se considerar que as entregas serão objeto de um controle externoao executor. São passíveis de verificação. O próprio termo remete ao movimento detransmissão do executor para o avaliador.

Assim sendo, os momentos em que ocorrem entregas do projeto servem comopontos de referência para a avaliação do progresso do próprio projeto. Estes pontosde verificação são denominados de marcos ou milestones.

A expressão milestone, literalmente pedra da milha, vem da engenharia romana queusava uma pedra para marcar o percurso da estrada a cada de mil pés de umsoldado romano.

O conceito de “marcar” a distância da origem como referência é fundamental para amedição do trabalho realizado no projeto. Se a entrega prevista para ser realizadanaquele momento (ponto no tempo – marco – milestone) tiver sido efetivada, oprojeto estará dentro do cronograma. Se não, estará atrasado.

Dessa forma, o escopo (o trabalho) do projeto deve ser definido pelas entregas queserão necessárias para que o projeto atenda aos seus requisitos.


Critérios de aceitação do produto

É necessário que as regras do jogo estejam bem claras desde o início do projeto.Estes critérios serão a referência que os demandantes do projeto utilizarão paraavaliar se o projeto efetivamente cumpriu aquilo a que se propôs quanto aos seusobjetivos e metas.

São os limites de tolerância para a aceitação formal das entregas do projeto. Serãoutilizados no processo de inspeção realizado pelo cliente, denominado no GuiaPMBOK® de verificação do escopo do projeto. Compara aquilo que foi estabelecidonos requerimentos com o que de fato é entregue.

As metas do projeto são as referências para o estabelecimento dos critérios deaceitação. Uma meta de um projeto de desenvolvimento de um software podeprever que 1.000 usuários façam acesso simultâneo sem perda de performance, eestabelecer como critério de aceitação, que se até 900 o projeto será aceito.

Exclusões Específicas - Itens NÃO incluídos no escopo

Procura definir itens que não serão entregues pelo projeto. Este conjunto deinformações faz-se necessário porque, por melhor que seja a especificação doescopo do projeto, sempre haverá possibilidade de dúvida quanto a configuraçãotanto do produto do projeto quanto ao trabalho para realizá-lo.

Serve, também, para identificar expectativas dos demandantes quanto a entregas,funcionalidades, atributos ou características que não foram explicitadas naDeclaração do Trabalho (Statement of Work).

Há projetos que, por sua natureza, podem gerar elementos de especificaçãoconsiderados óbvios pelo demandante e por isso não são lançados na Declaração doTrabalho. Neste caso esta relação de itens funciona como uma lista de verificação(checklist) daquilo que efetivamente é esperado do projeto.

Premissas

São fatos assumidos como verdadeiros pelas partes demandantes e os realizadoresdo projeto. São as regras do “jogo”. Condições sob as quais o projeto será conduzidoe que, se modificadas, influenciam a capacidade do projeto de alcançar seusresultados. Implicam, portanto, na necessidade de revisão dos parâmetrosestabelecidos para o projeto. Pode-se elencar como premissas em um projeto dedesenvolvimento de um sistema corporativo, por exemplo, que será necessária aautorização de acesso a membros da equipe do projeto aos sistemas da empresa.

Premissas são alvos primários de riscos, porque, se atingidas, normalmente, geramalterações na estrutura do projeto e, conseqüentemente, na capacidade de atingirseus objetivos.

Restrições

São fatores, previamente estabelecidos, que limitam as opções do projeto. Podemser normas organizacionais que precisam ser seguidas, regimentos, legislações, ou


quaisquer obrigações relacionadas ao objeto do projeto. O regimento interno de umedifício pode restringir o trabalho que gere ruído durante o período noturno.

Definição progressiva do escopo

Há projetos cuja dificuldade de definição de escopo é muito grande. Isto ocorre emfunção do ineditismo do produto do projeto, do ambiente tecnológico ser muitovolátil, que é o caso dos projetos de tecnologia da informação, ou mesmo pelasnecessidades serem muito difusas em função de interesses diversos.

Este grau de incerteza pode ser traduzido em função da distância entre o ponto departida e o alvo (escopo) a ser atingido.

Geometricamente percebe-se que quanto maior for esta distância maior será apossibilidade de desvio do alvo. Ou seja, uma pequena variação no início pode, dadaa distância ao alvo, tornar-se grande.

Portanto, a recomendação é de que se procure identificar, sempre que possível,pontos de partição do escopo total que possam ser realizados parcialmente. Ou seja,verificar se é possível dividir o projeto em partes e fechar o acordo de definição doescopo da ou das partes que possibilitem a definição de escopo com razoável graude previsibilidade.

O alvo do projeto passa a ser então B1 e não o todo Bt (total). O compromisso doprojeto é entregar B1. Reduzindo o potencial de desvio.

A entrega B1 será, posteriormente elemento de entrada (input) para o projeto deentrega de B2 e assim sucessivamente até completar a entrega total pretendida (Bt).


A natureza integrativa do planejamento exige que áreas como escopo, tempo e custosejam coordenadas cuidadosamente em um processo iterativo. À medida que maisinformações ou características do projeto são reunidas e compreendidas,planejamento adicional pode ser necessário. O detalhamento progressivo do planode gerenciamento do projeto é geralmente chamado de “planejamento em ondassucessivas”, indicando que o planejamento e a elaboração da documentaçãoassociada são processos contínuos e repetitivos.

A definição do escopo, dessa forma, permite que a demanda real do projeto, ou seja,a razão de sua realização, seja elaborada e formulada progressivamente.

O processo de Verificação do Escopo

Uma vez definido o escopo é necessário determinar como o cliente avaliará a suaefetiva realização. Que procedimentos serão usados para o cliente verificar, constatarse aquilo que foi proposto na declaração do escopo corresponde ao que de fatoestará sendo entregue. Será a aplicação de critérios de aceitação de entregasparciais, ou intermediárias, e do produto final, definidos na declaração do escopo.

ESTRUTURA ANALÍTICA DO PROJETO (EAP)(Work Breakdown Structure – WBS)

Os americanos costumam referir-se à EAP (WBS) como “the big picture of theproject”, no sentido de que é uma imagem que permite a visão do todo, do conjuntocompleto. Possibilita uma visão holística do projeto. Que ao olhar a EAP (WBS)consegue-se “enxergar” tudo aquilo que o projeto irá realizar.

Analisar (Estrutura Analítica) significa decompor em partes menores para melhorcompreender o todo e as partes que o compõem. É exatamente essa a missão daEAP que é a principal ferramenta para o gerenciamento do escopo do projeto.

A decomposição dá-se de cima para baixo, daí o termo em inglês: breakdown, apartir do projeto, que será o primeiro nível, ou nível zero, como preferem algunsautores. Por ser uma ferramenta de escopo, na EAP não aparecem atividades (açõesou tarefas), são representadas apenas entregas geradas pelo projeto (deliverables).


Portanto, nela não são representadas relações de dependência temporal deexecução. A hierarquia da EAP diz respeito a um todo (no nível acima) que écomposto de partes (no nível abaixo).

O segundo nível da EAP representa o ciclo de vida do projeto, pois determina aprimeira partição do projeto, ou seja, suas macro-fases.


1º Nível : Nome do Projeto11ºº NNíível : Nome do Projetovel : Nome do Projeto

1. PROJETO1. PROJETO1. PROJETO

2.1 Fase 12.1 Fase 12.1 Fase 1 2.2 Fase 22.2 Fase 22.2 Fase 2 2.3 Fase 32.3 Fase 32.3 Fase 3

3.6 Entrega3.6 Entrega3.6 Entrega3.5 Entrega3.5 Entrega3.5 Entrega

4.12 PT4.12 PT4.12 PT4.11 PT4.11 PT4.11 PT4.10 PT4.10 PT4.10 PT4.9 PT4.9 PT4.9 PT





1º Nível : Nome do Projeto11ºº NNíível : Nome do Projetovel : Nome do Projeto









2º Nível : Ciclo de Vida do Projeto22ºº NNíível : Ciclo de Vida do Projetovel : Ciclo de Vida do Projeto









2º Nível : Ciclo de Vida do Projeto22ºº NNíível : Ciclo de Vida do Projetovel : Ciclo de Vida do Projeto









O projeto é, então, sucessivamente sendo “quebrado” (break), em níveis de entregascada vez menores até o menor nível desejado para detalhamento do escopo doprojeto. Este nível é denominado no Guia PMBOK® de “pacote de trabalho”.

A decisão de até onde decompor é determinada por alguns fatores relacionados àforma pela qual o projeto será gerenciado.

Novamente se apresenta uma situação de trade-off, ou seja, faz-se necessária umaavaliação de custo/benefício entre detalhar (decompor) ou não decompor.

A favor da maior decomposição pesa o fato de permitir uma melhor identificação(visualização) das menores partes e com isso aumentar a previsibilidade de projeto.Porém este maior detalhamento implica em maior esforço de planejamento eposterior controle.

O último nível de decomposição da EAP, ou detalhamento do projeto estárelacionado ao nível de domínio e controle que se deseja exercer sobre os elementosde escopo do projeto, isto é, se for necessário que um elemento de escopo sejarealizado exatamente de determinada forma, então será necessário o detalhamento.

Por exemplo, em um projeto de um evento, onde a EAP for decomposta até o nívelde aquisição das passagens aéreas dos participantes e não for relevante oudeterminante que a entrega seja decomposta em: prospecção, seleção econtratação, isto é se os detalhes de como a entrega será realizada não foremimportantes e não requererem um controle de execução das partes, não hánecessidade de decompor esta entrega. Neste caso a supervisão e o controle irá atéo nível de entrega das passagens aéreas.


3º Nível : Principais entregas do projeto33ºº NNíível : Principais entregas do projetovel : Principais entregas do projeto









3º Nível : Principais entregas do projeto33ºº NNíível : Principais entregas do projetovel : Principais entregas do projeto









Último Nível : Pacotes de Trabalho (menor entrega do projeto)

ÚÚltimo Nltimo Níível : Pacotes de Trabalho vel : Pacotes de Trabalho (menor entrega do projeto)(menor entrega do projeto)









Último Nível : Pacotes de Trabalho (menor entrega do projeto)

ÚÚltimo Nltimo Níível : Pacotes de Trabalho vel : Pacotes de Trabalho (menor entrega do projeto)(menor entrega do projeto)









Possíveis EAP (Estrutura Analítica

do Projeto – WBS – Work

Breakdown Structure) para um

mesmo projeto.


O projeto é, então,sucessivamente “quebrado”(break), em subprodutoscada vez menores até omenor nível desejado paradetalhamento do escopo doprojeto.

Ainda relacionado ao controle está o princípio 8/80 que recomenda que um pacotede trabalho não tenha menos do que 8 e não mais do que 80 horas de duração. Oque equivale recomendar que o menor ciclo de controle do projeto não seja menordo que um dia (8 horas) e não maior do que duas semanas (2 semanas de trabalhode 40 horas)

Outro fator determinante para a parada da decomposição é se a entrega serárealizada por um terceiro. Mesmo que seja da própria organização executora, nocaso de um setor de Marketing que irá preparar um plano de marketing para oprojeto, nestes casos, o gestor do projeto figurará como um demandante de umprojeto (sub-projeto) e não haverá necessidade de detalhar o “como” da entregaterceirizada.

Decomposição dos pacotes de trabalho em atividades que formarão o diagrama de rede do projeto

Formas de EAP

A estruturação do projeto pode dá-se da maneira mais conveniente para osexecutores do projeto. Pode ser em formato de uma lista indentada ou emdistribuição radial, conforme exemplos abaixo.


Funções da EAP

Além da missão de identificar a plenitude do trabalho do projeto, seguindo oprincípio dos 100%, que determinam que 100% do trabalho do projeto deve estarrepresentado na EAP, esta permite ou facilita a elaboração de uma série deelementos do projeto.

Por sua estrutura refletir a hierarquia de construção do projeto a EAP permite, compequenos ajustes, a elaboração do organograma do projeto.

A EAP pode servir como referência para uma identificação e tratamento de riscos apartir de cada entrega.


PROJETOPROJETOPROJETO

Fase 2Fase 2Fase 2

Entrega BEntrega BEntrega BEntrega AEntrega AEntrega A

PT 4PT 4PT 4PT 3PT 3PT 3PT 2PT 2PT 2PT 1PT 1PT 1

Gerente do ProjetoGerente do ProjetoGerente do Projeto

Resp. Fase 2Resp. Fase 2Resp. Fase 2

Resp.Ent.BResp.Resp. EntEnt .B.BResp.Ent.AResp.Resp. EntEnt .A.A

R.PT 4R.PT 4R.PT 4R.PT 3R.PT 3R.PT 3R. PT 2R. PT 2R. PT 2R.PT 1R.PT 1R.PT 1

Permite a atribuição específica de responsabilidades por

entregas


Fase 2Fase 2Fase 2

Entrega BEntrega BEntrega BEntrega AEntrega AEntrega A

PT 4PT 4PT 4PT 3PT 3PT 3PT 2PT 2PT 2PT 1PT 1PT 1


Resp. Fase 2Resp. Fase 2Resp. Fase 2

Resp.Ent.BResp.Resp. EntEnt .B.BResp.Ent.AResp.Resp. EntEnt .A.A

R.PT 4R.PT 4R.PT 4R.PT 3R.PT 3R.PT 3R. PT 2R. PT 2R. PT 2R.PT 1R.PT 1R.PT 1

Permite a atribuição específica de responsabilidades por

entregas

Estimativas de custo tornam-se mais simples se seguirem a seqüência inversa daEAP, ou seja de baixo para cima (Bottom Up).

O último nível da EAP, os pacotes de trabalho, uma vez decompostos, identificarãoas atividades do projeto que é, sob o ponto de vista do processo de decomposição, amenor célula do projeto. Com as atividades identificadas será possível construir ocronograma do projeto.

A EAP está diretamente relacionada à natureza do produto do projeto. Significa queprojetos de mesma natureza, como por exemplo, projetos de desenvolvimento desoftware que utilizem a mesma metodologia, terão EAP muito parecidas, podendo,inclusive, ser aproveitadas como modelo.

Dicionário da EAP (WBS)

As entregas indicadas na EAP devem ser descritas de forma sucinta, portanto há anecessidade de descrevê-las de forma mais detalhada. Para isso, a boa práticarecomenda que seja elaborado um dicionário, uma espécie de glossário da EAP(WBS), no qual serão detalhados os significados e os elementos mais importantesdas entregas do projeto.



Fase 2Fase 2Fase 2

EntregaEntregaEntregaEntregaEntregaEntrega

PTPTPTPTPTPTPTPTPTPTPTPT

Identificação de Riscos Associados por entregas

Tratamento de Riscos Associados

por entregas PROJETOPROJETOPROJETO

Fase 2Fase 2Fase 2

EntregaEntregaEntregaEntregaEntregaEntrega

PTPTPTPTPTPTPTPTPTPTPTPT

Identificação de Riscos Associados por entregas

Tratamento de Riscos Associados

por entregas

100100100

505050505050

252525252525252525252525

100100100

505050505050

252525252525252525252525

Modelo de Dicionário da EAP (WBS). As informações essenciais são o código e a descrição da entrega as

demais, inclusive de outras áreas de conhecimento, tais como duração, custo etc., serão documentadas

na sequência do processo de planejamento

CRONOGRAMA DO PROJETO

O desenvolvimento do cronograma do projeto envolve a definição das atividades eseu sequenciamento, a determinação dos recursos humanos e materiais necessáriosà realização das atividades, a estimativa da duração das atividades e oposicionamento em um calendário real em que sejam consideradas as limitações deperíodos de trabalho.

1- DEFINIÇÃO DE ATIVIDADES

A decomposição das entregas do último nível da EAP (pacotes de trabalho)identificará as atividades necessárias para a realização das entregas previstas peloprojeto. Estas serão as menores unidades de execução do projeto. As atividadespermitirão demonstrar as mais detalhadas relações de dependência necessárias àelaboração do diagrama de rede do projeto.


Data da AprovaçãoAprovador da Entrega

Critérios de Aceitação

Sucessor

Custo

Responsável

Aprovador da Execução

Predecessor

Duração

Recursos

Produto (Deliverable)

Descrição da Entrega

Código #

Data da Aprovação

Restrições

Milestones (Marcos)

DICIONÁRIO DA WBS

Versão #Data última atualização

Data da AprovaçãoAprovador da Entrega

Critérios de Aceitação

Sucessor

Custo

Responsável

Aprovador da Execução

Predecessor

Duração

Recursos

Produto (Deliverable)

Descrição da Entrega

Código #

Data da Aprovação

Restrições

Milestones (Marcos)

DICIONÁRIO DA WBS

Versão #Data última atualização

2- SEQUENCIAMENTO DAS ATIVIDADES

Sequenciar as atividades do projeto significa determinar as relações de dependêncialógica entre as atividades. A dependência lógica é uma relação de causa e efeitoentre atividades na qual: a atividade PREDECESSORA é a causadora da SUCESSORA.Ou seja, a atividade SUCESSORA é determinada, influenciada, pela atividadePREDECESSORA. A dependência lógica não é uma dependência cronológica, isto é aatividade SUCESSORA pode ser realizada antes no tempo da atividadePREDECESSORA.

As atividades preparação para a prova e a marcação da data da prova podem ilustraressa diferença, pois dependendo das condições podem assumir o papel tanto dePREDECESSORA como de SUCESSORA.


Tipos de dependências

Dependências Obrigatórias – Seguem uma lógica rígida (hard logic). Dada anatureza das atividades, a atividade sucessora depende necessariamente dapredecessora. É fisicamente impossível ser invertida. Por exemplo: a pintura de umaparede depende do emboço.

Dependências Facultativas – Há atividades, porém que não apresentamdependência lógica entre si, mas por conveniência, ou preferência, o gestor doprojeto estabelece uma relação de dependência. Também denominada dedependência arbitrada ou discricionária (soft logic), passa a existir por decisão dogestor do projeto em função de ser uma melhor composição de acordo com asmelhores práticas do ramo de atividade relacionada ao projeto, ou de experiênciasem projetos anteriores. Por decisão gerencial, podem ser desfeitas ou invertidas.

Dependências Externas – Fatores externos ao projeto podem ter relacionamentosque gerem restrições à forma pela qual as atividades podem ser conduzidas. Umaaprovação governamental, por exemplo, irá limitar as atividades que dependam dela.

Relações de Dependência entre atividades


Todo projeto, por definição, tem início e fim definidos previamente, ou seja, umponto de partida e outro de chegada, portanto é possível representar graficamenteas atividades do projeto em sequências determinadas pelas relações de dependênciaentre elas em forma de uma rede.

No diagrama de rede, ou diagrama de precedência (PDM – Precedence DiagrammingMethod), são identificadas quais atividades serão executadas em série e quais serãodesenvolvidas simultaneamente, ou em paralelo.

Os conjuntos de atividades dependentes entre si são denominados de caminhos. Umprojeto pode ter muitos caminhos, mas todos eles partirão do ponto de início eterminarão no ponto de fim do projeto. A rede acima apresenta os seguintescaminhos: Início-A-B-D-Fim; Início-A-B-E-Fim e Início-A-C-E-Fim.


Exemplo da determinação das dependências entre as atividades e o consequente diagrama de rede

3- ESTIMATIVA DE RECURSOS

A fim de poder calcular as durações das atividades é necessário determinar querecursos humanos, materiais e de equipamentos serão utilizados, ou seja, osrecursos executores das atividades.

É preciso identificar as disponibilidades de cada um dos recursos, a fim de que nãohaja superalocações, se o recurso é próprio da organização ou será contratado deterceiros, assim como suas capacidades de desempenho.

Havendo a possibilidade do recurso a ser utilizado na realização da atividade énecessário que cada recurso seja associado, atribuído, a cada atividade, conformefigura a seguir.


No caso de recursos humanos é importante identificar suas produtividades quedependem de suas competências específicas relacionadas à natureza da atividade,de suas experiências anteriores, nas suas formações e perfis profissionais.

Quanto aos equipamentos é importante, na medida do possível, diferenciar acapacidade nominal, a prevista no manual, da capacidade real, ou efetiva, pois umasuperestimação de desempenho pode gerar falsas expectativas que no momento daexecução serão frustradas.

4- ESTIMATIVA DE DURAÇÃO DAS ATIVIDADES

Uma vez que os recursos executores com suas respectivas capacidades dedesempenho foram determinados, é possível estimar o tempo de duração dasatividades.

A duração da atividade como função da relação entre o trabalho e os recursosdeterminados para executá-lo faz com que o aumento do número de recursos parauma mesma quantidade de trabalho, ou esforço, gere uma redução na duração,conforme gráfico a seguir:

Entretanto, esta relação matemática, na prática não se confirma, pois segue oprincípio de economia dos lucros cessantes ou retornos decrescentes (Law ofDiminushing Returns), que considera que o ganho de produtividade com a adição derecursos não é linear, isto é, na realidade os recursos têm competências oucapacidades diferentes, portanto gerando desempenhos diferentes.


Sendo assim, estas perdas devem ser compensadas quando forem feitas asestimativas de duração das atividades.

Ao realizar o processo de estimar duração das atividades é necessário determinar ograu de precisão requerido. Uma estimativa com maior precisão, se por um lado geramaior confiabilidade, por outro requer mais esforço, utilização e manipulação de maisdados e informações, portanto tem maior custo.

Em casos onde não é possível obter informações mais precisas, pode-se estimar aduração por analogia, isto é, comparando com experiências anteriores. Valeressaltar, que se deve ter o cuidado em comparar grandezas de mesma ordem ecaracterísticas.

A melhor condição de confiabilidade para a estimativa é que seja obtida do própriorecurso escalado para executar a atividade e que sua produtividade real sejaconhecida do gestor do projeto.

Na impossibilidade de definição do executor o gestor do projeto terá que realizar aestimativa a partir da opinião de um especialista na matéria, de tempos padrão emfunção do tipo da atividade, ou de cálculos paramétricos, ou seja, a multiplicação dequantidades por produtividades. Modelos matemáticos que estabelecem correlaçõesentre variáveis: metros por hora, montagens por dia, etc.

O processo de elaboração da estimativa, entretanto, é determinante na qualidadedos esforços e tempos estimados. Uma simples solicitação de prazo pelo gestor doprojeto ao executor pode esconder distorções significativas. Vale a pena analisaralgumas situações típicas e seus efeitos nos parâmetros do projeto.

Estimativa do Executor

Neste caso, o gestor do projeto solicita ao executor que estime a duração de umaatividade. De modo geral, o executor faz uma análise superficial, pois, infelizmente,não é prática comum ter-se controles de time sheet ou apontamento de horascorrelacionando período de trabalho e tarefa ou atividade de projeto. Assim, a partir


apenas de uma idéia do volume de trabalho já comprometido, o executor forneceuma estimativa maior do que real para se defender de cobranças acerca do nãocumprimento do compromisso. O esquema abaixo procura ilustrar esta relação.

Nas estimativas fornecidas pelo executor, em geral, há a inclusão de uma margemde segurança para o cumprimento do “compromisso”. O executor não gosta de tersua estimativa não confirmada, portanto é natural que queira se proteger colocando“colchões” (padding). Cabe ao gestor do projeto tentar identificar os excessos enegociar, com base em históricos anteriores ou outras fontes uma maior adequação.

Estimativa do Gestor do Projeto

Aqui o gestor do projeto estima por sua conta a duração da atividade considerandoque o executor a realizará no período estabelecido e dedicará seu tempointegralmente a execução da atividade.

Estimativa Conjunta – Gestor do Projeto e Executor

Neste caso, o gestor do projeto e o executor da atividade analisam os períodosefetivamente disponíveis e que realisticamente serão dedicados ao trabalho naatividade e negociam uma distribuição da carga de trabalho e chegam à duração daatividade.


Estimativas Probabilísticas - Estimativa a partir de cálculos estatísticos queconsidera três valores de estimativa (Three points Estimate): a estimativa maisotimista, a mais pessimista, a mais provável.

Esta modelagem foi elaborada para aplicação em projetos no final da década de 50durante o desenvolvimento da série de submarinos Polaris para a Marinha Americanae foi denominada de PERT (Program Evaluation and Review Technique).

Este método de estimar é perfeitamente coerente com a natureza da atividadeprojeto que é essencialmente probabilística. Apresenta as estimativas como faixas devalores possíveis e não como um palpite certeiro que dificilmente seria cumprido.

No primeiro passo, a formulação estatística soma os tempos otimistas e pessimistasao mais provável multiplicado por 4.

Esta média considera a proporção probabilística de ocorrência da mais provável egera um efeito de compensação dos extremos estimados. Ou seja, uma estimativaque tenderia a ser muito otimista, ao aplicar a fórmula é compensada em direção avalores pessimistas, e vice e versa.

Após esta mediação é necessário estabelecer a faixa de expectativa de precisão, ouseja, o intervalo a partir do qual será estabelecido o compromisso do projeto. Noexemplo a seguir, estimativas calculadas com base na fórmula probabilística.


E =O + 4M + P

6E =

O + 4M + P6

F

TO PM

F

TO PM

F

TO PM

F

TO PM E

F

TO PME

E = M E < ME > M

F

TO PM

F

TO PM E

F

TO PME

E = M E < ME > M

O intervalo de precisão é determinado pelos desvios padrões considerados. Para umdesvio padrão a expectativa de cumprimento da estimativa é de 68,26%, se foremconsiderados dois desvios padrão, sobe para 95,46% e se forem três, para 99,73%.

A natureza da atividade, sua complexidade, seu ineditismo, etc., será determinantepara a aplicação de uma faixa maior ou menor de estimativa.

Para o cálculo do desvio padrão pode ser utilizada a fórmula empírica onde:


2321Preparar KITsJ

6864Receber inscriçõesI

473,53Imprimir material para participantesH

2321Enviar divulgaçãoG

594,53Obter maillingF

911103Desenvolver material de divulgaçãoE

6864Obter palestrantesD

5654Escolha do localC

5852Determinação do tema e do programaB

2321Determinação da data da conferênciaA

Estimativa(E)

Pessimista(P)

Média(M)

Otimista(O)

ATIVIDADE

2321Preparar KITsJ

6864Receber inscriçõesI

473,53Imprimir material para participantesH

2321Enviar divulgaçãoG

594,53Obter maillingF

911103Desenvolver material de divulgaçãoE

6864Obter palestrantesD

5654Escolha do localC

5852Determinação do tema e do programaB

2321Determinação da data da conferênciaA

Estimativa(E)

Pessimista(P)

Média(M)

Otimista(O)

ATIVIDADE

F

T1s

68,26 %

2s

3s

95,46 %

99,73 %

1s

2s

3s

F

T1s

68,26 %

2s

3s

95,46 %

99,73 %

1s

2s

3s

s =P - O

6

DesvioPadrão

ss =

P - O

6

DesvioPadrão

s

Dessa forma a estimativa de duração da atividade “E” estaria entre 7,67 e 10,33 diascom a precisão de 1 desvio padrão, estaria entre 6,34 e 11,66 dias com a precisãode 2 desvios padrão e entre 5,01 e 12,99 dias com a precisão de 3 desvios padrãode tolerância.

Caminho Crítico

O método do caminho crítico (CPM - Critical Path Method) foi uma importantecontribuição para o gerenciamento de projetos, desenvolvida, no final da década de50, pelo pessoal da companhia americana Duppont e a inglesa Remington.

O conceito baseia-se no modelo de rede que identifica “caminhos”, que sãoconjuntos de atividades dependentes entre si. Dos caminhos do projeto um ou maisdeles terá ou terão maior duração. Este ou estes caminhos, determinam a duraçãototal do projeto. Este ou estes caminhos, serão considerados críticos porquequalquer atraso nele ou neles resultará em atraso do projeto.

Os demais caminhos terão, portanto, menor duração. Esta diferença de duração serátratada como folga. Sendo assim o caminho crítico será aquele ou aqueles com amenor folga ou com folga igual a zero, no caso do tempo permitido ou demandadoao projeto ser igual ao tempo calculado ou estimado. Por exemplo, se o produto deum projeto precisa ser entregue no dia 30 e a estimativa calculada prevê que oprojeto poderá ser entregue no dia 25. Neste caso há uma folga de projeto que serátambém do caminho crítico. Portanto, o caminho crítico, nesse caso será o de menorfolga.


7.67a

10.33

Range de Estimativa

1 s

9,00

Estimativa(E)

1,33

DesvioPadrão

1,77

Variância

9,00+ ou -1,33

11,0010,003,00Desenvolver material de divulgação

E

Range de Estimativa

1 sPessimista

(P)Média(M)

Otimista(O)

ATIVIDADE

7.67a

10.33

Range de Estimativa

1 s

9,00

Estimativa(E)

1,33

DesvioPadrão

1,77

Variância

9,00+ ou -1,33

11,0010,003,00Desenvolver material de divulgação

E

Range de Estimativa

1 sPessimista

(P)Média(M)

Otimista(O)

ATIVIDADE

6,34a

11,66

2 s9,00+ ou -2,66

2 s6,34a

11,66

2 s9,00+ ou -2,66

2 s

5,01a

12,99

3 s9,00+ ou -3,99

3 s5,01a

12,99

3 s9,00+ ou -3,99

3 s

É importante ressaltar que as folgas dos demais caminhos, não-críticos são recursosvaliosos a serem utilizados pelo gestor do projeto e não tempo disponível para serdesperdiçado. Uma manipulação adequada das folgas de caminhos não-críticos podegerar economias de tempo e custo significativas ao projeto, como veremos nosmétodos de compressão ou redução de cronograma.

Para calcular o Caminho Crítico é necessário seguir uma rotina que será descritapasso-a-passo a seguir.

Antes de mais nada, é necessário definir o que são inícios mais cedo e mais tarde etérminos mais cedo e mais tarde. Considerando-se o conceito de folga, onde haveráa possibilidade de executar as atividades de caminhos que não são críticos, queportanto, têm folgas, dentro de um intervalo de tempo igual a folga semcomprometer o projeto, ou seja, sem ultrapassar a duração do caminho crítico.Sendo assim estas atividades poderão começar a ser executadas em um momentomais cedo ou em um momento mais tarde no cronograma sem atrasar o projeto.Conseqüentemente, somando-se a duração estimada para a atividade teremos seustérminos mais cedo e mais tarde.

Representação gráfica da rede com a Atividade no Nó (Activiti-on-node – AON)


2321 226 7 8 9 10 252420191817161514131211 2321 226 7 8 9 10 252420191817161514131211

Início mais CEDO Término mais CEDO

2321 226 7 8 9 10 252420191817161514131211 2321 226 7 8 9 10 252420191817161514131211

Início mais TARDE Término mais TARDE

Para o cálculo do caminho crítico é necessário analisar as atividades do projeto a fimde estabelecer as relações de dependência a fim de encontrar os caminhos da rededo projeto.

Em seguida, calcula-se os tempos de início e término mais cedo de cada atividade.


� Atividade A pode começar imediatamente e tem uma estimativa de duração de 3 semanas

� Atividade B pode começar após a atividade A ser completada e tem uma estimativa de duração de 3 semanas

� Atividade C pode começar após a atividade A ser completada e tem uma estimativa de duração de seis semanas

� Atividade D pode começar após a atividade B ser completada e tem uma estimativa de duração de oito semanas

� Atividade E pode começar após a atividade C e D serem completadas e tem uma estimativa de duração de quatro semanas

3AB

6AC

8BD

4C, DE

-

Ant.

3A

DuraçãoATIV.

3AB

6AC

8BD

4C, DE

-

Ant.

3A

DuraçãoATIV.

3A 3A

3B 3B 8D 8D

4E 4E

6C 6C

0

INÍCIO

0

INÍCIO FIMFIM

30

3A

30

3A

63

3B

63

3B 8D 8D

4E 4E

6C 6C

Término Mais Cedo de B = Término Mais Cedo de A + Duração de B

0

INÍCIO

0

INÍCIO FIMFIM

Depois o cálculo dos tempos mais tarde.

Com isso é possível identificar o caminho crítico do projeto, que, neste caso, temfolga igual a zero. O outro caminho possui folga de 5 semanas.

O diagrama de rede, portanto, permite identificar as relações de dependência entreas atividades e o caminho crítico do projeto.


30

3A

30

3A

63

3B

63

3B

146

8D

146

8D

1814

4E

1814

4E

93

6C

93

6C

Início Mais Cedo de E (Convergência) = Término Mais Cedo da Atividade de

Maior Término Mais cedo das convergentes

14 > 9

0

INÍCIO

0

INÍCIO

1818

FIM

1818

FIM

Tempo Total do Projeto Estimado

Se houvesse mais tempo permitidoEste valor seria diferente

Por Exemplo: 20. O Projeto teria uma folga de 2 semanas

30

30

3A

30

30

3A

63

63

3B

63

63

3B

146

146

8D

146

146

8D

1814

1814

4E

1814

1814

4E

148

93

6C

148

93

6C

00

INÍCIO

00

INÍCIO

1818

FIM

1818

FIM

3 menor que 8FOLGA em C14 – 9 = 58 – 3 = 5

Se houvesse folga total para o ProjetoApareceria aqui

30

30

3A

30

30

3A

63

63

3B

63

63

3B

146

146

8D

146

146

8D

1814

1814

4E

1814

1814

4E

148

93

6C

148

93

6C

00

INÍCIO

00

INÍCIO

1818

FIM

1818

FIM

Início-A-C-E-Fim

Início-A-B-D-E-Fim

CAMINHOS

13

18

Dur

Início-A-C-E-Fim

Início-A-B-D-E-Fim

CAMINHOS

13

18

Dur

Gráfico de Gantt

Cada ferramenta utilizada para o gerenciamento do projeto tem uma finalidadeespecífica e apresenta um conjunto diferente de informações. O gráfico de barrasdesenvolvido pelo Engenheiro Gantt no final da década de 20 mostra a proporção deduração das atividades em uma escala de tempo. Mostra, também, osposicionamentos dos períodos de duração das atividades. Permite visualizar maisfacilmente quanto de interseção há entre os momentos de realização das atividades.

Gráfico de Gantt (ou Barras)

Algumas regras precisam ser respeitadas quando do desenho de um gráfico deGantt. A escala de tempo não deve ser modificada em um mesmo desenho, pois issogeraria perda da visualização da proporção das durações. A recomendação é de quese faça gráficos diferentes para cada escala de visualização. No caso de um projetode duração de 5 anos, poderia ser feito um gráfico em anos, outro em semestres,outro em trimestres, meses e até semanas. Da mesma forma, não se deve fazercortes no meio do gráfico para encurtá-lo.

Gráfico de Gantt (ou Barras) e Diagrama de Rede, compondo o Cronograma do Projeto


Atividade E

Atividade D

Atividade C

Atividade B

Atividade A

19181716151413121110987654321Atividades

Atividade E

Atividade D

Atividade C

Atividade B

Atividade A

19181716151413121110987654321Atividades

Redução do Cronograma (Schedule Compression)

Após a elaboração do cronograma pode-se constatar que os prazos calculados nãoatendem aos requisitos do projeto. Neste caso, deve-se procurar alternativas deredução do cronograma que mantenham a melhor relação de custo benefício.

Fast Tracking (Paralelismo) – A técnica consiste na análise de atividades doCAMINHO CRÍTICO, que foram programadas para serem executadas em seqüêncialinear a fim de verificar a possibilidade de passarem a ser executadas em paralelo,simultaneamente.

As atividades do Caminho Crítico cujas relações de dependência são arbitradas eforam planejadas em seqüência linear por conveniência de projeto, serão os alvosprimários da análise de Fast Tracking, porém as atividades com dependênciasobrigatórias também podem permitir um Fast Traking parcial. Ou seja uma parte daatividades poderá ser executada em paralelo ou simultaneamente.

O Fast Tracking tanto total quanto parcial aumenta o risco de atraso do projeto, poisaumenta a necessidade de gerenciamento. Atividades ocorrendo em paralelo,simultaneamente, exigem maior supervisão. Os pontos de autorização do início dasucessora são, em geral, difusos, isto é, são obtidos por cálculos paramétricos. Porexemplo: após 1 metro de cola aplicada será possível começar a colação do papel deparede.

Pode exigir também, conforme a natureza das atividades a adição de mais recursospara executar ambas as atividades.

Não é possível afirmar genericamente que isto, necessariamente, levaria a umaumento de custo, pois os ganhos com o tempo de execução podem compensar e


A

D

I

B

C

Fim

FE G

H

A

D

I

B

C

Fim

F

E

G

H

T T - FT FT

Ganho de tempo com o Fast

Traking

até mesmo ultrapassarem o valor dos recursos adicionais. Por isso, tanto nestemétodo como no seguinte, é necessária uma análise de trade-off, isto é avaliar qualopção trará mais vantagens para o projeto.

Crashing (Compressão) – Mais uma vez o Caminho Crítico será o alvo de umaanálise que verificará se a adição, troca ou realocação de recursos poderá gerarganhos de tempo no cronograma. Também, neste método as trade-off sãonecessárias.

Na adição de recursos é necessário considerar a influência nos resultados de algunsfatores.

1- Se a atividade é sensível à duração, ou seja, se a adição de recurso de fatodiminuirá sua duração. Por exemplo, em um projeto de uma casa, a atividadede concretagem da laje requer um número necessário e suficiente derecursos humanos e de equipamentos para a realização do trabalho delançamento e assentamento do concreto que determinam sua duração. Nãohaverá redução de duração se houver um acréscimo de recursos nestaatividade.

2- A lei dos retornos decrescentes (Law of Dimininushing Returns), citadaanteriormente, deve-se considerar fatores tais como: a maior necessidade desupervisão, perdas por processos de setup redundantes, etc.

3- É necessário avaliar (trade-off), se o custo do recurso adicional irá ultrapassaros ganhos de desempenho. Se isto acontecer, e o fator crítico de sucesso doprojeto for custo, a adição não será uma alternativa viável.

CUSTOS DO PROJETO

Uma vez definidos o escopo, o que fazer, e o tempo necessário para fazer o queprecisa ser feito no projeto, pode-se estimar o quanto irá custar o projeto. Como emtodo o processo de planejamento a modo como o custo será tratado no projetoprecisa ser planejado. Será necessário elaborar o plano de gerenciamento de custosdo projeto que indicará a estrutura de custos do projeto determinando a classificaçãodos centros de custos, critérios de rateios, reservas previstas, etc., ou seja, definirá aestratégia a ser adotada na orçamentação do projeto.

Classificação dos Custos

A forma geral, contábil, de classificar custos leva em consideração o ponto de vistada empresa, isto é, o referencial é a empresa. Para uma classificação que sirva aogerenciamento do projeto, deve-se classificar custos sob a perspectiva do projeto, ouseja, tendo como referencial o projeto e não a empresa.

Custos Fixos e Variáveis – Custos que não variam com o tempo, nem com aintensidade de utilização, nem com o volume de serviços gerados pelo projeto, sãoclassificados como fixos. São custos que, independentemente da duração, ou dequaisquer variáveis do projeto, terão o mesmo valor. Se, ao contrário da situaçãoanterior, os custos variarem de valor conforme o uso eles serão classificados comocustos variáveis.


O custo do transporte de um equipamento, que será usado no projeto, é umexemplo de custo fixo. Já o custo de mão-de-obra para a execução de uma atividadedo projeto é um exemplo de custo variável, pois seu valor dependerá da duração daatividade.

Custos Indiretos e Diretos – Um custo será indireto se não conseguirmos atribuí-lo direta e especificamente a uma única atividade do projeto. Isto é, se deste custobeneficiarem-se mais de uma atividade do projeto. Neste caso haverá a necessidadede um rateio entre as atividades beneficiadas para que elas absorvam a proporçãodevida a cada uma do custo. Se, ao contrário, conseguirmos atribuir diretamente auma única atividade um custo este será classificado como um custo direto.

O salário 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 critérios que sejam capazesde representar a verdadeira proporção de dedicação do coordenador. Já o custo deum equipamento que será utilizado exclusivamente para a execução de uma únicaatividade deverá ser classificado como um custo direto.

Uma classificação de custos realizada de forma indevida pode levar a distorções quemascarem a real distribuição dos custos no projeto, podendo gerar decisõesdesfavoráveis aos objetivos do projeto.

Alocação dos custos no projeto

A fim de representar o real impacto dos custos nas partes específicas do projeto énecessário que seja feita a apropriação de custos. A cada atividade do projeto deveráser apropriado os valores correspondente aos seus custos diretos e à carga doscustos indiretos que lhes são devidas seguindo critérios de rateio.

Atribuição (vinculação) dos custos a cada atividade do projeto


A correta alocação dos custos do projeto gerará uma curva de custos incorporadosque será o balizador de monitoramento e controle dos custos do projeto. Esta curvaem razão da natureza geral de projetos, que possuem um comportamento típico demenor intensidade de consumo de recursos no seu início, maior consumo nas fasesintermediárias e declínio de consumo ao seu final, assume o formato de “S”, sendo,portanto denominada de curva “S” do projeto.

Curva “S” do Projeto – Curva de distribuição dos custos acumulados do projeto

Curva “S” do Projeto – Representa a correlação direta entre as atividades e os custos do projeto

Estrutura hierárquica dos custos do projeto

Após a correta alocação será obtido o montante geral orçamentário para o projeto aoqual deverão ser somados os valores relativos às reservas de contingência do


60Atividade 10

30Atividade 570Atividade 630Atividade 760Atividade 840Atividade 9

1070

10040

Custo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 24 25 26 27

Atividade 4Atividade 3Atividade 2Atividade 1

36232221PROJETO 1

60Atividade 10

30Atividade 570Atividade 630Atividade 760Atividade 840Atividade 9

1070

10040

Custo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 24 25 26 27

Atividade 4Atividade 3Atividade 2Atividade 1

36232221PROJETO 1

50

200

150

0

400

350

300

250

100

450

500

550

Custo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 24 25 26 27 36232221

50

200

150

0

400

350

300

250

100

450

500

550

Custo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 24 25 26 27 36232221

4- Projeto

2- Pacotes de Trabalho

3- Contas de Controle

200200200

100100100

505050505050

2525252525252525252525251- Atividades

100100100

505050505050

252525252525252525252525

5- Reservas de Contingência (Trat. conhecidos) 202020

6- Base de Referência de Custos (Cost Baseline) 220220220

7- Reserva de Gerenciamento (Trat. Desconhecidos) 606060

8- Orçamento total do Projeto 280280280

projeto, ou seja, os valores dos orçamentos das ações de respostas aos riscosidentificados e classificados como merecedores, dada à sua importância para osobjetivos do projeto, de uma resposta ativa. Este somatório representará a base dereferência de custos do projeto. Significa dizer que se o valor reservado ao plano decontingência for gasto nas ações do plano não haverá estouro de orçamento, ou sejaeste valor faz parte do plano de gerenciamento do projeto. Vide modelo abaixo:

O item 3 diz respeito a Contas de Controle que devem corresponder às macroentregas do ciclo de vida do projeto e serão as correspondências que o plano decontas da contabilidade da organização e o projeto poderão fazer sua conciliação.

PLANEJAMENTO DA QUALIDADE DO PROJETO

A elaboração do Plano de Gerenciamento do Projeto prossegue e, neste ponto doprocesso, já devem ter sido definidos o escopo, o tempo e o custo do projeto. Ouseja, as três principais variáveis determinantes do projeto. Outros elementos doplano, porém, ainda não terão sido tratados o que significa que as definiçõesanteriores poderão e deverão ser reformuladas, uma vez que o processo deelaboração do plano é de fato interativo. A seqüência segue uma ordem lógica, masque deve comportar idas e vindas.

Antes de tudo, é importante lembrar que qualidade só pode ser entendida sereferenciada a um padrão. Isto é, não existe qualidade absoluta, mas sim qualidaderequerida por alguém (sujeito) que espera atendimento dos seus requisitos dentrode certas margens de tolerância. Estas margens de tolerância são os limites,fronteiras do padrão da qualidade requerida.

Plano de Gerenciamento da Qualidade

Assim sendo, o plano de gerenciamento da qualidade do projeto deve levar emconsideração este cenário. A fim de encontrar a melhor estratégia para atender àsexpectativas do cliente deve empreender todos os esforços possíveis para descobrirquais são estas expectativas, explicitá-las, para, em seguida, encontrar os meios de


4- Projeto

2- Pacotes de Trabalho

3- Contas de Controle

200200200

100100100

505050505050

2525252525252525252525251- Atividades

100100100

505050505050

252525252525252525252525

5- Reservas de Contingência (Trat. conhecidos) 202020

6- Base de Referência de Custos (Cost Baseline) 220220220

7- Reserva de Gerenciamento (Trat. Desconhecidos) 606060

8- Orçamento total do Projeto 280280280

atendê-las. O gerenciamento da qualidade do projeto, segundo o Guia PMBOK®, édefinido como sendo: os processos que cuidam das atividades da organizaçãoexecutora que determinam as responsabilidades, os objetivos e as políticas dequalidade para que o projeto satisfaça as necessidades para as quais foi criado.

O plano de gerenciamento da qualidade definirá padrões e processos que garantama qualidade do projeto. Determinará como serão tratados a garantia dos processos eo controle da qualidade do produto do projeto.

Deve definir, também, as responsabilidades específicas dos membros da equipe paraconduzir as ações do gerenciamento da qualidade. Quem liderará cada processo,quem fará inspeções, quem aprovará, autorizará etc.

Análise de Custo x Benefício

O conceito de qualidade enunciado pela ISO 9000:2000 é de que qualidade é: ograu no qual um conjunto de características inerentes satisfaz aos requisitos.

Portanto, não há qualidade absoluta ou total. Em meados dos anos 80, o termoQualidade Total foi interpretado equivocadamente como sendo qualidade absoluta,quando deveria significar que a totalidade da organização deve buscar a qualidadecomo objetivo e não apenas aqueles que tinham como função zelar pela qualidade.

Assim sendo, é necessário, para o planejamento da qualidade do projeto, identificarqual a melhor relação entre as necessidades do cliente e os custos envolvidos paraatender a estas necessidades. Haverá um ponto de equilíbrio indicando que a partirde um determinado ponto, não haverá valor percebido pelo cliente.

As entregas que excederem ao limite do contratado serão consideradasformalmente, além do requisitado, do esperado pelo cliente. Não foi pedido pelocliente. O jargão da comunidade de gerenciamento de projetos denomina estaprática de “gold plating”. Em uma tradução livre, seria a gíria: dourar a pílula.


Nível de Atendimento aos

requerimentos

Gold P latingNão Requsitado

Não EsperadoNão Contratado

Custo da Qualidade

Orçamento do Projeto

Requisitos do Projeto(CLIENTE)

Valor Esperado (contratado)

Significa que não faz parte do escopo muito menos dos requisitos acordadosformalmente. Não é uma boa prática de gerenciamento de projetos entregar além dorequisitado, pois a premissa é de que seja elaborado um plano que atenda aosrequisitos e que este plano seja executado. Qualquer diferença a mais ou a menosque não seja fruto da incerteza inerente a qualquer projeto, ou seja, movimentosintencionais de modificações do plano será uma quebra do acordo feito com ocliente.

Determinação dos Padrões da Qualidade do Projeto

A qualidade precisa de uma referência de avaliação. Esta referência é o padrão daqualidade que deve ser estabelecido pelo cliente do projeto. É função do gestor doprojeto identificar este padrão e persegui-lo. Cada padrão, porém, possui umaprobabilidade de ser atingido que dependerá das características de processamento egeração do produto. Esta probabilidade, ou possibilidade, de cumprimento do padrãoque deve ser reconhecida e aceita pelo cliente será tratada como TOLERÂNCIA.

Portanto, é necessário para estabelecer os acordos relacionados à qualidade quesejam determinantes do padrão, ou seja a tolerância do cliente à variabilidade dosresultados das entregas. Na figura abaixo temos a descrição de um padrão, outolerância, para a fabricação de uma peça mecânica. Esta é, certamente, umasituação de grau de facilidade alto para a determinação destas variáveis, pois quantomais abstrato for o objeto da entrega mais difícil é a determinação dos padrões etolerâncias envolvidos. É o caso por exemplo de projetos que geram soluções paraum problema, ou melhorias. O que não exime o gestor do projeto de fazê-lo.

Procedimentos, métricas e indicadores da qualidade

Uma vez que tenham definidos os padrões de referência do projeto será precisodeterminar os procedimentos necessários para que eles sejam atingidos, assim como


D D

∆D+∆D-

Tolerância = PADRÃO DA QUALIDADE

as unidades de medida, métricas, para cada parâmetro da qualidade e os indicadoresque permitirão monitorar o quanto eles estarão sendo cumpridos e tomar as medidaspreventivas e corretivas necessárias.

A medida da qualidade do projeto será a medida do cumprimento dos parâmetrosestabelecidos nas variáveis de escopo, tempo de custo do projeto. Cadaespecificação do projeto passa a ser uma referência a ser seguida e medida daqualidade do projeto. A determinação de que uma parede em um projeto deconstrução de uma casa será pintada com uma tinta específica e com umadeterminada densidade são itens de escopo, mas a medida do cumprimento destasespecificações, isto é, a garantia de que a tinta e a densidade especificadas sejamcumpridas é assunto do gerenciamento da qualidade.

PAPÉIS E RESPONSABILIDADES DAS PESSOAS NO PROJETO

Atividades e ramos da economia, conforme sua natureza, são intensivos em capital,caso das instituições financeiras, intensivos em tecnologia, caso das empresas detelecomunicações, intensivas em equipamentos caso de empresas que dependamfortemente de máquinas, etc. Projetos são intensivos em pessoas. Significa que osucesso de um projeto depende diretamente do desempenho das pessoas que orealizam.

O planejamento dos recursos humanos do projeto tem como objetivo criar o Planode Gerenciamento de Pessoal que estabelece a forma como as pessoas do projetoserão incorporadas, organizadas, distribuídas pelas partes do projeto, como serãocapacitadas e coordenadas para alcançarem os objetivos do projeto.

Contratação ou Mobilização da Equipe do Projeto

De acordo com os requisitos de desempenho do projeto o plano indicará critérios eprocessos necessários para a busca e a escolha dos profissionais que integrarão aequipe do projeto.

O tipo de vínculo que o profissional terá com o projeto, será determinado pela suaorigem. Se for pessoal da própria organização será uma mobilização, mas se forexterno à organização executora do projeto será uma contratação.

Para tal é necessário que o gestor do projeto identifique as competências que aequipe deve ter a fim de realizar as atividades do projeto necessárias ao seusucesso.

A primeira dificuldade na identificação de competências reside no fato de quecompetência é diferente de qualificação, isto é, competência segundo FelipePerrenoud (1999), é Capacidade de agir eficazmente em um determinado tipo desituação, apoiando-se em conhecimentos, mas sem limitar-se a eles. O currículo doprofissional apresenta conhecimentos adquiridos em formação acadêmica eexperiências anteriores, mas não consegue garantir que ele seja competente para aatividade requerida.


O conhecimento é um dos componentes da competência, assim como as habilidadesque são desenvolvidas na prática de atividades que requeiram a aplicação detécnicas conhecidas.

De forma simplificada competências podem ser definidas como o conjunto deconhecimentos, habilidades e atitudes de um profissional. Esquematicamente pode-se dizer que conhecimentos são o “saber”, as habilidades o “saber fazer”, e asatitudes o “querer fazer”. Este último elemento refere-se ao posicionamento que oprofissional frente aos desafios das atividades. Nele estão contidos ocomprometimento, o envolvimento e a motivação para agir no momento adequadomobilizando conhecimentos e habilidades.

A identificação de competências necessárias à execução do projeto assim como dospotenciais membros da equipe de um projeto não é da tarefa trivial. Exige, portanto,que o gestor do projeto invista esforço considerável já que uma equipe competente éfator crítico de sucesso para o projeto.

As competências necessárias ao projeto precisam ser traduzidas de forma maisexplicita e prática possível através da análise da natureza de cada tarefa. Porexemplo, será necessário elaborar um cronograma composto de: um gráfico deGantt e de um Diagrama de Rede inseridos em um calendário, utilizando o software“X”. O profissional candidato à posição precisa ser “capaz” de executar esta atividadeutilizando a referida ferramenta.

Após a identificação das competências exigidas para execução de cada tarefa ogestor deve especificar o conjunto de competências que serão necessárias para cadaprofissional do projeto, determinando, assim um perfil desejado.

Este perfil profissional desejado será o instrumento que servirá de guia para a buscana própria organização, para uma mobilização, ou no mercado, para umacontratação.

Uma vez recrutados os candidatos, será necessária a seleção. Para esta etapa,Seguindo uma orientação focada em competências, o gestor do projeto pode solicitarque o candidato se submeta a um teste ou que obtenha informações de fontesabalizadas que atestem seu desempenho em tarefas equivalentes às que serãonecessárias, ou seja, que obtenha uma comprovação das competências e não hajaapenas uma demonstração de currículos.

Organograma e Matriz de Responsabilidades do Projeto

Como resultado estruturado do processo de especificação das pessoas em suasrespectivas posições, atribuições e relações hierárquicas é um organograma e umamatriz de atividades por pessoas alocadas no projeto, conhecida como Matriz deResponsabilidades.


Organograma do Projeto

No organograma devem estar demonstradas as relações de subordinação funcionalno projeto. Devem estabelecer o papel de todas as pessoas que participarãoativamente no projeto, inclusive pessoas externas à organização executora. Paradeixar claro que este organograma é do projeto e não reflete necessariamente ahierarquia da empresa, costuma-se denominá-lo de organograma virtual do projeto.

A matriz de responsabilidades tem uma abordagem mais operacional, pois asreferências são as atividades do projeto e o papel que cada membro da equipe doprojeto desempenho em relação a elas.

Alguns princípios devem nortear a elaboração da matriz, entre eles o da unicidade decomando. Isto é, cada atividade deve ter apenas um responsável. Mesmo que hajadois membros da equipe que “dividam” a responsabilidade pela execução daatividade, é recomendável que o gerente do projeto nomeie um deles como oresponsável.

Matriz de Responsabilidades do Projeto



Resp. Fase AResp. Fase AResp. Fase A Resp. Fase BResp. Fase BResp. Fase B Resp. ContratosResp. ContratosResp. Contratos

Membro 3Membro 3Membro 3Membro 1Membro 1Membro 1 Membro 2Membro 2Membro 2 Resp. Ent. nRespResp . . EntEnt. n. n

Sponsor do ProjetoSponsorSponsor do Projetodo Projeto

ConsultorConsultorConsultor

Apoio AdmApoio Apoio AdmAdm

- Resp. Atividade A- Resp. Atividade B- Resp. Atividade n

PLANEJAMENTO DAS COMUNICAÇÕES DO PROJETO

O recente estudo de benchmarking realizado pelo PMI aponta a comunicação é umproblema importante em projetos. Um dos principais fatores de fracassos emprojetos. Tratar as comunicações de forma planejada, portanto, é um caminho paradiminuir a probabilidade de dificuldades no gerenciamento do projeto.

Projeto é algo que precisa ser criado para resolver um problema ou aproveitar umaoportunidade. Estas necessidades ou requisitos precisam ser transmitidos,comunicados, a quem será encarregado de realizá-lo. Sendo assim, a comunicação éelemento chave neste relacionamento que deverá identificar os objetivos e definir oescopo do projeto. Portanto, se analisadas em mais profundidade as causas deobjetivos, escopo e outras varáveis de projeto mal definidos, pode-se chegar comfreqüência ao componente comunicação como fator preponderante.

Muitos dos problemas ligados à comunicação são identificados pela compreensão doselementos presentes no processo, conforme demonstra a figura a seguir.

Modelo Básico de Comunicação (fonte: Guia PMBOK®, 2008)

A partir deste modelo é fundamental deixar claro que a responsabilidade pelaqualidade, eficácia, da comunicação é do emissor. Ou seja, de quem transmite amensagem. Sendo assim, ele deve cuidar para que eventuais desvios, diferenças,ruídos, barreiras ou lacunas na comunicação não ocorram. E se ocorrerem dar omelhor tratamento. Jogar a responsabilidade pela não compreensão da mensagempara o receptor, não é prática recomendável.

Ponto sensível em ambientes de projeto, a escolha do código utilizado pelo emissorpara encapsular a mensagem é fator decisivo na eficácia da comunicação. O códigoescolhido pelo emissor deve ser de domínio do receptor. Como guardião da eficáciada comunicação, o emissor, antes de mais nada, deve certificar-se de que o receptordomina o código que será usado na transmissão da mensagem.

Jargões técnicos de domínio de ambientes tecnológicos restritos, com siglas eabreviaturas específicas, muito comuns em projetos de áreas intensivas emtecnologia, são pontos de atenção para códigos desconhecidos pelo receptor. Apresunção de que o jargão “deve” ser dominado, por quem é do meio, é perigosa.Projetos são atividades de relacionamentos internos e externos à organizaçãoexecutora. Hoje, dado o grau de especialização tecnológico e a velocidade das


mudanças, profissionais de uma mesma área podem ter sérias dificuldades decompreender os termos usados na comunicação de um projeto.

O problema se agrava se levarmos em consideração a interação que os executoresde projetos precisam ter com membros da alta direção empresarial. Um diretorrecém contratado pela organização pode se sentir constrangido em demonstrardesconhecimento de um jargão e por isso não externar que não compreendeuadequadamente uma informação valiosa para sua tomada de decisão. O mesmopode ocorrer com um fornecedor ou outro stakeholder do projeto.

Assumindo o papel de responsável pela eficácia da comunicação no projeto oemissor deve, inclusive procurar garantir que o retorno (feedback) dado peloreceptor seja ativo. Feedback ativo, não é o mesmo que o receptor responder“entendi”, porque pode ter sido “entendido” algo diferente do conteúdo que oemissor desejava comunicar. Feedback ativo, portanto, requer a confirmação dosignificado da mensagem nas palavras do receptor, afim de que seja possível aoemissor verificar se houve divergência entre o que foi entendido e o que precisavaser comunicado.

A título de exemplo de uma estratégia para provocar feedback ativo de stakeholdersimportantes tais como o cliente ou o sponsor, o gestor do projeto, durante umaentrevista de levantamento de requisitos ou de definição de escopo, pode testar oentendimento, induzir ao feedback ativo, lendo em voz alta o que foi “acertado” eanotado e solicitando ao interlocutor que identifique alguma divergência.

Portanto, o planejamento das comunicações do projeto deverá determinar:

O que deve ser comunicado.

Que documentos e informações do projeto devem ser transmitidas. O Termo deAbertura, a declaração do escopo, o plano de gerenciamento do projeto, variaçõesde prazo, de custo, novos riscos identificados, mudanças, etc.

Quem deve enviar e receber a comunicação.

Os stakeholders (partes interessadas) do projeto devem ser o alvo de um plano decomunicação de um projeto. A boa técnica da comunicação recomenda, para maioreficácia, a seletividade. Isto é, a comunicação deve ser direcionada ao receptorespecífico. Se a comunicação não for seletiva pode causar o efeito que os e-mailsspam (comunicação em massa). A distribuição indiscriminada, não seletiva,desvaloriza tanto a mensagem quanto o emissor. Outras mensagens do emissor nãoseletivo tendem a ser desconsideradas. Este processo, portanto, depende de umbom mapeamento, identificação precisa das necessidades e interesses, de cadastakeholder do projeto.

Quando deve ser feita a comunicação.

A periodicidade ou momentos específicos do projeto que deve ser realizada. Uma vezque o princípio do planejamento prevaleça e o plano de gerenciamento do projetodetermine um ciclo de controle, o calendário de reuniões de progresso programadasjá deve ser divulgado a quem delas irá participar.


Como será feita a comunicação.

Que meios ou canais serão utilizados a fim de que haja maior eficácia. Aqui também,o princípio da seletividade se faz necessário. Cada informação a ser comunicada aum stakeholder específico deve ser entregue pelos meios, canais, ou veículosespecíficos. Determinada informação para alguns stakeholders pode ser suficiente apublicação em um jornal de grande circulação ou em um diário oficial regional. Paraoutro stakeholder pode ser mais indicado uma apresentação presencial em suaprópria sala. Cabe ao gestor do projeto, apoiado pelo sponsor, identificar estasespecificidades que são fatores críticos de sucesso para a comunicação do projeto.

Matriz de Comunicações

GERENCIAMENTO DOS RISCOS DO PROJETO

Risco de projeto, segundo o Guia PMBOK®, é um evento ou condição incerta que, seocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo doprojeto, como tempo, custo, escopo ou qualidade.

Projetos são atividades probabilísticas e não determinísticas, isto é, seus resultadospossuem considerável grau de incerteza. Projetos são realizados para a criação dealgo que não existe ou para a aplicação de uma solução a um problema presente.Em ambos os casos não é possível garantir com absoluta certeza que acontecerão.São eventos futuros sobre os quais é possível, no máximo, fazer estimativas eprevisões com taxas de probabilidades associadas.

Neste cenário o gerenciamento dos riscos constitui-se no conjunto de processos queaumentem a possibilidade de sucesso do projeto, aumentando a probabilidade e oimpacto dos riscos positivos, e diminuir a probabilidade e o impacto dos riscosnegativos do projeto. Aumentar a dimensão das oportunidades, ou fatores favoráveis


Na identificação de problemas

Na identificação de novos riscos

Na abertura do projeto e na conclusão do plano

No término do planejamento

Na geração do documento

Na assinatura do contrato

Na conlusão do planejamento

Na abertura do projeto

Quando?

(...)

Equipe

Equipe

Sponsor, cliente e equipe

Gerentes Funcionais

Sponsor, Cliente, Equipe

Sponsor e Cliente

Sponsor e Equipe

Sponsor, Cliente, Equipe, Gerentes Funcionais,...

Stakeholder

Cópia em papel entregue em mãos

WBS

Memorando internoCronograma de Utilização de recursos


Riscos Identificados

E-mail

E-mailProblemas identificados



Contrato

(...)(...)


Plano do Projeto

Termo de Abertura

Como?Documento

Na identificação de problemas

Na identificação de novos riscos

Na abertura do projeto e na conclusão do plano

No término do planejamento

Na geração do documento

Na assinatura do contrato

Na conlusão do planejamento

Na abertura do projeto

Quando?

(...)

Equipe

Equipe

Sponsor, cliente e equipe

Gerentes Funcionais

Sponsor, Cliente, Equipe

Sponsor e Cliente

Sponsor e Equipe

Sponsor, Cliente, Equipe, Gerentes Funcionais,...

Stakeholder


WBS

Memorando internoCronograma de Utilização de recursos


Riscos Identificados

E-mail

E-mailProblemas identificados



Contrato

(...)(...)


Plano do Projeto

Termo de Abertura

Como?Documento

ao projeto alcançar seus objetivos e diminuir as ameaças, ou fatores desfavoráveisao alcance dos objetivos do projeto.

Um risco origina-se de uma fonte, o evento materializa-se por uma causa que geraconseqüências, impactos nos objetivos do projeto.

Configuração do Risco em projetos

O evento será potencial, portanto, risco, se possuir uma probabilidade de ocorrência.Se a probabilidade for nula não será considerado como hipótese, ou se for de 100%será um fato que pode configurar-se como uma certeza, restrição ou irrelevante parao projeto. Havendo probabilidade de ocorrência e a presunção de que o eventovenha a causar impactos, efeitos nos objetivos do projeto, será considerado risco.Portanto, um risco deve ser avaliado sempre considerando-se as duas variáveis: aprobabilidade e o impacto.

Plano de Gerenciamento dos Riscos

O planejamento do gerenciamento dos riscos produzirá um plano que determinarácomo serão realizados os demais processos do gerenciamento dos riscos, que são:

� Identificar os riscos� Realizar a análise qualitativa de riscos� Realizar a análise quantitativa de riscos� Planejar respostas aos riscos� Monitorar e controlar os riscos

Determinará, também, a abordagem, estratégia, que será dada aos riscos de acordocom suas características: se pró-ativa, agindo antecipadamente, ou reativa, agindose e quando, o evento incerto ocorrer.

Imediatamente após a elaboração do plano de gerenciamento dos riscos, ainda noprocesso de planejamento, será necessário realizar os processos do gerenciamentodos riscos, exceto o de monitoramento e controle dos riscos que será realizado aolongo do processo de execução do plano de gerenciamento do projeto.

Identificar os riscos

Determinação, através de uma abordagem organizada, dos riscos positivos enegativos que podem afetar os objetivos do projeto. Este processo envolve, também,o levantamento e documentação de informações que caracterizem os eventos aoponto de permitir ações específicas sobre eles.


Para um melhor resultado neste processo, visto que envolve a identificação dehipóteses de eventos potenciais, é recomendável utilizar métodos de trabalho emgrupo que estimulem a criatividade, tais como brainstorming, delphi, modelagensmentais e de associação de idéias, diagramas de causa e efeito (Ishikawa), análisede Forças, Oportunidades, Fraquezas e Ameaças (SWOT – Strengths, Weaknesses,Opportunities, and Threats) etc.

Modelos de categorização elaborados no planejamento dos riscos, tais comoestruturas hierárquicas em forma de organogramas, neste caso, denominadas deestrutura analítica de riscos (EAR), podem ajudar na indução de identificação deriscos.

O principal resultado do processo de identificação de riscos é um documentodenominado Registro de Riscos (Risk Register) que contém a lista de riscos, comsuas respectivas causas, efeitos e potenciais respostas.

Dicas para documentar bem os riscos do projeto:

1. Descrever o risco de maneira estruturada, utilizando uma descrição em 3partes:

“Devido a <uma ou mais causas>, <risco> poderá ocorrer, o que levaria a <um oumais efeitos>.”

2. Quanto mais específica for a descrição do evento de risco, mais facilmenteconseguiremos planejar uma resposta e monitorá-lo posteriormente.

� Descrição genérica de um risco:

Devido à situação atual do cliente, poderão ocorrer mudanças de escopo, o quelevaria a um atraso do projeto.

� Descrição específica de um risco:

Devido à quantidade de dúvidas do cliente em relação às possibilidades de utilizaçãodo ambiente a ser construído, poderá ocorrer um aumento na área de construçãoprevista originalmente para o auditório, o que levaria a um atraso na fase dedesenho do projeto.

3. Quando possível, identifique alertas (triggers) que indiquem que o risco estáprestes a ocorrer. Eles o ajudarão futuramente no monitoramento e controledaquele risco.

� Descrição do Risco:

Devido à falta de experiência do pessoal com o equipamento XYZ, um desempenhoruim na execução dos testes deste equipamento poderá ocorrer, o que levaria a umaumento da duração prevista dos testes, que é de 20 dias.

� Alerta:

Progresso dos testes inferior a 20% após 4 dias de teste.


Exemplo de EAR (Estrutura Analítica de Riscos)

Realizar a análise qualitativa de riscos

Priorização dos riscos identificados para análise ou ação adicional subseqüenteatravés de avaliação e combinação de sua probabilidade de ocorrência e impacto.

Classificação para priorização dos riscos em função da probabilidade e do impacto


Para o processo de análise qualitativa de riscos podem ser utilizadas escalasrelacionadas às duas principais variáveis do risco: a probabilidade de ocorrência e oimpacto sobre os objetivos. A ferramenta denominada Matriz de Probabilidade xImpacto permite uma melhor visualização da classificação dos riscos do projeto.

Os graus ou as faixas das escalas de probabilidade e de impacto devem serdeterminados de acordo com o perfil de tolerância ou aversão a riscos daorganização executora do projeto.

Exemplo de Escala de PROBABILIDADES

Exemplo de Escala de IMPACTOS


Exemplo de MATRIZ DE PROBABILIDADE X IMPACTOS (P x I)

Na matriz os eventos são posicionados de acordo com as estimativas deprobabilidade e impacto a fim de que sejam classificados segundo o produto dasduas variáveis. Esta classificação servirá de orientação à estratégia de resposta queserá elaborada no processo de Planejamento de Resposta aos Riscos. Os riscos comclassificação ALTA, por exemplo, alta probabilidade e alto impacto podem serconsiderados de prioridade máxima e exijam tratamento agressivo. Já para os declassificação BAIXA, a estratégia pode ser passiva, ou seja, apenas monitorá-los apartir de uma lista de observação (Watchlist).

Realizar a análise quantitativa de riscos

Análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto.Tem por objetivo analisar numericamente os riscos mais significantes estabelecidosdurante a análise qualitativa, e a interação entre eles, para estimar a faixa depossíveis resultados para o projeto como um todo.

Este processo utiliza técnicas como a simulação de Monte Carlo e a análise da Árvorede Decisão para:

� Quantificar os possíveis resultados do projeto e suas probabilidades

� Avaliar a probabilidade de atingir objetivos específicos do projeto

� Identificar os riscos que exigem mais atenção quantificando sua contribuiçãorelativa para o risco total do projeto.

� Identificar metas realistas e alcançáveis de custo, cronograma ou escopo,quando fornecidos os riscos do projeto

� Determinar a melhor decisão de gerenciamento de projetos

Planejar respostas aos riscos

Desenvolvimento de opções e ações para aumentar as oportunidades e reduzir asameaças aos objetivos do projeto.

Formas de responder a riscos NEGATIVOS de um projeto:

� Eliminar o risco, planejando uma forma de excluí-lo completamente.


� Mitigar o risco, buscando uma forma de reduzir a probabilidade de suaocorrência 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 positivofazendo com que a oportunidade efetivamente aconteça.

� Melhorar o risco, modificando o “tamanho” da oportunidadeaumentando a probabilidade e/ou impacto (valor esperado) do riscopositivo.

� Compartilhar o risco, atribuindo a sua propriedade a terceiros quepossam capturar melhor a oportunidade do risco acontecer em benefíciodo projeto.

Formas de responder a riscos POSITIVOS e NEGATIVOS de um projeto:

� Aceitar Ativamente, buscando se preparar com reservas de tempo oude dinheiro caso o risco venha a ocorrer.

� Aceitar Passivamente, simplesmente não fazendo nada e torcendopara que o risco não venha a ocorrer.

� Respostas de Contingência, elaborando planos de contingência que sóserão executados se algum alerta, sintoma ou trigger (gatilho) ocorrer, ouse o próprio risco ocorrer.

Estratégias de Resposta aos Riscos


Dicas para documentar bem um plano de respostas a riscos:

1. Planos de resposta a riscos devem ser mais do que simples “desejos” de queas coisas dêem certo.

� Plano de ação ou apenas um desejo?:

- Garantir que o equipamento seja entregue no prazo.

� Plano de ação objetivo:

- Negociar com o fornecedor visitas quinzenais à fábrica paraverificação do progresso da fabricação do equipamento.

- Disponibilizar linha de comunicação direta (“hot-line”) com a fábricapara agilizar comunicação de eventuais problemas durante afabricação.

2. Evite que os planos de resposta descrevam apenas o que já é parte dasatividades cotidianas do trabalho.

� Descrição do Risco:

- Quebra da alavanca código BHYZPT durante instalação do quadroelétrico nº 21A.

- Plano de ação ou trabalho do dia-a-dia?:

- Seguir as especificações de instalação do quadro elétrico.

O que poderia ser feito de diferente, em relação ao que já é costume, paramitigar ou prevenir a ocorrência do risco?

3. Cuidado com ações de resposta que exijam acompanhamento durante toda aextensão do projeto:

� Em lugar de:

- Acompanhar as atividades do fornecedor através de gestãointegrada.

� Prefira:

- Elaborar procedimento para acompanhamento das atividades dofornecedor através de gestão integrada.

Monitorar e controlar os riscos

Acompanhamento dos riscos identificados, monitoramento dos riscos residuais,identificação dos novos riscos, execução de planos de respostas a riscos e avaliaçãoda sua eficácia durante todo o ciclo de vida do projeto.



PROCESSOS DE AQUISIÇÕES

O projeto precisa de recursos para conseguir realizar seus objetivos. Dessa forma, osprocessos de aquisição determinarão como será a aquisição de bens e serviços defora da organização executora do projeto.

� Planejar Aquisições� Realizar Aquisições� Administrar Aquisições� Encerrar Aquisições

Decisão de Comprar ou Fazer (Make or Buy)

Como parte do processo de planejamento das aquisições, é necessário analisar asalternativas para cada recurso necessário ao projeto entre adquirir de fora daorganização ou produzir internamente. Considerar prós e contras, preferencialmenteutilizando métodos de tomada de decisão.

Indicações de FAZER

� Facilidade de integração com operações de rotina� Utilização de capacidade ociosa� Falta de fornecedores confiáveis� Necessidade de controle direto

Indicações de COMPRAR

� Fornecimento especializado� Pequenos volumes� Capacidade limitada� Ampliar leque de fornecedores� Transferência de risco ao fornecedor

Seleção do Tipo de Contrato

1- Contratos com Preço Fixo e com Pagamento Integral2- Contratos com Reembolso de Despesas3- Contratos de Mão-de-Obra e Material

Especificação do Serviço (SOW – Statement of Work)

A fim de que as necessidades específicas do projeto sejam atendidas é importanteidentificar todas as características de cada item a ser adquirido. Neste momento doprojeto o gestor do projeto estará atuando como um cliente. Quanto maisespecificações forem passadas aos fornecedores maiores serão as chances de que asaquisições sejam adequadas.

O nível de definição do escopo de cada parte do projeto determinará a possibilidadede especificação da aquisição e conseqüentemente do modelo de contrato quepoderá ser firmado. Se o escopo não estiver bem definido o contrato dificilmentepoderá ser por preço fixo, o que acarreta mais risco para o comprador, neste caso ogestor do projeto.


Critérios e Métodos de Avaliação de Fornecedores

A melhor prática de aquisições recomenda que se utilizem métodos de tomada dedecisão que diminuam a subjetividade da escolha de fornecedores. Esta prática podediminuir, também, a influência do fator preço sobre a escolha do fornecedor, o queem muitos casos não é sinônimo de qualidade nem de melhor solução técnica.

APROVAÇÃO DO PLANO DE GERENCIAMENTO DO PROJETO

Todo este trabalho que até agora analisamos de desenvolvimento do plano degerenciamento do projeto precisou ser AUTORIZADO. Autorização esta necessáriapara que o gestor do projeto e, dependendo da situação, uma equipe degerenciamento do projeto, pudessem trabalhar na configuração do plano degerenciamento do projeto.

O trabalho de desenvolvimento foi AUTORIZADO, entretanto o plano desenvolvidoprecisa ser APROVADO.

A instância aprovadora do plano de gerenciamento do projeto dependerá de cadaprojeto. Tipicamente, o Patrocinador (Sponsor) do projeto teria esta prerrogativa,mas pode ser aprovado por uma diretoria ou constituído um comitê especialmentepara esse fim.

Cabe lembrar que a aprovação do plano pressupõe a concordância com todos osparâmetros do projeto incluindo, prazo e orçamento.

Conceitualmente, a partir de sua aprovação, o plano de gerenciamento do projetopassa a representar a referência para a execução do projeto, a linha de base doprojeto (Project baseline).

A integridade desta referência, linha de base, passa a ser responsabilidade do gestordo projeto, isto é, uma vez aprovado o plano, criada a linha de base, toda mudançaem qualquer dos parâmetros do projeto deve ser tratada como modificação doplano. Significa que deverá ser conduzido um processo de aprovação das mudançaspelas instâncias autorizadas para tal.

REUNIÃO DE PARTIDA DA EXECUÇÃO DO PROJETO – KICKOFF MEETING

A boa prática recomenda que o início da execução do plano de gerenciamento doprojeto seja marcado, isto é, COMUNICADO aos principais stakeholders do projeto eà organização executora como um todo.

Este “pontapé inicial” tem a finalidade de esclarecer dúvidas relacionadas ao planode gerenciamento do projeto, a estratégias utilizadas, sistemas de controle adotados,pontos críticos, objetivos específicos, metas, enfim, é o momento e a oportunidadede confirmar a participação e o comprometimento dos principais envolvidos com osobjetivos do projeto e angariar apoio de áreas fornecedoras de recursos.


Execução, Monitoramento e Controle do Projeto

Uma vez elaborado o plano de gerenciamento do projeto, énecessário realizá-lo, cumpri-lo. Esta afirmativa está longe de ser uma obviedade,porque é comum que no calor dos acontecimentos o plano seja esquecido e oprocesso de execução passe a ser uma sucessão de improvisos.

O processo de execução consiste na integração das pessoas e recursos materiaispara realizar o plano de gerenciamento do projeto. A concentração dos esforçosnecessários para atingir os objetivos estabelecidos para o projeto.

Os processos de monitoramento e controle ocorrem desde o primeiro momento doprojeto, porém, quando o plano estiver sendo executado, as exigências demonitorar, isto é, verificar como está sendo executado o plano, e quando necessário,tomar medidas corretivas, ou seja, controlar, tornam-se mais prementes.

A execução do projeto envolve essencialmente:

� Executar, seguir o PLANO DE GERENCIAMENTO DO PROJETO

� Realizar o ESCOPO do projeto

� Entregar os PRODUTOS INTERMEDIÁRIOS

� Gerenciar os RECURSOS

� Gerenciar MUDANÇAS

� Corrigir DESVIOS

� Atualizar o PLANO DE GERENCIAMENTO DO PROJETO

Equipe de execução do projeto

É o momento de incorporar os membros da equipe que o plano de gerenciamento depessoal determinou como necessária à realização do projeto. Mobilizar, se forpessoal interno à organização ou contratar, se forem externos.

Em ambos os casos o gestor deverá apóia áreas de suporte no recrutamento,conduzir entrevistas e avaliar as competências dos candidatos.


Faz parte das atribuições do gestor neste momento do projeto, o desenvolvimentode competências que ainda não estejam plenamente incorporadas pelos membros daequipe, seguindo estratégias e métodos de desenvolvimento profissional.

Ciclo de Controle do Projeto

A freqüência com que o projeto será, de forma programada, monitorado econtrolado pode ser decisivo para o sucesso do projeto, pois determinará o nível deesforço empreendido nestes processos.

Ciclo muito frequente

Mais uma vez coloca-se uma situação em que faz-se necessário encontrar o ponto deequilíbrio, pois uma frequência muito alta irá requerer um esforço que talvezinviabilize o trabalho de monitoramento e controle. Pode inviabilizar, por exemplo, aatualização dos documentos do projeto. Levando à situação na qual o controleexcede o objeto controlado, princípio de Henry Fayol, que em outras palavras,significa consumir mais esforço 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 ordemque não possam mais ser corrigidos, isto é, não seja mais possível às açõescorretivas fazerem o projeto voltar à sua linha de base. Desvios impossíveis deserem corrigidos levam à necessidade de mudança para que o projeto continue comuma linha de base factível. Uma linha de base que sirva, efetivamente de referênciapara a execução do projeto.


O monitoramento e controle do projeto

A cada ponto do ciclo de controle de acordo com o previsto no plano degerenciamento do projeto devem ser realizadas medições para a coleta de dadospara a determinação do status do projeto. A data em que as medições são realizadasé denominada DATA DATE (Data dos Dados). A sequência de gráficos, a seguir,

As atividades em vermelho pertencem ao caminho crítico. No primeiro ponto do Ciclode Controle (C1), na DATA DATE, os dados de execução do projeto deverão ser


Dados coletados: Atividade A concluída e sem variação de custo

Os dados indicam, portanto que no primeiro Ciclo (C1) o projeto está de acordo como planejado. Cronograma e Orçamentos cumpridos. No segundo ponto do Ciclo (C2)

Impactos no PRAZO1- Atraso na Atividade B (Caminho Crítico) gera atraso no projeto2- Atraso na Atividade C não gera atraso por ter FOLGA de 5 diasCRONOGRAMA ATRASADO

Impactos no CUSTO1- Atividade B gastou mais 20% do orçado para fazer apenas 80% de 100% planejados2- Atividade C gastou mais 30% do orçado para fazer apenas 30% de 50% planejadosORÇAMENTO ESTOURADO

Se nenhuma ação corretiva for tomada o projeto sofrerá os impactos totaisidentificados, mas é papel do gerente do projeto identificar ações que neutralizem ou


minimizem os impactos dos desvios e tragam o projeto as previsões de prazo e custooriginais, ou seja, voltar à linha de base.


GERENCIAMENTO DO VALOR AGREGADO – EARNED VALUE MANAGEMENT

O ponto de partida para medidas de gestão efetivas é uma correta avaliação dodesempenho do projeto. Uma forma estruturada de avaliar o desempenho deprojetos é a técnica do Gerenciamento do Valor Agregado, que oferece uma amplavisão dos desvios existentes, tanto de custo como de prazo, utilizando como baseinformações de custo do AVANÇO FÍSICO ou ESCOPO REALIZADO.

O Valor agregado tem foco na relação entre CUSTOS reais incorridos e o trabalhorealizado no projeto (ESCOPO) dentro de um determinado período de TEMPO. Ofoco está em comparar o quanto foi efetivamente gasto com o quanto foiefetivamente produzido (agregado – Avanço Físico – ESCOPO realizado) e não oquanto foi gasto com o quanto se esperava gastar.

Valor agregado pode ser definido como a avaliação entre o que foi obtido em relaçãoao que foi realmente gasto e ao que se planejava gastar, onde se propõe que o valora ser agregado inicialmente para uma atividade é o valor orçado para ela. Na medidaem que cada atividade é realizada, aquele valor inicialmente orçado para a atividadepassa, agora, a constituir o Valor Agregado do Projeto.

O EVM como é conhecido o método do Gerenciamento do Valor Agregado, portanto,disponibiliza um sistema de controle gerencial unificado confiável, propicia aintegração do trabalho, prazos e custos utilizando a EAP do projeto (WBS) epermite análises comparativas com projetos já concluídos.

O EVM permite ao gerente do projeto responder a perguntas como:

� O cronograma está adiantado ou atrasado?

� O orçamento está acima ou abaixo?

A título de exemplo, consideremos um projeto com duração de 7 meses e quepossua três fases. Cada uma com seu orçamento específico, e os valores, em Reais,acumulados ao fim de cada fase e do projeto. Poderíamos representar estes valoresno gráfico da Curva “S” do projeto.


Ao final do segundo mês, no primeiro ciclo de controle (C1), é efetuada a verificaçãoe constata-se que o que estava previsto foi efetivamente realizado. Sendo assim, oavanço físico foi de 100%. Podemos considerar, portanto, que o valor agregado ao

Quanto ao avanço físico o projeto está em dia, isto é, o cronograma está sendocumprido. Entretanto, ao verificarem-se os gastos reais, constatou-se que foram deR$ 1.200. Ou seja, R$ 200. acima do orçamento de R$ 1.000. para a fase.


Entretanto, ao final do quinto mês, no segundo ciclo de controle (C2), as mediçõesindicam que apenas metade do que estava planejado foi efetivamente realizado.Significa que o avanço físico foi de 50%, equivalendo a um valor agregado de

Neste ciclo, porém, os gastos reais, o custo real apurado, foi equivalente ao valoragregado, ou seja, os gastos forma proporcionais ao que foi efetivamente realizado.Sendo, então, de R$ 1.500.


Neste ponto, o projeto está atrasado, pois agregou apenas R$ 2.500. quando deveriater agregado R$ 4.000. e está, também, com o orçamento estourado, pois gastou R$2.700. para agregar apenas R$ 2.500. É comum gestores de projetos que nãoutilizam o EVM interpretarem, erradamente, o gasto real de R$ 2.700. como bomdesempenho ao compararem com os R$ 4.000. previstos. Porém a comparação deveser do gasto real com o valor agregado, ou seja, com o que foi efetivamenterealizado.

O método do Valor Agregado permite, portanto, uma avaliação da saúde do projetode maneira analítica considerando as principais variáveis do projeto: ESCOPO,TEMPO e CUSTO comparadas duas a duas, sempre tendo como ponto de partida oESCOPO completado, ou avanço físico, ou VALOR AGREGADO.

A partir da medição física do quanto foi efetivamente realizado em termos deESCOPO (Avanço Físico), esta grandeza é comparada no ponto do tempo (milestone)para avaliar o desempenho de TEMPO e comparada com os gastos reais, CUSTOreal, naquele ponto, para avaliar o desempenho de CUSTO do projeto.

Indicadores do EVM

PV – Valor Planejado (Planned Value) (COTA – Custo Orçado do Trabalho Agendado)Nomenclatura Antiga: BCWS – Budget Cost of Work ScheduledO que planejamos executar até esta data? No exemplo: Em C1= 1.000. C2= 4.000.

EV – Valor Agregado (Earned Value)(COTR – Custo Orçado do Trabalho Realizado)Nomenclatura Antiga: BCWP – Budget Cost of Work PerformedQuanto 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 PerformedQuanto efetivamente gastamos naquilo que executamos? Em C1= 1.200. C2= 2.700.

BAC – Orçado na Conclusão (Budget at Completion) Qual o valor total orçado para o projeto? No exemplo = 5.000.

CV – Variação de Custo (Cost Variance) � CV=EV – ACEm C1 = 1.000 – 1.200 = (- 200). C2 = 2.500 – 2.700 = (-200)

SV – Variação de Prazo (Schedule Variance) � SV=EV - PVEm C1 = 1.000 – 1.000 = 0 (sem variação). C2 = 2.500 – 4.000 = (- 1.500)

Variações Negativas são 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)


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 são sinal de ALERTA !!!

ETC – Estimado para Completar (Estimated to Completion) � ETC = BAC – EVValor total estimado que falta para completar o projetoQuanto falta para completar. Em C1= 5.000 – 1.000 = 4.000. C2= 5.000 – 2.500 = 2.500

EAC – Estimativa na Conclusão (Estimate at Completion) � EAC = AC + ETCValor total estimado para o projetoO quanto gastaremos no total – NOVO ORÇAMENTO

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)

Parâmetros do EVM na Curva “S” do projeto


MÉTODOS DE MEDIÇÃO DO TRABALHO (VALOR AGREGADO)

A base de todo o método do Gerenciamento do Valor Agregado (EVM) reside namedição do avanço físico, do escopo completado, trabalho efetivamente realizado.Todos os indicadores partem do valor agregado (EV) para os cálculos, portanto amaneira como será medido o valor agregado precisa seguir métodos queestabeleçam padrões confiáveis.

1- Percentual (%) completo2- Marcos Ponderados3- Fórmula Fixa4- Esforço Associado5- Nível de Esforço

Cada método deverá ser utilizado de acordo com a natureza da atividade.

1- Percentual (%) completoPode ser aplicado quando a atividade permite a medição precisa do avanço físico.Caso de atividades cujo trabalho é tangível e de dimensões físicas expressas emunidades paramétricas. Por exemplo: área, comprimento, altura, volume, etc. Após amedição física, uma regra de três permite encontrar o percentual completado dotodo. Por exemplo: foram completados 3 metros da pintura de uma parede de 10metros, portanto, o avanço físico foi de 30%. Em seguida, é necessário calcular oValor Agregado, que será o Valor dos 30% completos da pintura da parede.

2- Marcos PonderadosEste método é aplicado quando não é possível ter parâmetros de dimensões precisasque permitam medir o percentual completo. Consiste em determinar a proporção daspartes do todo (100%) que possam ser identificados, marcados, por entregas doprojeto. A ponderação, atribuição de pesos que segmentem o todo de formaproporcional, carrega certa dose de subjetividade, pois dependo do julgamento emfunção de um parâmetro indireto. No caso da construção de uma residência, oparâmetro tempo pode servir de base para a ponderação e determinar a seguintedistribuição por fases: fundações (10%), estrutura (30%) alvenaria (20%),instalações (10%) e acabamento (30%).

3- Fórmula FixaEm casos de dificuldade de medição precisa ou de atividades de curta duração, cujadiferença entre medidas não gere conseqüências significativas para a avaliação dodesempenho do projeto, pode-se utilizar valores padronizados para estabelecer ospercentuais de avanço físico tais como: 20/80 – 25/75 - 50/50 – 0/100. O primeironúmero do padrão é atribuído quando a atividade começa a ser executada, portanto,no caso do 50/50, quando houvesse a informação de que a atividade foi iniciadaseria considerada como estando 50% completa. Ao seu término ela receberia os50% restantes.

4- Esforço AssociadoEmpregado quando uma atividade tem relação direta ou com caráter de suporte emrelação a outra que é denominada “base de medida”. Caso de atividades de garantiada qualidade, de inspeção ou fiscalização. Neste caso o valor agregado da atividadeassociada será igual ao da atividade base.


5- Nível de EsforçoUtilizado para medir o avanço de trabalhos indiretos realizados no projeto,tipicamente o trabalho de gerenciamento do projeto ou de suporte ao projeto quenão pode ser isolado como contribuinte de uma parte específica da geração doproduto do projeto. Por convenção adota-se que o Valor Agregado (EV) destasatividades será sempre igual ao Valor Planejado (PV) para elas.

Relatório de Status

Os principais parâmetros do desempenho do projeto devem ser periodicamenteinformados aos principais stakeholders do projeto. A boa prática recomenda querelatórios de status sejam sintéticos e objetivos.

RELATÓRIO DE STATUS DO PROJETO

Projeto Data Número

Principais Entregas realizadas% completo do projeto REALIZADO% completo do projeto PLANEJADO

Valor Planejado (PV)Custo Real (AC)

Valor Agregado (EV)Orçamento do Projeto (BAC)

Data de Término previstaIndicadores Anterior Atual Sinalizador

Variação de Custo (CV)Variação de Prazo (SV)

Performance de Custo (CPI)Performance de Prazo (SPI)

Estimativa de Custo no Término (EAC)cEstimativa de Prazo no Término (EAC)t

Ações Corretivas

O relatório de status deve ser tratado sob duas perspectivas: a situação atual doprojeto (status), e as recomendações de providências a serem tomadas para que oprojeto volte à possibilidade de cumprir seus objetivos de escopo, prazo, custo,qualidade, etc.

A situação atual é uma constatação do desempenho do projeto até o ponto do ciclode controle, ou data, em que foram realizadas as medições de avanço físico e docusto real do projeto.

Dessa forma, a equipe do projeto pode traduzir o status utilizando os indicadores dedesempenho do EVM (Gerenciamento do Valor Agregado).

Um recurso prático para relatórios de status é utilizar sinalizadores coloridos do tipopainel de controle que seguem a convenção de: vermelho, amarelo e verde deacordo com a condição do indicador.


Para os indicadores cujo sinalizador esteja em amarelo ou vermelho medidas degerenciamento, ou MEDIDAS CORRETIVAS devem propostas e submetidas aaprovação.

MEDIDAS CORRETIVAS

O método do Valor Agregado permitirá uma avaliação da saúde do projeto com certograu de precisão, porém, uma vez que foram identificados desvios no plano degerenciamento do projeto será necessário tomar medidas corretivas que façam oprojeto voltar à condição de alcançar seus objetivos.

As perguntas que surgem quando são constatados os desvios são:

� Gastar mais para melhorar prazo?

� Gastar menos para melhorar custo?

� Cortar escopo?

� Propor mudanças?

A resposta só poderá ser dada pelo FATOR CRÍTICO DE SUCESSO DO PROJETO.O “DRIVER” do projeto que estabelece as prioridades para o projeto dentre suasvariáveis.

Qual a prioridade, basicamente, entre ESCOPO, TEMPO e CUSTO? Esta prioridade,como vimos deve ser identificada no início do projeto, pois ela determinará,direcionará, todas as ações do projeto.

Entretanto, se ela ainda não estiver clara será explicitada neste momento, pois osdemandantes do projeto (patrocinador – sponsor e cliente) rejeitarão quaisquersoluções para os desvios do projeto que contrariem a prioridade real do projeto.

No caso de um projeto cujo fator crítico de sucesso seja custo, e o projeto estivercom desvios de prazo de custo, por exemplo, uma proposta do gerente do projetopara redução do atraso que implique em aumento de custos será, certamente,rejeitada pela alta direção do projeto.

Portanto, o gerenciamento do projeto, considerando todo o processo desde suainiciação, planejamento, execução, 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 seucondutor (gerente do projeto) poderá contar para produzir a entrega final dentro dosparâmetros esperados por seus demandantes.


Processo de Ação Corretiva

A “BOA PRÁTICA” recomenda que ação corretiva, ao contrário da prática geral, seja,submetida à aprovação da autoridade responsável. Seja o sponsor do projeto, umadiretoria, ou um comitê constituído especialmente. É importante lembrar que oscritérios, limites e alçadas já devem ter sido estabelecidos no plano degerenciamento do escopo e impedem que as decisões do projeto fiquem“engessadas”.

Controle Integrado de Mudanças

A natureza de elaboração progressiva e de uma projeção a um ponto futuro doprojeto faz com que esteja sujeito a mudanças.

Mudanças em projetos podem originar-se por muitas razões: podem ser fruto deuma maior compreensão do produto a ser entregue em razão do avanço de partesdo projeto que permitiram uma nova visão; por uma mudança no ambiente no qualo projeto está inserido que fez com que a estratégia que deu origem ao projetotenha mudado; por riscos que materializaram-se e tornaram o plano degerenciamento do projeto inviável, enfim, antes de impedir mudanças, o gestor doprojeto deve gerenciá-las, ou seja, tomar as providências necessárias para que elassejam incorporadas devidamente ao projeto.

Assim sendo, é necessário seguir procedimentos rigorosos de formalização dassolicitações, de avaliação dos impactos que a mudança gerará nos outroscomponentes do projeto e em seu sucesso, informar os stakeholders, e atualizartoda a documentação do projeto atingida.


Processo de Mudança

O processo de mudança inicia-se na solicitação da mudança, portanto é altamenterecomendável que as solicitações sejam formais, isto é, feitas através de documentosreconhecidos pela organização executora. Idealmente deve-se utilizar formuláriospadronizados.


Um risco associado a mudanças em projetos é o tratamento inadequado, em geral,gerado pela confusão entre mudança e correção de desvio, medida corretiva, queleva a distorções do plano de gerenciamento do projeto.

A medida de gestão, ação corretiva ou correção de desvio tem origem diferente damudança. Vem de uma constatação feita a partir do monitoramento do projeto,enquanto que a mudança é uma nova demanda posta ao projeto, novo input.

� Solicitação - Definição do procedimento formal para a solicitação demudanças no escopo

� Avaliação - Definição do processo para avaliação dos impactos causadospelas mudanças solicitadas, a fim de propiciar a informação necessária para atomada de decisão quanto a autorização da mudança

� Autorização - Definição do processo e dos envolvidos na autorização dasmudanças solicitadas (Comitê de Controle de Mudanças)

� Documentação - Definição do processo de atualização da documentação doprojeto, em decorrência da mudança solicitada

� Comunicação - Comunicação aos envolvidos ou impactados pela mudança

Distribuição das Informações do projeto

O plano de comunicações estabeleceu o que deve ser comunicado, pra quaisstakeholders, em que momentos, e os meios que devem ser utilizados, portanto, ogestor do projeto, utilizará como guia a matriz de comunicações.


FORMULÁRIO DE SOLICITAÇÃO DE MUDANÇA NO PROJETO

Projeto Data da Solicitação Número

Solicitante

Descrição da Mudança

Justificava para a Mudança

Impactos no projeto e medidas para mitigação dos impactos

1. Escopo1.1.

2. Tempo2.1.

3. Custo3.1.

4. Qualidade4.1.

5. Riscos do projeto5.1.

Aprovador Data da Aprovação

As reuniões, um dos meios de comunicação essenciais para um projeto, que são, naverdade instrumentos poderosos de gestão, devem ser conduzidas pelo gestor doprojeto com muito rigor seguindo técnicas de coordenação de reuniões quegarantam que o tempo e recursos envolvidos sejam aproveitados da melhor formapossível, isto é, tenham eficácia.

Considerando-se que o tempo em projetos é recurso é, por definição, limitado e deinfluência direta nas outras variáveis do projeto, é obrigação primária do gestor doprojeto, administrá-lo com o máximo de cuidado. É recomendável para a estabilidadena função que o gestor do projeto seja, e transmita aparência de ser, organizado.Uma reunião que consuma mais tempo que o necessário e que não cumpra seusobjetivos, passa mensagens que atingem a reputação de profissional capaz deelaborar planos e realizar estes planos, que é expectativa básica de competência deum gestor de projetos.

Assim sendo, é essencial que sejam tomadas providências que garantam a eficiênciae eficácia das reuniões de projeto.

Coordenação de Reuniões

Objetivo da Reunião. Em um projeto há diversos tipos de reuniões necessárias aoseu gerenciamento: reunião de Kickoff (partida da execução), de avaliação demembros da equipe, de soluções técnicas, de lições aprendidas, de identificação deriscos, de brainstorming para definição do escopo, de progresso, para citar asprincipais. Portanto, é fundamental para a eficácia e especificação dos principaiselementos da reunião, tais como, a pauta e convocados, que seja bem definido oobjetivo da reunião.

Coordenador da Reunião. Elemento essencial para a eficácia da reunião deve terconsciência de que é o responsável pelo sucesso ou fracasso da reunião. No caso doprojeto, na maior parte das reuniões esta coordenação será exercida pelo gestor doprojeto que terá, neste papel, as seguintes atribuições:

� Preparar pauta e distribuir previamente aos participantes� Convocar participantes (necessários e suficientes)� Abrir a reunião (última reunião - fazer apresentações)� Conduzir a pauta (prioridade de assuntos)� Promover processos de tomada de decisões (votação) � Administrar conflitos e disputas de poder� Fechar a reunião (fazer resumo dos assuntos abordados)

Duração. Este talvez seja o fator mais crítico para o sucesso de uma reunião. Naverdade o fato dela, a duração, não ser definida com clareza e, principalmente,cumprida. A indefinição dos horários de início término e o não cumprimento desteslimites, faz com que os participantes cheguem atrasados, consome mais tempo do


que o necessário e joga o instrumento gerencial reunião no descrédito. Em analogiaao projeto como um todo, a duração está para a reunião, assim como o prazo limiteestá para o projeto.

Pauta. A pauta de uma reunião é o conteúdo, ou conjunto de assuntos que serãotratados na reunião. Se mantivermos a analogia com o projeto, a pauta equivaleriaao escopo do projeto. Neste caso, se o cumprimento da duração for consideradofator crítico de sucesso, a pauta deverá subordinar-se à duração. Isto é, a pautadeverá ter o tamanho que “caiba” na duração estabelecida para a reunião. Osestudiosos do assunto afirmam que reuniões tendem a ter pautas extensas namedida em que os problemas ou questões a serem tratadas se acumulam. Sendoassim, um projeto que estabeleça e siga um ciclo de controle adequado tenderá a termenos necessidade de pauta por reunião. Outra prática que conduz a reuniões mais“rápidas” é a adoção de um roteiro de pauta padronizado em formato de lista deverificação (checklist).

Agenda. Ainda na analogia, deve-se distribuir o tempo disponível determinandoperíodos de tempo proporcionais e específicos a cada assunto da pauta. Istodeterminará milestones, ou marcos nos quais o coordenador da reunião deverápromover processos de tomada de decisão, por votação, se for o caso, e passar aoassunto seguinte. Ou seja, se a pauta é o escopo, a agenda passa a ser ocronograma da reunião. Que, também, deve ser cumprido. A dificuldade deestabelecer limites de tempo por assunto é a mesma que se tem em dimensionardurações para realizações do escopo. Analogamente, deve-se “aprender” (liçõesaprendidas), melhorar esta distribuição de proporção com o planejamento e a práticaavaliada e estudada.

Periodicidade. É muito provável que haja necessidade de uma reuniãoextraordinária, ou emergencial para solucionar problemas, riscos que sematerializam, em um projeto, mas por princípio, as reuniões de um projeto devemser planejadas. Isto é, ao término da elaboração do plano de gerenciamento doprojeto, o gestor do projeto já deve ter o calendário das reuniões programadas.Sendo assim, este calendário deve ser divulgado com antecedência a fim de que osparticipantes convocados possam programar-se registrando em suas agendas. Seesta boa prática for adotada é conveniente que haja uma previsão de comunicaçãocom antecedência de adiamentos e cancelamentos. Não esqueçamos que areputação de planejador competente do gestor do projeto está em jogo.

Local. Informado e preparado previamente, o local da reunião, evita atrasos dosparticipantes e até mesmo do início possível da reunião. Deve, também, seradequado em termos de espaço e conforto, mas deve ser respeitado o princípio daeconomicidade. Isto é, locais desproporcionalmente grandes para o número depessoas e cujas instalações consumas muita energia, são contra-indicados.

Responsável pela Ata. Esta providência permitirá que os participantes que tenhamcontribuições ativas na reunião possam concentra-se nos assuntos e não se distraiamtendo que registrar o que é tratado na reunião. Em seguida, é recomendável que aassistente administrativa (contra-indicado que seja um técnico de valor-hora, emgeral maior) responsável pela redação da ata, envie aos stakeholders determinadosna matriz de comunicações para recebê-la.


Reuniões de Progresso

O monitoramento do projeto provê informações acerca do desempenho do projeto eseus desvios em relação ao plano. As providências de controle podem ser tomadasisoladamente, mas avaliações do progresso, isto é, o quanto foi realizado do que foiplanejado, como estão sendo aplicados os recursos do projeto, qual a magnitude dosdesvios, que previsões podem ser feitas para o restante do projeto, enfim, ogerenciamento do projeto em equipe deve ser realizado nas reuniões de andamentodo projeto, segundo o Guia PMBOK®, ou de progresso.

Devem ser realizadas de acordo com o CICLO DE CONTROLE do projeto. O focodeve ser avaliar o executado comparando com o planejado. O status ou situação, ouposição do projeto deve ser insumo para a reunião de progresso, isto é, deve serlevado pelos participantes em forma de relatórios para análise. Não é boa práticautilizar a reunião de progresso para “levantar” o status do projeto. A reunião deprogresso é uma reunião para análise de dados, e tomada de decisões.

Devem ser analisados os pontos de atenção, riscos identificados e riscos queperderam a potencialidade, e elaborar previsões de desempenho e de status futuros,preferencialmente utilizando a técnica do valor agregado que foi vista.

O processo de Verificação do Escopo e Aceitação Formal

A cada etapa concluída, antes de realizar a entrega, a equipe do projeto deverealizar uma inspeção, isto é, uma comparação entre o que está prestes a serentregue ao cliente e os requisitos definidos da qualidade.

Se resultado estiver dentro dos limites de tolerância estabelecidos, então a entregapoderá ser efetivada. Se o trabalho não estiver conforme, correções devem serrealizadas até que os requisitos sejam atendidos, para só então, ser entregue aocliente.

A prática de inspecionar o trabalho antes de entregar ao cliente segue o princípio deadministração geral que prega a economicidade de processo, ou seja, quanto maisdistante é identificada uma não-conformidade mais custo ela gera.

Dessa forma, se a não-conformidade for identificada ainda no âmbito do projeto, suacorreção gerará menos custo do que se for identificada nas “mãos” do cliente.

O cliente, por sua vez, ao receber o trabalho (a entrega), deve verificar aconformidade com os parâmetros da qualidade acordados. Estes parâmetros servirãode Critérios de Aceitação da entrega para o cliente.

Este processo de gerenciamento do projeto, realizado pelo cliente, é denominado deVerificação do Escopo, pois basicamente verifica se o escopo está completo e se foirealizado dentro dos critérios de aceitação.

Se o trabalho estiver dentro dos critérios de aceitação, isto é, conforme, o clientedeve, então dar o ACEITE FORMAL no trabalho.


Podem ser utilizados outros termos para designar a verificação do escopo: revisão deproduto, auditoria, homologação, etc.


Encerramento do Projeto

O processo de encerramento de projetos, por diversas razões, nãoé conduzido com o devido cuidado que sua importância requer. Alguns membros daequipe já estão dividindo seu tempo com outro projeto, conflitos podem ter ocorridoe gerado desgaste emocional, cansaço físico, os gerentes funcionais que cederamseus subordinados pressionam para os terem de volta, enfim, muitos fatoresconspiram para que o projeto seja abandonado e não encerrado formalmente.

Um processo de encerramento mal realizado, porém, causa danos não só ao projetoem si, mas à organização executora que perde a oportunidade valiosa de gerardados, informações e conhecimentos para aplicação nos projetos subsequentes,além de ficar sujeita a ações judiciais movidas pelo cliente por descumprimento docontrato, gerando prejuízos financeiros.

O encerramento do projeto consiste basicamente do encerramento administrativo edo encerramento dos contratos.

Se a administração dos contratos tiver sido realizada, ao longo do projeto, com aprática de acompanhamento através de uma planilha com as informações docontrato, e as obrigações tiverem sido cumpridas, os procedimentos deencerramento dos contratos serão bastante facilitados. Deixar qualquer contrato doprojeto em aberto, gera um risco grave á organização executora do projeto.

O encerramento administrativo confirmará que o trabalho foi realizado de acordocom os requerimentos e obter a aceitação formal do cliente. A partir da entrega doproduto final do projeto e da verificação do escopo, realizada pelo cliente. Se nãohouver correções de não-conformidades, poderá ser formalizada a aceitação doresultado do projeto, permitindo, então que sejam tomadas as demais providênciasadministrativas tais como:

� Preparar o relatório de performance final do projeto� Indexar e arquivar documentos� Realizar a reunião de balanço final de Lições Aprendidas (Lessons Learned)� Desmobilizar os recursos do projeto

Lições Aprendidas

Os estudiosos afirmam que o desenvolvimento de competências organizacionais nogerenciamento de projetos ocorre por processo histórico. Significa que a organizaçãodeve 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, conseqüentemente crescimento para aorganização.


Dois elementos são fundamentais para que este processo de aprendizado aconteça:

� Registro

� Análise

O registro é a documentação da história do projeto. A descrição com o maior nívelde detalhes das ocorrências do projeto. Como problemas e dificuldades foramsuperados, como desvios foram corrigidos, como soluções técnicas foramencontradas, enfim,

Visto que é um processo de aprendizado coletivo, seções de lições aprendidas sãomais produtivas se o foco é no aspecto positivo, isto é, foco nas soluções e não nos“erros”. O Dr. Joseph Juran já recomendava que problemas possuem causas e nãoculpados. Esta é uma boa postura a ser assumida pelo gestor do projeto se oobjetivo for criar um clima favorável ao aprendizado. A busca por culpados podetransformar o processo de lições aprendidas em uma troca de acusações e defesasque não trarão benefício.

É recomendável que sejam conduzidos processos, ou seções de lições aprendidas aolongo de todo o processo do projeto, porque alguns membros da equipe deixarão oprojeto quando forem concluídas suas atividades, porque quanto mais próximo dofato gerador, mais preciso é o relato das ocorrências, e, por fim, o processo sendorealizado desde o começo do projeto permite que os ganhos do aprendizado sejamaproveitados para o próprio projeto.

* * *


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 deJaneiro, Brasport, 2007.

GOLDRATT, Eliyahu M.. Corrente Crítica. São Paulo, Nobel, 1998.

HAMILTON, Albert. Management by Projects - Achieving Success in a ChangingWorld. London, Thomas Telford, 2003.

HELDMAN, Kim. Gerência de Projetos – Fundamentos. Rio de Janeiro, Campus, 2005.

KERZNER, Harold. Gestão de Projetos – As Melhores Práticas. São 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, JohnWiley, 2002.

PROJECT MANAGEMENT INSTITUTE - PMI. Um Guia do Conjunto de Conhecimentosem Gerenciamento de Projetos (Guia PMBOK®), 4ª Edição. Pennsylvania, PMI, 2008.

PROJECT MANAGEMENT INSTITUTE – PMI. Practice Standard for Project RiskManagement. 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, Américo. Benchmarking em Gerenciamento de Projetos Brasil: Relatório2004. Rio de Janeiro, Editora SENAI, 2005.

SHTUB, Avraham. Project Management - Engineering, Technology, andImplementation. New Jersey, Prentice-Hall, 1994.

Links:

Softwares sobre gerenciamento de projetos:http://en.wikipedia.org/wiki/List_of_project_management_software


Documents

Apostila Compass - Fundamentos de Gerenciamento de Projetos