Vous êtes sur la page 1sur 153

Federao das Indstrias do Estado de Minas Gerais - FIEMG

Gerenciamento de Projetos

Ipatinga 2012

Presidente da FIEMG
Olavo Machado Jnior

Diretor Regional do SENAI


Lcio Jos de Figueiredo Sampaio

Gerente de Educao Profissional


Edmar Fernando de Alcntara

Federao das Indstrias do Estado de Minas Gerais - FIEMG Servio Nacional de Aprendizagem Industrial - SENAI Departamento Regional de Minas Gerais CFP Rinaldo Campos Soares

Gerenciamento de Projetos

Robson R. Oliveira

Ipatinga Abril/2012

05/04/2012. SENAI. Departamento Regional de Minas Gerais SENAI/MG CFP Rinaldo Campos Soares

Ficha Catalogrfica

SENAI Servio Nacional de Aprendizagem Industrial Departamento Regional de Minas Gerais

FIEMG Av. do Contorno, 4456 Bairro Funcionrios 30110-916 Belo Horizonte Minas Gerais

Prefcio

Muda a forma de trabalhar, agir, sentir, pensar na chamada sociedade do conhecimento. Peter Drucker

O ingresso na sociedade da informao exige mudanas profundas em todos os perfis profissionais, especialmente naqueles diretamente envolvidos na produo, coleta, disseminao e uso da informao. O SENAI, maior rede privada de educao profissional do pas, sabe disso, e ,consciente do seu papel formativo , educa o trabalhador sob a gide do conceito da competncia: formar o profissional com responsabilidade no processo produtivo, com iniciativa na resoluo de problemas, com conhecimentos tcnicos aprofundados, flexibilidade e criatividade, empreendedorismo e conscincia da necessidade de educao continuada. Vivemos numa sociedade da informao. O conhecimento, na sua rea tecnolgica, amplia-se e se multiplica a cada dia. Uma constante atualizao se faz necessria. Para o SENAI, cuidar do seu acervo bibliogrfico, da sua infovia, da conexo de suas escolas rede mundial de informaes internet- to importante quanto zelar pela produo de material didtico.

Isto porque, nos embates dirios, instrutores e alunos, nas diversas oficinas e laboratrios do SENAI, fazem com que as informaes, contidas nos materiais didticos, tomem sentido e se concretizem em mltiplos conhecimentos. O SENAI deseja, por meio dos diversos materiais didticos, aguar a sua curiosidade, responder s suas demandas de informaes e construir links entre os diversos conhecimentos, to importantes para sua formao continuada ! Gerncia de Educao Profissional

Sumrio
1. Introduo ................................................................................................................................. 9 1.1. Definio de projeto ............................................................................................................ 9 1.2. Incerteza e complexidade ..................................................................................................11 2. Governana do projeto Papis e Responsabilidades.................................................................14 2.1. Os interessados (Stakeholders) .........................................................................................14 2.2. Administrador (Gerente) do Projeto ....................................................................................19 2.3. Equipe do Projeto ..............................................................................................................23 2.4. Cliente (Usurio) ................................................................................................................25 3. Fase de Iniciao de Projetos ...................................................................................................27 3.1. Como os projetos tm origem? ..........................................................................................28 3.2. Etapas da Iniciao ...........................................................................................................29 4. Produtos da fase ......................................................................................................................34 4.1.1. Escopo do projeto ......................................................................................................34 4.2. Anteprojeto ou Documento Inicial do Projeto (DIP) .............................................................35 5. Modelo de Termo de Referncia (Project Charter) ....................................................................38 6. Anteprojeto: Modelo de Anteprojeto ..........................................................................................40 7. Planejamento Estratgico .........................................................................................................44 7.1. O que Escopo do Projeto? ..............................................................................................45 8. Determinao do Cronograma ..................................................................................................52 8.1. Processo de definio das atividades ................................................................................52 8.2. Como preparar a lista ........................................................................................................53 8.3. Identifique as omisses......................................................................................................53 8.4. Estrutura Analtica do Projeto.............................................................................................54 9. Mtodos para elaborar o diagrama de rede...............................................................................56 9.1. Mtodo do diagrama de precedncias (MDP).....................................................................56 9.2. Mtodo de Diagrama de Setas...........................................................................................57 9.3. Mtodos de Diagramas Condicionais .................................................................................57 9.4. Estimativa de durao das Atividades ................................................................................58 9.5. Desenvolvimento do Cronograma ......................................................................................59 9.6. Definio do Cronograma ..................................................................................................60 10. Determinao do Oramento .................................................................................................63 10.1. Processos da administrao de custos do projeto ..........................................................63 10.2. Estimativa dos Custos....................................................................................................65 10.3. Oramentao dos Custos .............................................................................................68 10.4. Controle dos Custos.......................................................................................................69 10.5. Lies aprendidas ..........................................................................................................71 11. Elaborao do Plano de Gerenciamento da Qualidade ..........................................................73 11.1. Conceito de Qualidade...................................................................................................73 11.2. Processo de Gerenciamento da qualidade em projetos ..................................................74 11.3. Planejamento da qualidade ............................................................................................75 11.4. Controle da qualidade ....................................................................................................77 11.5. Resultados do Controle da Qualidade ............................................................................78 11.6. Ferramenta para o Controle da Qualidade......................................................................79 11.7. Aes corretivas ............................................................................................................80 11.8. Registros .......................................................................................................................81 11.9. Custo da qualidade ........................................................................................................82 11.10. Custos da Conformidade................................................................................................82 11.11. Custos da no Conformidade .........................................................................................82 11.12. Principais categorias de custos da qualidade .................................................................83 12. Gerenciamento do risco em projetos......................................................................................86 12.1. Definio de risco em projetos .......................................................................................86 12.2. Gerenciamento do Risco ................................................................................................86 12.3. Identificao ..................................................................................................................89 12.4. Resultados da Identificao de Riscos ...........................................................................91 12.5. Passo 2 - Anlise Qualitativa de Riscos .........................................................................92 12.6. Passo 3 - Anlise Quantitativa .......................................................................................96

12.7. Passo 4 - Planejamento de Respostas aos Riscos .........................................................98 12.8. Preveno .....................................................................................................................99 12.9. Transferncia.................................................................................................................99 12.10. Mitigao .....................................................................................................................100 12.11. Aceitao.....................................................................................................................100 12.12. Planejamento de contingncias....................................................................................101 12.13. Resultados do Planejamento de Respostas aos Riscos ...............................................101 13. Gerenciamento de Recursos Humanos em projetos ............................................................105 13.1. Habilidades comportamentais do Administrador do projeto...........................................105 13.2. Processos do Gerenciamento de Recursos Humanos ..................................................106 13.3. Montagem da equipe ...................................................................................................107 13.4. Limitaes para compor a equipe.................................................................................108 13.5. Desenvolvimento da Equipe .........................................................................................109 14. Planejamento da Comunicao ...........................................................................................111 14.1. Pontos importantes a considerar: .................................................................................112 14.2. Etapas do processo de Gerenciamento da Comunicao .............................................112 14.3. Planejamento da Comunicao....................................................................................113 14.4. Relatrios de Desempenho ..........................................................................................117 14.5. Encerramento Administrativo .......................................................................................117 15. Suprimentos e Contrataes................................................................................................121 15.1. Processo de gerenciamento do suprimento ..................................................................121 15.2. Planejamento do Suprimento .......................................................................................122 15.3. Solicitao e recebimento de ofertas ............................................................................126 15.4. Seleo de fornecedores .............................................................................................127 15.5. Administrao de contratos ..........................................................................................128 15.6. Encerramento de contrato ............................................................................................128 16. Execuo (progresso e mudanas) ......................................................................................132 16.1. O Processo de Controle ...............................................................................................133 16.2. O que acontece na fase de execuo ..........................................................................133 16.3. A reunio de partida - como iniciar positivamente.........................................................134 16.4. Execuo das Atividades .............................................................................................137 16.5. Gerenciamento da Mudana ........................................................................................137 16.6. Avalie o impacto da Mudana ......................................................................................138 16.7. Discuta as Mudanas ...................................................................................................139 16.8. Controle do risco ..........................................................................................................139 16.9. Relatrios de desempenho ..........................................................................................140 16.10. Entregas ......................................................................................................................141 16.11. Planejamento das Entregas .........................................................................................141 16.12. Entregas parciais .........................................................................................................141 16.13. Entrega final ................................................................................................................142 17. Fechamento do Projeto .......................................................................................................144 17.1. Relatrio de Avaliao de Ps Implementao (RAPI)........................................................145 17.2. Registro das Lies Aprendidas .........................................................................................146 17.3. Preparao do RAPI ....................................................................................................147 17.4. Encerramento administrativo ........................................................................................147 17.5. Assinatura do Cliente ...................................................................................................147 17.6. Pessoal e Equipamentos..............................................................................................148 17.7. Fechamento Financeiro ...............................................................................................148 17.8. Fechamento de contratos.............................................................................................148 17.9. Arquivamento...............................................................................................................149 17.10. Celebrao do sucesso ................................................................................................150 17.11. Reconhecimento ..........................................................................................................150

1. Introduo

O que um projeto?

Muitas coisas, por exemplo. Como, pensar na construo de uma estao espacial para ficar na rbita da Terra. Ou realizar um grande evento onde se mobiliza milhes de pessoas. Os casos citados, anteriormente, podem ser considerados empreendimentos de modo a serem caracterizados por meio de duas propriedades distintas, a primeira de que so ambos elementos concretos, e, a segunda, de que, sendo assim, devem ser administrados como projetos. Segundo Mathias (1986), projeto o conjunto de informaes internas e/ou externas empresa, coletadas e processadas com o objetivo de analisar-se uma deciso de investimento. J para Maximiano (2002), os projetos esto associados mais a certos atributos como: inovao, desenvolvimento, renovao, busca, construo, explorao e descoberta. Portanto, projetos alocam recursos ao longo do tempo, compatibilizando-os com o planejamento oramentrio, que desenvolvido pela rea e/ou departamento responsvel pela sua execuo, bem como pela integrao com outros departamentos da empresa. Faz parte de todo projeto considerar datas de inicio e trmino previamente estabelecidas, assim como a existncia de uma coordenao para se obter um resultado final, ao qual foram destinados recursos necessrios para o seu desenvolvimento. O estabelecimento dos projetos proporciona ao executivo da empresa condies de identificar e operacionalizar os planos de ao que a empresa ir desenvolver, com o objetivo de alcanar os resultados esperados (OLIVEIRA: 1998). Para toda empresa, existem diversas dvidas quanto realizao de determinado projeto, porm trs questes so fundamentais na proposta: - Que produto e/ou servio ser fornecido? - Quanto tempo ser o perodo de confeco? - Qual ser o custo?

Segundo Maximiano (2002), s vezes, um projeto precisa ser suspenso ou prorrogado, por causa de acidentes, eventos imprevistos, falta de recursos, ou ainda porque a estimativa do prazo foi incorreta. Estas dificuldades podem ser contornadas em alguns casos. No entanto, os prazos so inflexveis em outros casos. Eleies e competies oferecem o melhor exemplo. O que aconteceria se no fosse realizado no dia determinado? Apesar das dificuldades, a diminuio da margem de erro na previso dos tempos, e a concluso, dentro do prazo, devem ser perseguidas como ideais da administrao de projetos.

1.1. Definio de projeto


Um projeto pode abranger trs caractersticas importantes:

- Ser um empreendimento temporrio ou uma sequncia de atividades com comeo, meio e fim programados; - Ter como objetivo o fornecimento de um produto e/ou servio; - E possuir como fator determinante a sua previso de custos.

Estas trs caractersticas determinam variveis crticas de desempenho, uma vez que, atendidas podem significar o sucesso em sua realizao. Caso contrrio, deve-se analisar em qual item o projeto foi conduzido de maneira incorreta. Segundo Maximiano (2002), estas trs caractersticas citadas acima so definidas a partir do seguinte modo:

1.1.1. Atividade temporria Projetos so sistemas ou sequncias de atividades finitas, com comeo, meio e fim bem definidos. Uma atividade repetitiva, ou que tem durao contnua no um projeto, uma atividade funcional ou programa.

A durao limitada uma condio ideal que nem sempre ocorre, e que para as empresas, infelizmente, est longe de ser atendida. Na prtica, alguns projetos no tm prazo exato para terminar, arrastam-se indefinidamente, ou seja, terminam muito depois da data limite, pois iniciam-se sem definio clara das datas de inicio e de concluso. 1.1.2. Produto singular A ideia central para a definio de projeto est ligada ao produto e/ou servio que poder ser fornecido, o qual dever tornar-se naturalmente o escopo do projeto. Os produtos e/ou servios classificam-se em trs categorias principais: - Produtos fsicos: so tangveis e podem ser atividades temporrias, ao final das quais um item tangvel deve ser fornecido, como por exemplo, uma casa, rodovia, etc; - Conceitos: so intangveis, caracterizados por atividades conceituais como: ideias, roteiros de filmes, frmulas e teorias, etc; - Eventos: consistem na realizao de tarefas, servios ou atividades, sendo o projeto a prpria execuo da atividade que, em geral, representa apenas a parte final, e um conjunto de atividades de planejamento, organizao e controle. Vejamos abaixo alguns exemplos: - Planejar, organizar e realizar eventos como eleies e jogos olmpicos; - Implantar sistemas, processos e modelos de organizao; - Fazer uma expedio a algum planeta. O importante ressaltar que nenhum projeto pertence a apenas uma nica categoria, pois sempre existe a combinao entre elementos fsicos, conceitos e servios. 1.1.3. Oramento Num mundo voltado ao capitalismo, onde a questo de investimento , de certa forma, parte estratgica de uma empresa, calcular de maneira errnea o quanto ser gasto, ou at mesmo o prazo de execuo de um projeto, pode mudar completamente o rumo de determinada empresa, refletindo direto no montante de recursos financeiros disponveis. Porm nenhum projeto trabalha com previses oramentrias exatas, mas sim com estimativas de custos, cuja preciso depende do tempo que foi investido no planejamento, e que, consequentemente, tem muita importncia no aumento da preciso do oramento, portanto, o planejamento sempre fundamental, antes de qualquer coisa.

10

Segundo Maximiano (2002), no comeo de um projeto, impraticvel, em muitos casos, ir alm de uma ideia aproximada de custos. A preciso s possvel no comeo, quando as pessoas envolvidas tm muita familiaridade com o tipo especfico de projeto, e, alm disso, quando o projeto pertence a uma rea de aplicao na qual a tecnologia j esteja consolidada, como o caso da engenharia civil, por exemplo. O custo para se elaborar o oramento aumenta quando a tecnologia desconhecida ou quando h algum outro fator de incerteza no que diz respeito ao projeto. Este custo no deve desencorajar os clientes, patrocinadores ou gerentes de projetos, j que a pressa no incio pode representar uma grande variao nos custos reais da execuo, gerando prejuzos e conflitos entre as partes envolvidas.

1.2. Incerteza e complexidade


Todo projeto a ser desenvolvido possui um componente de incerteza, que pode ser visualizado como forma de escala. medida que o desconhecimento de um futuro projeto maior, consequentemente, o risco e a incerteza tendero na mesma proporo, pois isto afeta tambm a questo de se fazer previses em relao ao xito do projeto. Alguns projetos so conduzidos para lidar com incertezas pelas quais se verifica que a soluo para o projeto desconhecida desde o incio. Segundo Maximiano (2002), este o caso dos projetos de pesquisa na rea de medicamentos ou da cura de doenas, como cncer e AIDS. Estes projetos so fceis de identificar onde comeam, mas no onde terminam, sabendo-se pouco sequer se algum tipo de resultado vai ser conseguido por meio deles. To grande a incerteza, que a incapacidade de se alcanar um resultado prtico no considerada como fracasso, e nem mesmo a justificativa para se interromper determinada pesquisa, sendo apenas, a princpio, uma forma de aprendizagem. O processo de incerteza inerente a todos os tipos de projetos, sendo este elemento responsvel, entre outras coisas, pelo descumprimento de prazos e oramentos. Ainda de acordo com Maximiano (2002), um dos casos em que isto aconteceu em grande escala o tnel do Canal da Mancha, que comeou com um oramento de 7 bilhes de dlares, e terminou custando 14 bilhes. Outro exemplo a barragem de Trs Gargantas, na China, para a construo de uma hidreltrica, que foi orada em 8 bilhes de dlares e chegou at o montante de 30 bilhes.

11

Alguns projetos podem ser caracterizados como complexos, em virtude do nmero de variveis que podem vir a constitu-lo. Pode-se ressaltar tambm o seguinte detalhe: Projetos que envolvem poucas pessoas durante pouco tempo, as quais trabalham em locais de grande distncia geogrfica, podem ser muitas vezes complexos; Projetos que exigem muitas pessoas de reas diferentes, durante muito tempo, para trabalharem em conjunto, so projetos tambm complexos.

Do mesmo modo que a incerteza, a complexidade tambm pode ser medida por meio de escala. Eis algumas variveis que normalmente fazem parte de um projeto complexo: Multidisciplinaridade; Tipo de pessoal envolvido; Distncia geogrfica; Diversidade e volume de informaes; Nmero de organizaes envolvidas.

12

Sntese Nesta aula, vimos alguns conceitos que fazem parte do entendimento do que a Administrao de Projetos. Fizemos uma pequena introduo sobre o que um Projeto de Administrao, a Definio de um Projeto, apontando alguns itens que fazem parte de sua concepo como a Incerteza e Complexidade na Administrao de Projetos. Na prxima aula, veremos o projeto no processo de planejamento estratgico da empresa.

13

2. Governana do projeto Papis e Responsabilidades

Projetos so planejados e executados por pessoas. Portanto, para que o projeto seja bem sucedido importante definir uma estrutura formal para os indivduos envolvidos. Esta providncia faz com que as pessoas tenham claro entendimento das suas responsabilidades e autoridades que tm para realizar as atividades do projeto. A forma de se organizar o projeto varia com o tamanho e a natureza de cada um. Projetos grandes podem exigir dedicao integral da equipe para um nico projeto. Em projetos menores, os trabalhos podem ser executados em apenas uma parte do tempo do qual as pessoas dispem, o que permite com que um mesmo indivduo possa trabalhar em mais de um projeto simultaneamente ou dedicar parte do seu tempo ao projeto e o restante s atividades de rotina.

2.1. Os interessados (Stakeholders)


Os stakeholders so pessoas, grupos de pessoas ou organizaes ativamente envolvidas com o projeto ou cujos interesses possam ser positiva ou negativamente afetados pela execuo do projeto ou sua concluso. Desta definio, podemos depreender que os stakeholders podem ter interesse no sucesso (ou no insucesso) do projeto. Para assegurar o sucesso do projeto importante identificar e classificar estas pessoas, suas necessidades e expectativas, bem como a forma como elas podem contribuir para prejudicar o projeto, ou ainda traar um plano para lidar com todas elas. Note que nem todos os stakeholders fazem parte da equipe do projeto. Os stakeholders podem ser classificados nos seguintes grupos: Os diretamente relacionados com o projeto como, por exemplo, fornecedores de bens ou de informaes, usurios do produto do projeto, reas da empresa participantes da equipe do projeto, etc; Os que tm influncia nas condies do projeto como, por exemplo: rgos do governo, organizaes reguladoras; Pessoas, grupos de pessoas ou organizaes que tm interesse no projeto em algumas situaes como uma forma de atingir seus prprios objetivos.

14

2.1.1. Categorias de Stakeholders

Uma vez que tenhamos identificado os diversos stakeholders, podemos classific-los em categorias de acordo com o seu grau de influncia para alavancar os prs, os neutros e aqueles que podem prejudicar o projeto. Desta forma, podemos construir uma matriz (como mostrado a seguir) com categorias e quantificar a posio e o grau de influncia que o stakeholder possui.

Legenda: C1 Nesta coluna, vamos identificar o stakeholder que pode ser uma pessoa, um departamento ou setor da empresa ou ainda uma organizao externa. C2 at C6 Nestas colunas, vamos classificar a posio do stakeholder com relao ao projeto. Neste caso, -2 significa que o stakeholder frontalmente contrrio ao projeto, 0 significa que indiferente (neutro) e +2 que completamente favorvel. C7 - Nesta coluna, vamos identificar o grau de influncia que ele tem para favorecer ou prejudicar o projeto. C8 Nesta coluna, vamos identificar estratgias para lidar com cada stakeholder. Vamos verificar que aqueles que tm posio extrema (-2 ou +2) devem ser acompanhados por algum da equipe do projeto. Uma outra forma de se analisar e definir estratgias de acompanhamento dos stakeholders mostrada bem abaixo.

15

Qualquer das formas ou uma combinao das duas deve ser aplicada pela equipe do projeto para no ser surpreendida por atitudes inesperadas dos stakeholders.

2.1.3. Quem so os Stakeholders?

Stakeholders podem incluir: 1. O Patrocinador - geralmente o maior interessado. a pessoa-chave para garantir recursos ao projeto; 2. O Gerente do projeto aquele que tem a responsabilidade de assegurar o sucesso do projeto; 3. O usurio (cliente final) - que a pessoa ou o grupo de pessoas que ir usar o produto do projeto; 4. Os membros da equipe - que so os responsveis por executar as atividades do projeto; 5. Departamentos ou reas dentro da empresa executora do projeto; 6. Organizaes externas interessadas no resultado do projeto.

Importncia dos Stakeholders Clientes (internos e externos) so considerados stakeholders importantes. O estabelecimento dos objetivos do projeto com base nas necessidades e expectativas dos interessados aumenta as chances de sucesso do projeto. Tambm o adequado gerenciamento das expectativas importante e muitas vezes difcil de ser realizado, pois pode tratar de interesses divergentes. Encontrar o equilbrio para estas divergncias fator-chave para o sucesso do projeto, j que as expectativas e recursos disponveis podem no ser compatveis. Projetos que no tenham um claro vnculo com a alta administrao da empresa podem encontrar dificuldade em obter recursos para sua execuo.

16

Principais stakeholders Um projeto tpico pode apresentar os seguintes stakeholders: Patrocinador (Sponsor); Gerente do projeto; Membros da equipe; Cliente (Solicitante); Usurio; Organizao executora; Fornecedores e contratados; Agncias governamentais; Organizaes ambientalistas; Cidados; Lobistas; Etc.

Vamos analisar papis e responsabilidades de cada um destes stakeholders.

2.1.4. O Patrocinador (Sponsor)

Um dos stakeholders mais importantes Patrocinador. Ele deve ter influncia na empresa de forma a assegurar com que o projeto receba prioridade e recursos suficientes. Normalmente, um alto executivo da empresa com claro interesse na concluso bem sucedida do projeto e que, em grande parte dos casos, recebe o produto do projeto.

17

O patrocinador detm o maior grau de autoridade no projeto e so dele as decises importantes em caso de divergncia. Ele d apoio e suporte equipe do projeto e aprova as entregas intermedirias. Em alguns casos, o Patrocinador delega algumas destas atribuies outra pessoa dentro ou fora da equipe do projeto.

Caractersticas desejveis do Patrocinador

a) Conhecimentos Princpios e prticas de administrao de projetos; Responsabilidades associadas com a funo de patrocinador; Conhecimentos de elaborao e avaliao de propostas; Conhecimento do Plano Estratgico da empresa.

b) Habilidades Liderana Relacionamento interpessoal Boa comunicao

c)

Responsabilidades do Patrocinador

Funes Gerais: Articular a alta administrao para que o projeto receba recursos e prioridade; Assegurar com que as especificaes e requisitos sejam alcanados.

18

Na Fase de Iniciao: - Definir necessidades e objetivo do projeto; - Assegurar suporte e apoio a equipe.

Na Fase de Planejamento: - Revisar e aprovar o Plano do Projeto; - Participar das atividades de planejamento; - Buscar e aprovar recursos para o projeto frente diretoria da empresa.

Na Fase de Execuo: - Indicar pessoas por intermdio do gerente do projeto; - Participar da reunio de partida; - Participar das reunies de reviso do projeto; - Fornecer aprovaes a produtos intermedirios do projeto; - Apoiar na soluo de problemas.

Na Fase de Fechamento: - Participar da reunio de identificao de lies aprendidas.

2.2. Administrador (Gerente) do Projeto


O gerente responsvel pela qualidade dos produtos do projeto e pela sua concluso com sucesso. Suas responsabilidades incluem a elaborao do plano do projeto, a execuo das atividades planejadas e o trmino no prazo, dentro do oramento e dos nveis de qualidade aceitveis.

19

Normalmente, o gerente do projeto indicado nas fases iniciais de modo a participar integralmente das definies do projeto. Ele responsvel por organizar o projeto em subprojetos, gerenciar os seus aspectos rotineiros, desenvolver planos de execuo de atividades, resolver problemas de planejamento ou de execuo, alm de monitorar e reportar progresso.

2.2.1. Responsabilidades do Gerente do Projeto Funes Gerais: Implementar polticas e procedimentos na conduo do projeto; Buscar a obteno de recursos necessrios para a realizao das atividades do projeto; Manter a equipe motivada e providenciar treinamento quando necessrio; Estabelecer nveis de qualidade aceitveis para o projeto; Identificar e homologar ferramentas para serem usadas no projeto; Influenciar as expectativas dos clientes, do Patrocinador e de outros envolvidos com o projeto por meio do desenvolvimento de planos e acordos em detrimento dos objetivos do projeto; Assegurar o comprometimento dos envolvidos no projeto.

Na Fase de Iniciao: Desenvolver a proposta de projeto incluindo os seus critrios de sucesso; Conduzir anlise de custo/benefcio quando necessrio; Assegurar com que o escopo do projeto reflita adequadamente o objetivo e as medidas de performance do projeto; Estabelecer a estrutura, organizar as pessoas e definir papis e responsabilidades no projeto; Documentar as premissas e as restries do projeto.

20

Na Fase de Planejamento Desenvolver e manter planos detalhados de execuo; Criar os instrumentos de medio de performance do projeto; Dar suporte equipe na elaborao dos planos; Assegurar com que os Planos do Projeto sejam aprovados; Alocar recursos para as atividades de planejamento.

Na Fase de Execuo Gerenciar e monitorar as atividades do projeto tendo como base os planos detalhados de oramento e cronograma, fornecendo orientao aos membros da equipe; Monitorar continuamente o desempenho do projeto para identificar mudanas que possam afetar o resultado final do projeto; Comunicar com frequncia e regularidade o progresso do projeto para os nveis hierrquicos de diretoria da empresa ou simplesmente ao cliente; Assegurar com que as mudanas necessrias sejam incorporadas no projeto e que os planos sejam atualizados; Atualizar o plano de gerenciamento do risco e estabelecer aes de preveno ou mitigao conforme necessrio; Obter aprovaes para produtos intermedirios produzidos.

Na Fase de Fechamento Desenvolver planos de ao para entregas (deliverables) ainda no aprovados; Obter aprovao formal para produtos entregues; Efetuar o fechamento de contratos; Elaborar o Relatrio de Fechamento e Avaliao do Projeto, incorporando Lies Aprendidas; Arquivar todos os documentos do projeto;

21

Celebrar sucesso com o Patrocinador e a equipe.

Habilidades do Administrador do Projeto

Liderana: Habilidades estratgicas, conceituais e analticas; Tomada de deciso; Adaptabilidade e flexibilidade; Habilidade de formao de equipe.

Habilidades interpessoais: Habilidade de orientao e consultoria; Habilidade de negociao num contexto de interesses conflitantes.

Habilidades de comunicao: Habilidades de apresentao e comunicao escrita; Habilidades de discusso de assuntos complexos com noespecialistas.

Habilidades de gerenciamento de projetos: Planejamento de atividades e alocao de recursos; Gerenciamento do risco; Gerenciamento de problemas; Gerenciamento do tempo; Gerenciamento de finanas;

22

Gerenciamento de pessoas; Trabalho em equipe; Gerenciamento da qualidade; Monitoramento e relatrios; Documentao e guarda de registros.

O conhecimento tcnico do produto do projeto crtico para se ganhar credibilidade em relao equipe e perante os pares e superiores.

2.3. Equipe do Projeto


A equipe liderada pelo gerente e trabalha para realizar as atividades previstas no plano do projeto. desejvel que a equipe seja formada por pessoas ligadas s reas que sero afetadas pela execuo ou pelo produto do projeto. A composio da equipe poder variar medida que o projeto avance em suas fases. A seleo de pessoas com o conhecimento e habilidades necessrias para a execuo das atividades vital para o sucesso do projeto. Sem estas capacidades presentes na equipe, grande a chance de fracasso do projeto. Os conhecimentos e habilidades necessrias devem ser claramente definidas pelo gerente do projeto.

a) Responsabilidades da equipe

Funes Gerais Identificar solues tcnicas e alternativas; Implementar as solues encontradas; Dar suporte s atividades de monitoramento do projeto.

23

Na Fase de Iniciao Fornecer estimativas para a elaborao da proposta; Assegurar com que as especificaes sejam adequadas para o objetivo do projeto; Analisar os requisitos com relao consistncia e disponibilidade de recursos.

Na Fase de Planejamento Desenvolver a documentao tcnica do projeto; Identificar ferramentas e mtodos aplicveis ao projeto.

Na Fase de Execuo Submeter os relatrios de status ao gerente do projeto; Conduzir as atividades de acordo com o estabelecido no plano do projeto; Identificar e documentar riscos; Participar das reunies de avaliao do progresso do projeto; Realizar as atividades de testes e ensaios nos produtos do projeto. Na Fase de Fechamento Identificar e documentar lies aprendidas.

24

2.4. Cliente (Usurio)


Os usurios do produto do projeto so responsveis por expressar suas necessidades e expectativas de modo claro e completo. O cliente principal do projeto, por sua vez, responsvel pela aplicao do produto do projeto e pela realizao dos benefcios previstos na fase de iniciao.

Responsabilidades do Usurio

Funes Gerais Articular os requisitos dos usurios; Propor alternativas de soluo.

Na Fase de Iniciao Definir os requisitos e caractersticas esperadas para o produto do projeto.

Na Fase de Planejamento Revisar e validar o plano do projeto.

Na Fase de Execuo Validar os produtos intermedirios. Apoiar testes e ensaios. Participar de reunies de reviso do projeto.

25

Na Fase de Fechamento Assinar as aprovaes de deliverables; Participar da reunio sobre Lies Aprendidas.

Sntese

Vimos que um projeto tem alguns aspectos comuns para os envolvidos. As atividades so realizadas pela equipe do projeto e observadas pelos que tm interesse no projeto os stakeholders. Satisfaz-los um mantra da equipe e principalmente do Administrador do projeto. Para isto, necessrio que estes interessados sejam adequadamente gerenciados. A correta identificao e classificao dos stakeholders em favorveis ou desfavorveis ao projeto bem como o desenvolvimento de estratgias para lidar com estes interesses pode fazer a diferena entre sucesso e insucesso do projeto. Os quatro Stakeholders primrios seriam, a princpio: O Patrocinador (gerente geral do projeto); O Administrador (gerente do projeto); A equipe; e O Cliente (Usurio).

26

3. Fase de Iniciao de Projetos

Agora que sabemos o que um projeto e que identificamos quem est envolvido nele, vamos ao primeiro passo para se dar a nossa caminhada para administrar projetos A INICIAO. Embora s vezes no haja um acordo uniforme sobre os estgios especficos de iniciao de um projeto e os processos associados, sabe-se que, para que um projeto exista, deve ter um incio. Esta fase pode ser definida como o processo de planejar os objetivos e a definio das aes necessrias para completar o projeto. Este processo envolve a identificao das atividades, a sequncia que acontece e uma estimativa, grosso modo, da durao de cada atividade e dos recursos necessrios para sua realizao, estimando-se com isto o oramento e o cronograma iniciais do projeto. Portanto, a fase de Iniciao envolve o planejamento e o raciocnio conceitual acerca da necessidade a ser atendida pelo projeto, alm dos produtos intermedirios entregues pela equipe. Produtos finais e intermedirios (Deliverables) so os resultados esperados do projeto, isto , os produtos e servios esperados pelos clientes. Como, normalmente, os produtos de um projeto so inditos, nas fases iniciais os atributos ainda no so totalmente conhecidos, porm tornam-se melhor definidos medida que o projeto avana. O objetivo da Iniciao produzir um conjunto de documentos que justifique e defina o projeto e forme a base para o gerenciamento durante as outras fases do ciclo de vida deste projeto. Este conjunto de documentos um elemento crtico para garantir aceitao e comprometimento por parte dos envolvidos. Estes documentos so o produto mais importante a ser produzido nesta fase, pois maximizam as chances de se obter o produto certo, dentro do prazo, de acordo com o oramento e com as caractersticas especificadas. Comear o projeto de forma certa melhor do que corrigir expectativas e objetivos ou redirecionar os esforos da equipe mais tarde. Um eficiente incio de projeto resulta em fundamentao slida para o alcance dos objetivos. Alm disso, a Iniciao do projeto representa a primeira oportunidade de reunir a equipe e obter entendimento comum das expectativas dos stakeholders, bem como definir as responsabilidades de cada integrante da equipe para se obter consenso e comprometimento a fim de alcanar os objetivos propostos.

27

Ao final desta fase, a equipe deve fornecer clculos estimados dos recursos requeridos e obter aprovao para se prosseguir rumo prxima fase (fase de planejamento).

3.1. Como os projetos tm origem?


So diversas as maneiras de se iniciar um projeto, mas todas comeam com uma ideia. Projetos podem comear de maneira formal ou informal. A maneira formal de comear um projeto compreende uma estrutura de guias, modelos de documentos, apresentando uma sequncia de etapas determinadas com pontos definidos de controle para facilitar o trabalho do gerente e da equipe durante a fase de concepo do projeto. Na maneira informal, normalmente, um grupo de pessoas discute uma boa ideia e busca adeptos para desenvolver o projeto. medida que a ideia evolui, o grupo sente que necessita, num determinado momento, de formalizao e documentao, passando ento a registrar o plano a ser seguido. Do exposto depreende-se que os projetos podem variar em termos de magnitude e complexidade, mas todos devem ter algum nvel de documentao inicial. Para alguns, este documento pode tomar apenas algumas horas ou dias para ser elaborado, para outros pode levar semanas. Em essncia, os projetos so criados por razes diferentes, contudo os projetos dedicam considerao especial para o custo, durao e prioridade para a empresa. Uma caracterstica comum a todos os projetos que eles so criados para atender a uma necessidade. So muitas as necessidades que nos levam a decidir por implementar um projeto. Pode ser uma solicitao de um cliente, a identificao de uma oportunidade de mercado, a verificao de que algum concorrente possui um produto que nossa empresa no tem, a necessidade de um novo produto detectada por pesquisa, etc. Nesta aula, vamos discutir os processos bsicos a serem seguidos para se reconhecer o fato de que um projeto deve ser iniciado e de quais documentos devem ser produzidos para caracterizar que um novo projeto comeou. O objetivo desta fase especificar o que ser obtido ao trmino do projeto. Eis alguns exemplos de possveis projetos: Implantao ou expanso de uma nova fbrica; Lanamento de um novo produto ou um servio;

28

Aumento da capacidade de processamento de dados, e desenvolvimento de sistemas e novos programas; Implementao de mudana organizacional.

3.2. Etapas da Iniciao

Todas as metodologias de gerenciamento de projeto enfatizam a necessidade de um bom incio, atravs de uma clara definio, que culmina numa srie de documentos que caracterizam a Iniciao do projeto. O objetivo desta fase dar uma clara indicao dos impactos e benefcios esperados e uma ideia, grosso modo, do custo global, da durao estimada e de produtos intermedirios que se espera que o projeto produza. Os documentos iniciais devem apresentar de forma concisa a justificativa do projeto, os objetivos, os fatores crticos de sucesso, os produtos intermedirios custos e benefcios, os projetos relacionados e os riscos aos quais o projeto est exposto. A elaborao destes documentos assegura com que os tpicos principais como necessidades e objetivos estejam completamente definidos, entendidos e aceitos por todos os envolvidos. O objetivo no produzir documentos extensos, mas fornecer informaes necessrias para se avaliar a oportunidade de iniciar (ou no) um projeto. A seguir, vamos apresentar uma sequncia de atividades que pode ser aplicada grande maioria dos projetos e que auxilia na definio dos parmetros gerais, durante a fase de Iniciao. Os tpicos foram organizados de maneira consistente a partir do desenvolvimento do projeto, durante esta fase.

3.2.1. Indicao de um Lder Na fase embrionria do projeto, nomeia-se uma pessoa que ser responsvel por conduzir os primeiros estudos sobre a ideia e seu desenvolvimento. Este Lder, que poder ou no ser o futuro gerente do projeto, responsvel por: Definir os objetivos do projeto;

29

Coordenar a elaborao dos documentos iniciais do projeto; Apresentar as concluses e obter autorizao para prosseguir.

3.2.2. Identificao do patrocinador Como vimos na aula anterior, o Patrocinador responsvel pela direo estratgica do projeto. Ele deve ter autoridade para definir os objetivos do projeto, assegurando recursos para resolver prioridades organizacionais e conflitos. Diversos estudos indicam que existe uma relao direta entre a falta de um Patrocinador e o fracasso de projetos. Reveja a aula anterior para relembrar as responsabilidades do Patrocinador.

3.2.3. Definio da Necessidade / Oportunidade Projetos so criados a partir de necessidades ou de oportunidades. A correta identificao fundamental para todo o desenvolvimento das atividades do projeto. Tipicamente, uma necessidade ou uma oportunidade pode ser relacionada com: Prestar servio mais eficiente; Reduzir custos; Gerar mais lucros; Oferecer um novo produto; Implantar um sistema mais confivel.

As discusses da equipe devem fornecer entendimento para: O que originou a necessidade ou como a oportunidade foi reconhecida; A magnitude da oportunidade; As consequncias, caso a necessidade / oportunidade no seja atendida.

30

3.2.4. Definio do Escopo geral do projeto Redija um texto conciso que trate do que o projeto vai cumprir e, se apropriado, o que est fora do escopo. O nvel de detalhamento deste texto deve ser suficiente para se desenvolver a declarao de escopo na fase de planejamento.

3.2.5. Definio dos objetivos do projeto Objetivos descrevem os produtos, servios ou processos que o projeto quer realizar. Cada objetivo deve ser descrito de forma que se possa avaliar se ele foi alcanado, ao trmino do projeto. Eles so usados para medir o desempenho do projeto por meio da comparao entre o que foi planejado e o que foi efetivamente realizado. Alguns gerentes de projeto classificam os objetivos em torno de duas naturezas Objetivos hard Relacionados com a durao, o custo e a qualidade do produto do projeto; Objetivos soft Relacionados com a forma como os objetivos sero atingidos, podendo incluir atitudes, comportamento, expectativas e comunicao. Os Objetivos do projeto devem estar de acordo com as necessidades dos stakeholders e serem comunicados no Documento Inicial de Projeto (DIP), tambm conhecido como Anteprojeto.

3.2.6. Identificao das Premissas e Restries Premissas so fatores que, para os propsitos do planejamento, so consideradas verdadeiras, reais, ou certas. Por exemplo, se a data na qual uma pessoa-chave estiver disponvel para o projeto incerta, a equipe poder assumir uma data de incio especfica. As premissas geralmente envolvem certo grau de risco. (PMBOK PMI) Restries so fatores que limitam as opes da equipe de gerncia do projeto. Por exemplo, um oramento pr-definido uma restrio que na maioria das vezes limita as opes da equipe com relao ao escopo, pessoal e prazos. Quando um projeto desenvolvido sob contrato, as provises contratuais so geralmente restries. (PMBOK PMI)

31

Projetos tm restries em termos de tempo, recursos, equipamentos, instalaes, etc. As restries formam a base para a estratgia do projeto. Por exemplo, podemos decidir ampliar o prazo em funo da indisponibilidade de uma determinada mquina por um perodo. importante identificar as restries e premissas de um projeto, logo na fase inicial, antes que as atividades do projeto comecem para evitar iniciar projetos que no tenham suficiente fundamentao.

3.2.7. Identificao e envolvimento dos principais stakeholders Como j vimos na aula anterior, stakeholders so pessoas ou organizaes que tm interesse no sucesso (ou fracasso) do projeto. A identificao dos stakeholders auxilia na definio e no direcionamento, contribuindo para a definio do escopo do projeto. A equipe do projeto deve identificar os stakeholders, determinar suas necessidades e expectativas, alm de influenciar suas decises de modo a assegurar o sucesso do projeto, pois o entendimento e o gerenciamento das necessidades bem como expectativas crucial para o sucesso do projeto. Uma ferramenta muito til a Matriz de Stakeholders. Construa uma matriz relacionando os stakeholders, seus interesses, grau de influncia, e estratgia da equipe para lidar com a situao.

3.2.8. Identificao dos riscos potenciais Projetos encerram incertezas, principalmente no seu incio. Por isso, importante se elaborar um documento de estudo dos riscos ao qual o projeto est exposto para identificar, quantificar, priorizar, e estabelecer estratgias de mitigao para os principais riscos. Risco qualquer fator que pode potencialmente afetar na capacidade do projeto concretizar seu resultado. Identificar o risco reconhecer que algum evento pode se transformar num problema. Um risco no um problema, pois problema um risco que se materializou.

3.2.9. Estimativa de Prazo Divida o projeto em etapas distintas, e identifique as macro-atividades necessrias para completar o projeto. Estabelea uma seqncia e estime suas duraes. Identifique as atividades crticas. Especifique o produto de cada etapa.

32

Elabore um cronograma mostrando as fases e as atividades crticas. Por ltimo, Identifique pontos de medio e relao ao progresso do projeto e assinale estes pontos no cronograma.

3.2.10. Estimativa de Custo Com base no cronograma, relacione os recursos necessrios para realizar as atividades. Determine custos para os recursos e calcule o custo por atividade, por fase, e tambm o custo total estimado do projeto.

33

4. Produtos da fase
Com as informaes coletadas, a equipe produzir pelo menos dois documentos que sinalizam o fim da fase de Iniciao. Estes documentos so o Termo de Referncia e o Anteprojeto.

4.1. Termo de Referncia (Project Charter) Veja um modelo no item 6. O Termo de Referncia o documento criado para comunicar formalmente a existncia de um novo projeto. Este documento editado no final da fase de Iniciao e serve como base para a elaborao do Plano do Projeto. Ele deve conter, seja diretamente ou por referncia a outros documentos: As necessidades que o projeto est incumbido de tratar; A descrio do produto. O Termo de Referncia deve ser emitido por um gerente externo e em um nvel apropriado s necessidades do projeto. Ele fornece autoridade ao gerente do projeto para usar recursos organizacionais nas atividades do projeto. Quando um projeto regido por um contrato, o contrato assinado servir, geralmente, como o Termo de Referncia para o vendedor. (PMBOK PMI) Ele serve para fornecer informaes gerais a respeito do projeto e deve ser preparado com nvel de detalhe, apropriado para a complexidade do projeto, a qual permita a avaliao por parte da alta administrao. O Termo de Referncia pode conter, mas no se limitar ao seguinte contedo: escopo do projeto, autoridade do gerente do projeto e fatores crticos de sucesso. Vejamos a seguir o que significa cada um deles.

4.1. Escopo do projeto


O escopo do projeto especifica o que dever ser feito, como as entregas intermedirias e as responsabilidades das partes envolvidas. importante que a equipe defina o que est fora do escopo como forma de evitar conflitos mais tarde.

34

4.1.1. Autoridade do gerente do projeto Durante a execuo de um projeto, muitas decises so tomadas para manter o compromisso de entregar o produto nas condies estabelecidas. Por esta razo, o Temo de referncia define a autoridade do gerente e os mecanismos para resolver conflitos. O Termo de Referncia nomeia um gerente e formaliza sua relao com a administrao da empresa bem como com outros stakeholders.

4.1.2. Fatores Crticos de Sucesso Para assegurar com que o projeto tenha progresso satisfatrio devem ser identificados certos marcos com datas claramente definidas, pelas quais o progresso do projeto ser medido, na medida em que os compararmos com os objetivos planejados. Estes marcos podem ser usados para aprovar a concluso de uma determinada fase e estabelecer uma deciso de parar ou prosseguir. Os fatores crticos de sucesso asseguram com que produtos e servios entregues atendam aos objetivos com relao a prazo, custo e qualidade.

4.2. Anteprojeto ou Documento Inicial do Projeto (DIP)


Veja um modelo no item 8. Ao final da fase de Iniciao, depois de coletadas todas as informaes, voc deve redigir um documento contendo as principais definies do projeto. A este documento damos o nome de Anteprojeto. O contedo deste documento segue a sequncia dos passos da fase de Iniciao, descritos nas etapas da Iniciao. O Anteprojeto serve para definir o que deve ser feito, por que deve ser feito, e que benefcios o projeto poder apresentar. Ele tambm deve especificar os produtos que cada fase deve produzir e um cronograma macro das fases do projeto divididas numa sequncia de atividades.

35

Este documento fornece a fundamentao para se iniciar o projeto e serve para medir o sucesso ao seu trmino. medida que o projeto avana, so necessrias mudanas que sero efetuadas de maneira consciente, considerando todas as alternativas para sua implementao. O perodo de preparao deste documento pode variar de horas a semanas, dependendo da complexidade do projeto. Todo projeto nico e cada um requerer nveis de detalhamento e pesquisa diferentes, levando a diferentes prazos para a elaborao do anteprojeto. Vrios so os mtodos aplicados elaborao do anteprojeto, como, por exemplo: Sesses de brain storming; Reunies executivas formais; Reunies com stakeholders; Contribuio de especialistas; Estes mtodos podem ser utilizados individualmente ou em conjunto para se produzir o anteprojeto. O anteprojeto pode conter, mas no se limitar ao seguinte contedo: objetivo, descrio do produto, determinao da viabilidade, indicao do gerente, indicao da equipe do projeto, identificao dos stakeholders e clientes.

4.2.1. Objetivo O objetivo define os principais aspectos do projeto e forma a base para o seu gerenciamento e avaliao do sucesso.

4.2.2. Descrio do produto A descrio do produto do projeto parte integrante do DIP e descreve as caractersticas do produto/servio/processo a ser criado. Indica ainda quais necessidades que geraram o projeto e como elas sero satisfeitas. Tipicamente, a descrio do produto no chega a nveis de detalhe, que sero objeto da fase de planejamento.

36

4.2.3. Determinao da viabilidade A determinao da viabilidade do projeto desempenha um importante papel na sua Iniciao. Existem quatro passos bsicos que devem ser considerados ao se efetuar um estudo de viabilidade: Descrio da necessidade; Estratgia a ser adotada; Solues possveis para a situao; Recomendaes preliminares;

4.2.4. Indicao do gerente O gerente do projeto ir definir o objetivo, estabelecer os fatores crticos de sucesso, obter as informaes necessrias, determinar os estudos iniciais e desenvolver estimativas de custo e prazo para o projeto.

4.2.5. Indicao da equipe do projeto Deve ser definida em funo da complexidade e do esforo necessrio para completar o estudo inicial do projeto.

4.2.6. Identificao dos Stakeholders e Clientes Indivduos e organizaes que so ativa ou passivamente envolvidos no projeto e que podem ser positiva ou negativamente afetados pelo projeto ou pelo seu produto.

Sntese

37

Nesta aula, vimos alguns conceitos que fazem parte da primeira fase do ciclo de vida dos projetos - a fase de INICIAO. Mostramos atividades inerentes a esta etapa e os documentos que caracterizam o trmino da fase.

5. Modelo de Termo de Referncia (Project Charter)

Situao Atual: Explicar os eventos que conduzem a solicitao do projeto. Descrever projetos relacionados que possam ter influenciado este projeto. Identificar quem est envolvido e a situao atual do projeto.

Objetivos do Projeto Informar como os resultados do projeto beneficiam a empresa e auxiliam no alcance dos objetivos organizacionais ou corrigem um problema. Fornecer detalhes referentes ao custo benefcio.

Escopo do projeto Especificar o que dever ser feito, no caso das entregas intermedirias. importante deixar claro o que est fora do escopo.

Fatores Crticos de Sucesso:

38

Fornecer uma lista de pelo menos cinco fatores de sucesso. Estas so reas nas quais o projeto no pode falhar e as quais sero baseadas nos objetivos organizacionais a serem alcanados ou nos problemas a serem resolvidos.

Premissas e Restries Listar quaisquer fatores conhecidos que limitam a execuo do projeto. A restrio mais frequente a data final do projeto. Para cada restrio listada, demonstrar de que maneira est limitando o projeto e quais seriam os benefcios da sua remoo.

Autoridade no Projeto: Esta seo identifica os envolvidos no projeto e seus respectivos nveis de autoridade, quem tem competncia para resolver conflitos e quem vai fornecer a direo geral para os esforos do projeto. Esta seo deve conter, no mnimo, os papis e responsabilidades da equipe do projeto e dos stakeholders. Deve tambm identificar qualquer estrutura de controle ou comit de direcionamento aos quais o projeto est ligado.

Aprovaes Revisei as informaes constantes do Termo de Referncia datado de ______, e estou de acordo e compromissado com as bases estabelecidas neste documento.

39

6. Anteprojeto: Modelo de Anteprojeto


Modelo de Anteprojeto <Projeto>

Aprovaes Revisei as informaes constantes do Anteprojeto datado de dd/mm/aaaa, e estou de acordo e compromissado com as bases estabelecidas neste documento.

40

41

42

43

7. Planejamento projeto
Vimos na aula anterior que a fase de INICIAO de um projeto se completa coma edio do Termo de Referncia e do Anteprojeto. Uma vez que a ideia apresentada nestes documentos for aprovada por quem de direito (numa empresa normalmente a Diretoria), passamos para a fase de PLANEJAMENTO do projeto. O Planejamento de Projeto comea logo depois da fase de iniciao. O tempo aplicado na correta identificao das necessidades e na organizao do projeto elimina horas de retrabalho e confuso que seriam gastas na fase de Execuo. O Plano do projeto produzido nesta fase permite com que todos os envolvidos tenham o mesmo entendimento e conheam quais so os resultados esperados do projeto. Isto assegura com que questes crticas possam ser previstas e resolvidas com eficincia e eficcia, e forma tambm uma base para decises futuras, incluindo os critrios para se definir se o projeto ou uma fase do projeto foi concluda com sucesso. A fase de Planejamento do Projeto constituda por diversos estgios. Cada estgio produz documentos, os quais so coerentemente conjugados em um nico documento denominado Plano do Projeto, o qual pode ser usado como guia na fase de Execuo e Controle do Projeto. Nesta aula, vamos nos ater ao Planejamento do Escopo do projeto. Antes de prosseguirmos com nossa aula sobre este importante aspecto da administrao de projetos, voc saberia definir Escopo? Veja abaixo um conceito bastante aceito e compare-o com sua resposta.

O planejamento do Escopo abrange os processos necessrios na definio e no controle do que est dentro e do que est fora do escopo. A descrio clara do que ser produzido essencial para o sucesso do projeto.

44

A equipe do projeto e os stakeholders devem ter o mesmo entendimento acerca do que ser produzido pelo projeto e que processos sero usados para produzi-lo. Nossa maior preocupao ao tratarmos do escopo, compreender, definir e controlar o que est ou no includo no projeto. Um Escopo bem definido auxilia a estimar com maior preciso a durao, o custo e os recursos envolvidos na execuo do projeto, e pode definir uma base para avaliao e controle do projeto bem como uma forma de distribuir o servio entre os membros da equipe. A correta definio e aprovao do escopo pelo Patrocinador e pelo cliente fornece as condies para se alcanar os objetivos do projeto e atender s expectativas dos envolvidos. O escopo definido na fase de planejamento poder mudar medida que o projeto avana. Para assegurar com que as mudanas sejam acompanhadas necessrio que a equipe estabelea um processo formal de aceitao e acompanhamento de mudanas do escopo. Este processo de definio assegura tambm com que o plano do projeto seja baseado em critrios acordados, mediante comprometimento por parte dos stakeholder, e tendo em vista a definio de critrios de desempenho.

7.1. O que Escopo do Projeto?


Sendo o primeiro passo do Planejamento do Projeto, esta fase identifica e documenta o trabalho que produzir o produto do trabalho. Para maior clareza de entendimento do Escopo do Projeto, o principal resultado desta fase ser a elaborao de dois documentos de grande importncia para a administrao do projeto: a Declarao de Escopo e a Estrutura Analtica de Projeto.

7.1.1. A Declarao de Escopo um documento usado para desenvolver e confirmar um entendimento comum do Escopo do projeto entre os envolvidos. Deve estar includo no seu prprio texto ou ento estar disponvel por referncia a outros documentos, contendo no mnimo os seguintes tpicos: A justificativa do projeto - a necessidade do negcio para a qual o projeto foi empreendido.

45

O Produto do Projeto - uma breve descrio do resultado esperado em relao ao projeto. Os Objetivos do Projeto - os critrios quantificveis que devem ser atingidos para que o projeto seja considerado bem sucedido. Os Produtos Intermedirios (Marcos) - uma lista dos principais produtos intermedirios cuja produo completa e satisfatria determina o trmino do projeto. As Restries - os limites do projeto expressos em termos de: custo, prazo, servios internos e terceirizados, e interfaces. As Premissas - so fatores que, para os propsitos de planejamento, so considerados: verdadeiros, reais ou certos. Alguns autores sugerem que alm destes dados, as seguintes informaes tambm faam parte da Declarao de Escopo: Equipe responsvel pela elaborao do Plano do projeto uma lista contendo informaes das pessoas envolvidas na preparao do plano. O registro do acompanhamento das mudanas de escopo algo que o gerente pode estar absolutamente certo de que haver mudanas no escopo durante a execuo do projeto. O gerenciamento do escopo compreende a aceitao e a incorporao das mudanas bem como a consequente atualizao do plano do projeto. Para desenvolver uma Declarao de Escopo coerente, com as expectativas do cliente, tente definir o que o projeto deve produzir. Pea para quem solicitou o projeto, expor com clareza o que espera obter com o produto do projeto. Convide a equipe a descrever o que o projeto deve produzir. Estimule a equipe tambm a ser criativa. No deixe que o modo habitual de fazer as coisas impea-o de ver alternativas diferentes. Faa propostas viveis, sem perder o senso de realidade. Ao escrever a Declarao, evite conceitos ambguos. Verifique se o Solicitante concorda com o Escopo definido. Solicite que ele assine a Declarao. Incentive ainda a equipe a questionar-se continuamente. Para que todos se comprometam a alcanar os resultados esperados, preciso que concordem com os rumos que sero seguidos! Este documento deve ser elaborado com consenso entre os principais envolvidos, e assinado por eles, antes da sua divulgao formal. A aprovao do Patrocinador e do Cliente indica que estes stakeholders aprovam o escopo e se comprometem com a sua realizao.

46

7.1.2. A Estrutura Analtica de Projeto Depois de completar a Declarao de Escopo, o prximo passo ser definir a abrangncia do trabalho a ser executado, decompondo o escopo em partes. Esta maneira de definir o volume de trabalho auxilia na preciso das estimativas de custo e prazo do projeto. Vamos usar uma forma simples de decompor o trabalho, criando uma estrutura chamada de Estrutura Analtica do Projeto. A Estrutura Analtica de Projeto EAP -, tambm chamada de Estrutura de Decomposio do Trabalho EDT -, uma ferramenta de definio do trabalho requerido para produzir os produtos de um projeto. Para produzir a EAP, vamos tomar como referncia o escopo estabelecido na Declarao de Escopo. A partir da, identificaremos blocos de trabalho, dividindo-os sucessivamente em partes cada vez menores at chegarmos ao nvel de atividade que se quer. Se nos orientarmos pelo ciclo de vida do projeto, teremos uma EAP orientada ao processo, e, se nos orientarmos pela construo do produto, teremos uma EAP orientada ao produto. A EAP define todo o trabalho e somente o trabalho necessrio para completar o projeto. O trabalho que no estiver contido na EAP est automaticamente fora do Escopo. De acordo com Cleland, o desenvolvimento da EAP fornece meios para: 1. Sumarizar todos os produtos e servios contidos no projeto, incluindo o suporte e outras tarefas; 2. Entender as inter-relaes dos blocos de trabalho entre si com o projeto total e com as demais atividades da organizao; 3. Estabelecer a autoridade/responsabilidade da organizao matricial; 4. Calcular o custo do projeto; 5. Conduzir anlise de risco; 6. Planejar blocos de trabalho; 7. Desenvolver informaes para a gerncia do projeto; 8. Providenciar uma base para controle da aplicao de recursos; 9. Estabelecer pontos de referncia para fazer com que as pessoas se comprometam em apoiar o projeto.

47

7.1.3. Princpios bsicos para construir uma EAP a. Um bloco de trabalho s deve aparecer em um nico lugar da EAP. b. O trabalho contido num item da EAP representa a soma do trabalho dos itens que esto abaixo dele. c. Cada item da EAP s tem um responsvel, embora outras pessoas possam participar de sua execuo. d. A EAP deve ser consistente com a forma como o trabalho est sendo realizado. Ele deve primeiramente ser til para a equipe do projeto. e. Os membros da equipe devem estar envolvidos no desenvolvimento da EAP para garantir consistncia e comprometimento. f. Cada item da EAP deve ser documentado para assegurar com que haja entendimento do que est dentro e fora de cada item. g. A EAP deve ser uma ferramenta flexvel para acomodar mudanas inevitveis e garantir o controle do trabalho executado em conformidade com a Declarao de Escopo.

7.1.4. Atualizaes da Estrutura Analtica de Projeto A EAP deve ser atualizada sempre quando houver mudanas substanciais o escopo do projeto. Os documentos atualizados precisam ser distribudos a todos os envolvidos.

7.1.5. Como representar a EAP Graficamente, a EAP representada por uma estrutura hierrquica (como um organograma), mas pode assumir a forma de uma lista. Veremos estas duas formas a seguir. A EAP tambm construda antes da identificao das dependncias entre as atividades, e da estimativa de durao, constituindo-se na fundao para o planejamento do projeto. A partir dela, outros documentos de planejamento e controle sero construdos.

48

7.1.6. Atualizaes da Estrutura Analtica de Projeto A EAP deve ser atualizada sempre quando houver mudanas substanciais no escopo do projeto. Os documentos atualizados precisam ser distribudos a todos os envolvidos.

7.1.7. Como representar a EAP Graficamente, a EAP representada por uma estrutura hierrquica (como um organograma), mas pode assumir a forma de uma lista. Veremos estas duas formas a seguir. A EAP tambm construda antes da identificao das dependncias entre as atividades, e da estimativa de durao, constituindo-se na fundao para o planejamento do projeto. A partir dela, outros documentos de planejamento e controle sero construdos.

49

7.1.8. Estrutura na forma de Lista A mesma estrutura pode ser representada em forma de lista, na qual os blocos de trabalho so organizados de maneira sequencial pela ordem que devem acontecer no projeto. Conforme mostrado abaixo, temos:

1. Iniciao 1.1. Seleo da equipe 1.2. Organizao e governana 1.3. Definio da metodologia 1.4. Definio do processo de controle 2. Planejamento 2.1. Definio dos objetivos 2.2. Identificao do Sponsor e Stakeholders 2.3. Desenvolvimento da EAP 2.4. Desenvolvimento do cronograma 2.5. Desenvolvimento do plano de pessoal 2.6. Desenvolvimento plano de comunicaes 2.7. Desenvolvimento plano da qualidade 2.8. Desenvolvimento plano dos riscos 2.9. Preparao dos documentos para avaliao 3. Execuo 3.1. Determinao dos requisitos 3.2. Especificaes de projeto 3.3. Construo do sistema

50

3.4. Preparao da documentao 3.5. Desenvolvimento do plano de testes 3.6. Execuo do plano de testes 4. Implementao 4.1. Desenvolvimento do plano de transio 4.2. Desenvolvimento do plano de treinamento 4.3. Desenvolvimento do plano de suporte 4.4. Implementao do plano de transio 4.5. Ajustes no sistema 5. Operao e Suporte 5.1. Desenvolvimento do plano de suporte operacional 5.2. Implementao do plano de suporte operacional

Sntese: Com esta aula, iniciamos a fase de planejamento do projeto. Vimos a importncia de se planejar os limites do projeto, e definir com clareza o seu Escopo por meio da Declarao de Escopo. Vimos tambm como este Escopo deve ser desmembrado em partes menores e mais fceis de gerenciar por intermdio da Estrutura Analtica de Projeto, cuja caracterstica bsica dividir sucessivamente o escopo do projeto em blocos de trabalho, at chegar a um nvel no qual se possa atribuir responsabilidades pela execuo, a fim de dimensionar o prazo e o custo do projeto. A emisso destes dois documentos caracteriza, portanto, o trmino da fase de planejamento do escopo.

51

8.

Determinao do Cronograma

O captulo anterior, vimos como construir uma estrutura analtica de projeto EAP -, para melhor identificar as principais atividades que devem ser realizadas a fim de se obter o produto do projeto. Lembre-se de que para obter a EAP, relacionamos todas as atividades necessrias para atingir aos objetivos do projeto, e as dividimos em grupos para facilitar o entendimento e a indicao de quem deve realizar cada atividade. A seguir, montamos uma figura, em forma de organograma, representando os grupos de atividades. Depois de identificar a estrutura, construmos com ela uma lista, abrangendo os grupos de atividades identificados. Pois bem, para estimarmos o prazo do projeto, vamos trabalhar com esta figura e com a lista de atividades.

8.1.

Processo de definio das atividades

O processo de definio de atividades envolve identificar e documentar as atividades especficas que devem ser realizadas de maneira a se obter os produtos e subprodutos identificados na EAP. Rena a equipe do projeto e conduza uma sesso de tempestade de ideias (brainstorming). Talvez, voc tenha que convidar outras pessoas que possam contribuir com conhecimento e experincia para que a lista seja a mais completa. Consulte pessoas e documentos de outros projetos similares e traga o que conseguir para a discusso. Monte a EAP e construa a lista de atividades. O produto deste estgio alm da forma grfica uma lista de atividades a serem realizadas para o alcance dos objetivos do projeto. Esta lista ser utilizada no seguinte estgio: Sequenciamento das Atividades. A lista dever conter todas as principais atividades e uma descrio de cada uma delas, de modo que os integrantes da equipe entendam o trabalho que deva ser realizado.

52

8.2.

Como preparar a lista

8.3.

Identifique as omisses

Verifique, com a equipe, se a lista toda contempla o trabalho necessrio para concluir o projeto. Lembre-se de que um esquecimento neste estgio pode ter srias implicaes em suas estimativas de prazo, custo e recursos necessrios. Examine a lista, item por item, e pergunte: Falta alguma atividade entre as que foram listadas? Se todas forem concludas, o projeto ser terminado? Foram listadas somente as atividades realmente necessrias? Depois de responder s questes e certificar-se de que a lista est completa, atribua identificao para cada uma delas. Um exemplo de fcil entendimento a troca do piso da sala de estar:

Dados: Comprimento: 5 m Largura: 4 m As atividades necessrias so:

53

Atividade 01 02 03 04 05 06 07 08 09 10 11 Clculo da rea e da quantidade de materiais Definio das caractersticas do novo piso. Aquisio do piso e materiais necessrios. Contratao dos operrios. Recebimento do piso e dos materiais. Retirada do piso antigo. Nivelamento do piso. Assentamento do novo piso. Acabamento. Limpeza. Disponibilizao para uso.

Durao (dias) 1 2 1 3 1 3 2 3 1 1

8.4.

Estrutura Analtica do Projeto

Com a lista acima, preparamos a EAP do projeto, conforme mostramos abaixo:

8.4.1. Atualizaes da Estrutura Analtica de Projeto A EAP deve ser atualizada sempre quando houver mudanas substanciais no escopo do projeto. Os documentos atualizados precisam ser distribudos a todos os envolvidos.

8.4.2. Como representar a EAP Graficamente, a EAP representada por uma estrutura hierrquica (como um organograma), mas pode assumir a forma de uma lista. Veremos estas duas formas a seguir.

54

8.4.3. Sequenciamento das Atividades Agora que j identificamos as atividades, sabemos que elas no podem, todas, iniciar-se ao mesmo tempo. Ento, necessrio organiz-las numa sequncia lgica, identificando e documentando as relaes de precedncias existentes entre elas. As atividades devem ser sequenciadas cuidadosamente de forma a permitir, mais tarde, o desenvolvimento de um cronograma realista e factvel. Decida quais delas devem iniciar imediatamente e quais precisam ser terminadas para que outras comecem. Neste estgio, a equipe precisar desenvolver um esquema grfico (diagrama de rede) em forma de rede que representa, de forma lgica, as ligaes dos grupos de trabalho entre si, e das atividades dentro dos grupos de trabalho, ou seja, que evidencie quais delas devem ser concludas antes do que outras comecem. Este diagrama pode ser simples ou complexo, dependendo da natureza do projeto e de quantas atividades ele comporte.

8.4.4. Atualizao da Lista de Atividades Ao construir o diagrama de rede do projeto, voc poder descobrir que alguns itens foram esquecidos, principalmente quando se elaborar a lista de atividades ou se achar que um determinado item precisa ser decomposto para melhor entendimento do trabalho a ser realizado. Se este for o caso, crie novos itens e decomponha os itens previamente listados. No esquea de atualizar a lista de atividades com base nesta nova situao.

55

9.

Mtodos para elaborar o diagrama de rede

Diversas tcnicas foram desenvolvidas para o sequenciamento de atividades, por exemplo: MDP Mtodo do Diagrama de Precedncias MDS Mtodo de Diagrama de Setas MDC Mtodo de Diagramas Condicionais

9.1.

Mtodo do diagrama de precedncias (MDP)

Este mtodo para construir o diagrama de rede do projeto usa vrios ns com o objetivo de representar as atividades, e setas que as liguem, mostrando as suas dependncias. A figura abaixo mostra um diagrama de rede de um projeto simples, produzido com a tcnica MDP. Esta tcnica tambm chamada de Atividade nos Ns e o mtodo utilizado pela maioria dos softwares de gerenciamento de projetos.

9.1.2. Ligao das atividades Neste mtodo, as atividades podem ser ligadas entre si, a partir de diversas formas: fim /incio (a atividade precedente deve ser concluda para iniciar a subsequente); incio / incio (as atividades ligadas devem iniciar simultaneamente); fim / fim (as atividades devem ser concludas simultaneamente), incio / fim (a atividade subsequente na lista deve ser concluda antes do incio da precedente).

56

Ao se desenvolver o cronograma, as restries devem ser observadas e podem ser de vrias naturezas, por exemplo: data mais cedo, no concluir antes de, no concluir depois de, concluir em, deve iniciar em, no iniciar antes de, etc. Na maior parte das atividades, a restrio estabelecida para se concluir o mais cedo possvel. Ao construir a rede, procure identificar claramente estas formas de relacionamento, lembrando-se de que a relao fim/incio a dependncia usada com mais frequncia.

9.2.

Mtodo de Diagrama de Setas

Este mtodo para construir o diagrama de rede do projeto usa setas para representar as atividades e ns para mostrar as dependncias. A figura abaixo mostra um diagrama de rede de um projeto simples, produzido com a tcnica MDS. Esta tcnica tambm chamada de atividade na seta, e, embora menos utilizada que a MDP, ainda encontra alguma aplicabilidade. A MDS usa apenas ligaes fim / incio para mostrar as dependncias, e, em alguns casos requer, a criao de atividades fantasmas para definir corretamente as relaes lgicas entre elas.

9.3.

Mtodos de Diagramas Condicionais

Estas tcnicas so utilizadas para a representao de atividades no sequenciais como laos (loops) (Por exemplo: um teste que precisa ser realizado diversas vezes), ou como ramos condicionais (Por exemplo: a atualizao de um sistema necessria somente se os testes identificarem problemas). Estas atividades no podem ser representadas por MDP nem por MDS.

57

O diagrama de rede do projeto Troca do Piso -, considerando as relaes de precedncia entre as atividades, e utilizando a tcnica MDP, pode ser representado da seguinte forma:

9.4.

Estimativa de durao das Atividades

A estimativa de durao das atividades envolve a avaliao do nmero de perodos de trabalho necessrio para completar cada atividade estabelecida no diagrama de rede do projeto. Normalmente, a realizao desta tarefa cabe pessoa, ou grupo de pessoas da equipe, mais experimentados com a natureza do projeto a ser conduzido. Consideraes acerca do nmero de perodos de trabalho devem levar em conta as horas trabalhadas por dia e, tambm, os feriados e fins de semana no transcorrer do projeto. A maioria dos softwares de gerenciamento trabalha automaticamente com estas variveis. A durao geral do projeto tambm pode ser estimada com esta ferramenta, mas mais apropriadamente obtida como resultado do desenvolvimento do cronograma.

58

Estimativas precisas neste estgio so muito importantes para o projeto, pois eventuais erros podem comprometer seriamente o sucesso do projeto. Para evitar erros, solicite pessoa que vai realizar a atividade que ela estime a sua durao. Em alguns casos, voc ter que solicitar o auxlio de especialista para estimar com preciso as duraes das atividades. Tomando o diagrama de rede do projeto Troca do Piso -, vamos estimar as duraes como se segue e assinalar as respectivas duraes em cada atividade:

9.5.

Desenvolvimento do Cronograma

Desenvolver um cronograma significa determinar as datas de incio e fim para as atividades do projeto. Datas no realistas conduzem a problemas com o cronograma, e podem comprometer todo o esforo no projeto. Use o diagrama de rede para definir as datas de incio e fim de cada atividade. Comece da primeira, e siga para as demais, iniciando cada item o mais cedo possvel. As mais conhecidas tcnicas de desenvolvimento de cronograma so: a-) MCC Mtodo do Caminho Crtico Neste mtodo, as datas de incio e trmino das atividades so calculadas de forma determinstica, baseando-se na rede do projeto, uma vez que as dadas so criadas no estgio de Sequenciamento das Atividades e nas duraes estimadas. O Mtodo do Caminho Crtico foca-se no clculo das folgas, procurando identificar as atividades que tenham a menor flexibilidade de prazo.

59

b-) TGRA Tcnica Grfica de Reviso e Avaliao (Graphical Evaluation and Review Technique - GERT) Esta tcnica permite o tratamento probabilstico da rede lgica e das estimativas de durao das atividades (isto , algumas atividades no sero realizadas, porm outras sero concludas em parte, sendo que outras ainda sero realizadas mais de uma vez). c-) PERT Programm Evaluation and Review Technique (Tcnicas de Reviso e Avaliao de programas) Esta tcnica usa a rede lgica do projeto e mdias ponderadas de durao das atividades visando calcular a durao do projeto. As diferenas mais importantes entre as tcnicas de PERT e de CPM que: a primeira usa a distribuio de probabilidades para estimar as duraes (valor esperado), e sua aplicao maior se efetua quando o grau de incerteza para a durao das atividades muito alto; enquanto que a segunda usa valores determinados, e se aplica primordialmente em projetos com baixo grau de incerteza nas duraes. Para estimar o valor esperado de atividades com alto grau de incerteza, vamos fazer conjeturas acerca do tempo de durao de cada atividade. Neste sentido, estimamos um valor otimista que a durao, caso tudo venha a ocorrer conforme planejado; um valor pessimista, se ocorrerem desvios do planejado e um valor mais provvel, situado em algum ponto entre estes dois valores. O tempo esperado calculado supondo que os valores seguem uma distribuio de frequncia beta conforme a frmula: Valor esperado = (Op + 4 Mp + Pe)/6, onde: Op = Otimista Mp = Mais provvel Pe = Pessimista O valor esperado o valor mdio que divide a rea abaixo da distribuio de frequncia em duas partes. Na tcnica PERT, o tempo esperado calculado para cada atividade, e estes valores so usados para determinar o caminho crtico.

9.6.

Definio do Cronograma

Todo projeto precisa de um cronograma, pois ele fundamental para: o planejamento, controle e acompanhamento.

60

O grfico de Gantt uma tcnica que mostra por meio de um grfico de barras: as atividades, aes e o tempo despendido (gasto) no projeto. Ele tambm representado por meio de duas partes. A primeira uma matriz que apresenta no eixo vertical todas as atividades a serem realizadas. Cada linha contm uma nica identificao que normalmente consiste em nmero e nome. O eixo horizontal dividido em colunas que indicam a durao estimada da atividade. Estas duraes so representadas pelas colunas horizontais, sendo uma coluna para cada perodo de tempo. Os perodos so expressos nas unidades de tempo do projeto que podem ser: meses, semanas, dias, horas e outras unidades, dependendo da durao total do projeto. A parte grfica consiste de uma linha horizontal para cada atividade, ligando as colunas do perodo de incio com as de trmino. Cada atividade representada em uma linha independente, e o tempo esperado representado por uma barra cuja extremidade esquerda mostra o incio, e a extremidade direita a data esperada de concluso. As atividades podem ocorrer sequencialmente, em paralelo ou sobrepostas. Em muitos casos, deixa-se uma linha em branco entre as atividades. Durante a execuo do projeto, esta linha usada para mostrar o progresso, representada por outra barra que se inicia na coluna de incio real da atividade, e que continua at que ela esteja completa. Com o progresso do projeto, o grfico atualizado, preenchendo-se a barra deixada em branco proporcionalmente ao trabalho executado para cada atividade. A comparao das duraes estimada e realizada indica o status do projeto, por atividade. Desta forma, obtemos uma leitura rpida do progresso, desenhando-se uma linha horizontal na data atual. Atividades j completadas ficam esquerda da linha. Atividades sendo realizadas so cortadas pela linha. Se a extremidade preenchida da barra estiver esquerda da linha, a atividade est atrasada. Se estiver a direita, est adiantada. Atividades futuras ficam inteiramente direita da linha. Para o nosso exemplo de troca do piso, tomando o diagrama de rede com as duraes estimadas, obtemos o seguinte grfico de Gantt.

61

Sntese Tudo que fizemos nesta aula foi visando obter um cronograma que represente com clareza o prazo necessrio para concluirmos o projeto. H um axioma no mundo dos negcios de que tempo dinheiro. Portanto, planejar eventos futuros e organiz-los numa seqncia lgica de forma que sejam realizados com o mnimo de tempo extremamente importante para o sucesso do empreendimento. Para obter um cronograma execute os seguintes passos: 1.Defina o projeto e as suas atividades importantes. 2.Determine a relao de precedncia entre as atividades. 3.Estime a durao necessria para completar cada atividade. 4.Desenhe uma rede conectando todas as atividades, e indique as duraes estimadas. 5.Calcule o caminho de mxima durao (caminho crtico) na rede. 6.Use a rede para planejar, elaborar cronograma e controlar o projeto.

62

10. Determinao do Oramento


Administrar custos em projetos requer uma abordagem disciplinada quanto s estimativas e quanto ao controle dos custos. O processo de gerenciamento realiza-se nas fases iniciais quando a equipe determina o custo total mais provvel do empreendimento e, consequentemente, gera um oramento mestre. Este documento identifica todos os recursos envolvidos na realizao das atividades do projeto, suas quantidades e seus respectivos custos individuais. Durante a execuo do projeto as variaes de custo, ou seja, as diferenas entre o previsto e o realizado devem ser controladas, pois afetam todo o desempenho do projeto. Mudanas no escopo ou na durao das atividades tambm tm influncia sobre o custo. Ineficincia ou baixa produtividade so outros fatores que podem afetar de forma negativa a previso e o controle dos custos. A administrao do custo do projeto engloba os processos necessrios para assegurar com que o projeto ser concludo dentro do oramento aprovado.

10.1. Processos da administrao de custos do projeto


De acordo com a publicao PMBOK, os estgios necessrios para a correta administrao dos custos do projeto so: Planejamento dos Recursos determina quais recursos (pessoas, equipamentos, materiais) e que quantidade de cada um deve ser usada para executar as atividades do projeto. Estimativa dos Custos desenvolve uma estimativa dos custos dos recursos necessrios implementao das atividades do projeto. Oramentao dos Custos alocar as estimativas de custos globais aos itens individuais de trabalho. Controle dos Custos controlar as mudanas no oramento do projeto. Em alguns projetos, especialmente nos menores, o planejamento dos recursos, a estimativa dos custos e a sua oramentao esto to unidos que podem ser vistos como um nico processo (por exemplo, podem ser realizados por um nico indivduo durante um certo intervalo de tempo). Estes processos so aqui apresentados como processos distintos porque as ferramentas e tcnicas so diferentes para cada um deles.

63

A seguir, tratemos ento individualmente de cada um destes processos.

10.1.1. Planejamento dos Recursos O planejamento dos recursos envolve determinar quais recursos fsicos (pessoas, equipamentos e materiais) e quais quantidades de cada um devem ser usadas para a realizao das atividades do projeto. Estes elementos devem estar firmemente sincronizados com a estimativa dos custos dos projetos.

a)

O que podemos usar par Planejar os Recursos

Cronograma do projeto (descrito na aula 05). Identifica as atividades do projeto e suas respectivas duraes e, consequentemente, contm as principais informaes para o planejamento de recursos. Informaes de projetos anteriores. Para identificar os recursos necessrios a equipe do projeto pode utilizar informaes de projetos similares. Declarao do escopo. A declarao do escopo contm a justificativa da necessidade do projeto e a descrio do produto esperado, alm dos objetivos do projeto, e deve ser considerada tambm para o planejamento dos recursos. Quadro potencial de recursos. O conhecimento de quais recursos (pessoas, equipamentos, materiais, etc.) esto potencialmente disponveis para o projeto til ao planejamento dos recursos. Polticas organizacionais. As polticas gerais da empresa, relativas tanto ao quadro de pessoal quanto ao aluguel ou compra de suprimentos e equipamentos, bem como qualidade, segurana e meio ambiente, devem ser consideradas durante o planejamento dos recursos.

b)

Ferramentas e Tcnicas para o Planejamento dos Recursos

Avaliao de especialista. A avaliao especializada poder ser requerida para auxiliar na identificao dos recursos necessrios. Tal conhecimento especfico pode ser fornecido por qualquer grupo ou indivduo com conhecimento ou treinamento especializado. Como exemplo de fornecedores deste servio pode-se citar: Setores especializados da empresa.

64

Consultores. Profissionais e associaes tcnicas.

c)

Resultados do Planejamento dos Recursos

Recursos necessrios. Deve ser elaborada uma lista contendo os tipos de recursos requeridos e a quantidade para cada atividade detalhada no cronograma.

10.2. Estimativa dos Custos


A estimativa de custo do projeto consiste basicamente na identificao dos custos unitrios, na dimenso de consumo dos recursos e no clculo dos custos, primeiramente em cada atividade e, depois, pela totalizao da soma dos custos das atividades obtendo o oramento do projeto. A estimativa dos custos inclui identificar e considerar vrias alternativas de custo. Por exemplo: na maioria das reas de aplicao, considera-se amplamente que o trabalho adicional durante a fase de projeto (design) tem o potencial de reduo do custo na fase de produo. O processo de estimativa dos custos deve considerar, por exemplo, se o custo do trabalho adicional na fase de projeto ir compensar a economia esperada. Os custos do projeto podem ser classificados em custos diretos e indiretos. Custos diretos so despesas que podem ser alocadas diretamente ao projeto e mantm uma relao de proporcionalidade com a quantidade de servio executado ou com materiais e servios recebidos. Custos indiretos so despesas calculadas como um percentual do custo direto e so geralmente relacionadas a recursos no diretamente consumidos pelo projeto.

10.2.1. Exemplos de custos diretos Custos de pessoal so as despesas com salrios das pessoas responsveis por executar as atividades do projeto. Estes custos incluem os salrios dos coordenadores e supervisores. Custo de materiais so os materiais que sero consumidos nas atividades do projeto e que compem outra natureza de custo a ser considerada.

65

Custo dos equipamentos trata-se dos equipamentos adquiridos para executar as atividades previstas no projeto e que devem ser lanados como custos diretos, mesmo que sejam alienados ao trmino do projeto. Custos de servios se houverem partes do projeto executadas por terceiros estas despesas compem tambm o custo direto do projeto. Custos de viagens alguns custos como despesas de viagem e estadia que ocorrem em funo do projeto so classificados como custos diretos e compem o oramento.

10.2.2. Exemplos de custos indiretos Benefcios so os benefcios pagos ao pessoal alocado para o projeto, sendo classificados como custos indiretos. Custos administrativos so despesas referentes administrao geral da empresa e que so rateados pelos diversos projetos que esto sendo conduzidos. Custos gerais so despesas gerais com: telefone, energia eltrica, manuteno, e outros gastos que so divididos entre os diversos setores da empresa.

10.2.3. O que usar para Estimar Custos O cronograma, como descrito na aula 05, ser usado para organizar a estimativa dos custos e assegurar com que todo o trabalho identificado seja estimado. Lista de Recursos necessrios. So os recursos descritos no pargrafo anterior. Custo unitrio de recursos. Voc dever buscar informaes como: custo horrio de pessoal, custo de material, custo de equipamentos, etc. Se estas informaes no estiverem disponveis, voc poder estim-las. Estimativas de durao das atividades. A estimativa da durao das atividades afetar as estimativas dos custos de qualquer projeto no qual o oramento inclua subsdios para os custos de: Registros de outros projetos. Procure informaes dos custos nos arquivos de projetos anteriores ou com o pessoal da equipe. Plano de Contas. O plano de contas descreve a estrutura de codificao utilizada pela organizao para reportar as informaes financeiras ao seu sistema geral de contabilidade. As estimativas do custo do projeto devem ser alocadas na categoria contbil correta.

66

10.2.3. Tcnicas para a Estimativa dos Custos Algumas tcnicas so utilizadas para facilitar o trabalho da equipe na determinao dos custos do projeto. Dentre elas trs, so mais conhecidas as seguintes: Estimativa por analogia - Neste tipo de estimativa, tambm chamada de estimativa topdown, vamos usar os custos reais de projetos anteriores, desde que eles sejam similares, como base para a estimativa do custo do projeto atual. uma tcnica geralmente usada na estimativa dos custos totais do projeto quando existir uma quantidade limitada de informaes detalhadas sobre o projeto (por exemplo, nas fases iniciais). A estimativa por analogia normalmente envolve menor volume de trabalho do que as outras, mas o seu grau de preciso tambm normalmente menor. So mais confiveis quando os projetos anteriores so semelhantes de fato, e no apenas na aparncia de pessoas ou ainda grupos que estejam preparando as estimativas, e que possuem grande experincia no assunto. Estimativa por parmetros - Neste modelo, utiliza-se caractersticas do projeto (parmetros) em modelos matemticos para prever os custos do projeto. Os modelos podem ser simples (as construes residenciais custaro um certo valor por unidade de rea construda) ou complexos (um modelo de custos de desenvolvimento de software usa 13 fatores de ajuste com 5 a 7 pontos a serem analisados em cada deles). Tanto o custo quanto a preciso do modelo paramtrico variam amplamente. Sero provavelmente mais realistas quando: (a) as informaes histricas utilizadas no desenvolvimento forem precisas; (b) os parmetros usados no modelo forem prontamente quantificveis; e (c) o modelo for escalonvel (por exemplo, quando ele funcionar bem tanto para grandes projetos quanto para projetos menores). (PMBOK 2000) Estimativas por atividade (Bottom-up) - Esta tcnica envolve estimar os custos das atividades do cronograma, depois som-los para obter a estimativa total do projeto. O custo e a preciso das estimativas dependem do volume de trabalho envolvido em cada atividade. Quanto maior o nvel de detalhe das atividades mais precisa ser a estimativa, porm o custo de estimar tambm ser mais alto. Ferramentas computadorizadas - As ferramentas computadorizadas, tais como: softwares de gesto de projetos e planilhas eletrnicas so amplamente utilizados como apoio estimativa dos custos. Tais produtos podem simplificar o uso das ferramentas descritas acima e, portanto, agilizar as consideraes de muitas alternativas de custo.

67

10.2.4. Resultados da Estimativa dos Custos Custos estimados - O oramento estimado do projeto normalmente apresentado na forma de planilha na qual so listadas as atividades e seus respectivos custos expressos em unidades monetrias. Em alguns casos, outras unidades como, por exemplo, homem/hora podem ser utilizados para expressar o custo das atividades. Detalhes de suporte - Frequentemente a equipe guarda os documentos do processo de estimativa de custos para facilitar o entendimento de como foram desenvolvidas. A quantidade e o tipo destes documentos variam de projeto para projeto. Plano de gerncia do custo. O plano de gerncia do custo descreve como os desvios no custo sero gerenciados. O plano de gerenciamento de custo pode ser formal ou informal, muito detalhado ou bastante amplo e baseado nas necessidades das partes envolvidas do projeto.

10.3. Oramentao dos Custos


A oramentao o processo de sumarizar todos os custos num nico documento denominado oramento mestre do projeto.

10.3.1. O que usamos para compor o oramento mestre Estimativas de custo - como j descritas acima. A EAP (descrita na aula 04). Identifica os elementos do projeto para os quais o custo ser alocado. O cronograma do projeto. O cronograma do projeto inclui as datas planejadas de incio e de trmino das atividades do projeto no qual haver consumo de recursos e, portanto, custos iro ocorrer. Esta informao necessria para que se aloque adequadamente os custos para o perodo de tempo em que ele for realmente acontecer.

10.3.2. Tcnicas para a Oramentao Tcnicas para a estimativa de custo. As ferramentas e tcnicas descritas para o desenvolvimento da estimativa do custo so tambm usadas para o desenvolvimento do oramento.

68

10.3.3. Resultados da Oramentao Oramento mestre (cronograma fsico financeiro) - o oramento de referncia (custos alocados no tempo) que ser utilizado para medir e monitorar o desempenho do custo do projeto. desenvolvido a partir da totalizao das estimativas de custo por perodo.

10.4. Controle dos Custos


Para controlar os custos, o administrador e a equipe devem acompanhar as despesas realizadas. No caso de serem identificados desvios do custo programado, a equipe deve tentar influenciar nos fatores que causam as mudanas para se ajustar as atividades, adequadamente, a fim de retornar os custos ao oramento original. Neste trabalho, a equipe ir: Monitorar o desempenho do custo para detectar as variaes do plano; Assegurar com que todas as mudanas adequadas estejam registradas corretamente no cronograma mestre; Impedir que mudanas incorretas no apropriadas ou no autorizadas sejam includas no cronograma mestre; Informar adequadamente aos interessados (stakeholders) as mudanas autorizadas; O controle de custo inclui descobrir o motivo de desvios para mais ou para menos do custo programado. Este processo est fortemente integrado com os outros processos de controle (o controle de mudana de escopo, o controle do cronograma, o controle da qualidade, entre outros). Por exemplo, uma resposta no apropriada para variaes do custo pode causar problemas de qualidade ou de cronograma, ou ainda produzir, mais adiante no projeto, um nvel de risco inaceitvel.

10.4.1. O que usar para o Controle dos Custos Oramento mestre - conforme descrito no item acima. Relatrios de desempenho - Os relatrios de desempenho do projeto fornecem informaes acerca do desempenho do custo e indicam se os custos planejados esto sendo alcanados ou no. Ao indicar a tendncia dos custos, os relatrios podem apontar para situaes de risco que podem se tornar problemas mais tarde.

69

Solicitaes de mudana - As solicitaes de mudana podem ocorrer de muitas formas oral ou escrita, direta ou indiretamente, iniciada externa ou internamente, e legalmente imposta ou opcional. As mudanas podem requerer um aumento no oramento ou permitir com que ele seja reduzido. Plano de gerncia do custo - O plano de gerncia do custo descreve como as variaes no custo sero gerenciadas (por exemplo, respostas diferentes para problemas menores ou maiores).

10.4.2. Ferramentas e Tcnicas para o Controle dos Custos Sistema de controle de mudana do custo - O sistema de controle de mudana do custo define os procedimentos pelos quais o oramento mestre pode ser alterado. Inclui manuais, sistemas de acompanhamento e os nveis de aprovao necessrios para autorizar mudanas. O sistema de controle de mudanas do custo deve estar integrado com o sistema do controle geral de mudanas do projeto. Medidas de desempenho - As tcnicas de medida de desempenho auxiliam na avaliao da magnitude dos desvios ocorridos. Uma tcnica bastante usada a anlise do valor ganho (earned value). Uma parte importante do controle de custo determinar as causas de variao no custo e tomar medidas corretivas para se ajustar o custo aos valores estabelecidos a fim de evitar com que as causas tornem a ocorrer. Replanejamento - Poucos projetos progridem exatamente como o planejado. Mudanas de grande porte podem exigir estimativas completamente novas ou revises do custo ou, ainda, exigir anlise de alternativas. Ferramentas computadorizadas Atualmente no se pode conceber o acompanhamento e o controle do custo dos projetos sem o uso de uma ferramenta informatizada, tais como: softwares de gerenciamento de projeto e planilhas eletrnicas. Estes aplicativos so frequentemente utilizados para comparar o custo planejado com o custo realizado e para identificar os efeitos das mudanas do custo.

10.4.3. Resultados do Controle dos Custos Revises nas estimativas de custo - As estimativas de custo revisadas so modificaes nas informaes de custo utilizadas para gerenciar o projeto. Caso seja necessrio, o administrador e a equipe informam aos stakeholders das mudanas efetuadas no custo planejado. O custo estimado revisado pode ou no requerer ajustes em outros aspectos do plano geral do projeto.

70

Atualizaes do oramento - As atualizaes do oramento so uma categoria especial de revises nas estimativas de custo, pois tratam das mudanas no cronograma mestre aprovado. Estes nmeros so geralmente revisados apenas em resposta a grandes mudanas no escopo. Em alguns casos, as variaes de custo podem ser to severas que seja necessrio um re-planejamento completo com a finalidade de fornecer uma avaliao realstica em relao ao desempenho atual do projeto. Aes corretivas. Uma ao corretiva qualquer ao tomada no sentido de ajustar o desempenho futuro esperado com o plano do projeto. Estimativa na concluso (Estimate at Completion) - A estimativa na concluso (EAC) uma previso do custo na concluso, baseada no desempenho do projeto at o momento. As tcnicas mais comuns de previso da estimativa do custo na concluso so: EAC = custo real at a data, mais o oramento restante do projeto modificado por um fator de desempenho, freqentemente o ndice de desempenho de custo. Esta abordagem usada com mais freqncia quando as variaes correntes so vistas como tpicas para variaes futuras. EAC = custo real at a data, mais uma nova estimativa para todo o trabalho restante. Esta abordagem usada com mais frequncia quando o desempenho passado mostra que as premissas da estimativa original estavam bastante imperfeitas, ou que no so mais to relevantes, devido a mudanas nas condies. EAC = custo real at a data, mais o oramento restante. Esta abordagem usada com mais frequncia quando as variaes correntes so vistas como atpicas, sendo que a expectativa da equipe de gerncia do projeto de que variaes semelhantes no se repetiro no futuro. As abordagens acima podero ser utilizadas ou no, dependendo de qual das atividades do projeto estejam sendo avaliadas.

10.5. Lies aprendidas


As causas das variaes, as razes por trs das aes corretivas tomadas, e outros tipos de lies aprendidas durante o controle do custo, devem ser documentadas de forma a tornarem-se parte da base de dados histricos a ser utilizada tanto no projeto corrente como em outros projetos da empresa.

71

Sntese: Como administrador do projeto, voc ter certas responsabilidades por assegurar com que ele possa ser concludo dentro do oramento aprovado. O processo de gerenciamento do custo do projeto inicia com a descrio do produto desejado do projeto (Escopo), se estendendo para a definio das atividades necessrias visando o alcance dos objetivos a partir da elaborao da Estrutura Analtica do Projeto (EAP). A definio da sequncia das atividades e a estimativa de durao de cada uma delas nos fornece o cronograma mestre. Com este documento, analisamos as necessidades de recursos de vrias naturezas, bem como estimamos os respectivos custos para cada atividade. Por ltimo, sumarizamos ainda os custos individuais das atividades, por meio de um documento denominado oramento mestre, o qual contempla todas as estimativas de custo previstas para realizar as atividades. medida que o projeto avana, a equipe do projeto acompanha o desempenho dos custos; e toma aes corretivas, caso necessrio, mantendo sempre informados todos os interessados, de acordo com um plano previamente estabelecido. O que fizemos nesta aula foi justamente apresentar os processos necessrios para se obter um oramento que represente com clareza o custo necessrio para concluirmos um projeto. Alm disso, discorrermos a respeito dos processos necessrios para completar um projeto dentro do oramento aprovado, incluindo o planejamento dos seus recursos, a estimativa de custos, a oramentao, a monitorao e o controle dos custos.

72

11. Elaborao do Plano de Gerenciamento da Qualidade

Para que um projeto seja considerado bem sucedido, dever haver uma correspondncia entre o seu Escopo, Custo, Prazo e o nvel de confiana nos seus produtos, ou seja, na sua qualidade. A qualidade faz parte do trio de restries encontradas em todos os projetos. uma das vias para se chegar a um projeto bem-sucedido e, normalmente, determina se as expectativas dos stakeholders foram atendidas. Por exemplo, um projeto pode ser concludo rapidamente com investimento mnimo em gerenciamento da qualidade, contudo o nvel de confiana no que ele produziu pode ter sido afetado, significativamente. O processo de Planejamento da Qualidade visa ao cumprimento de padres de qualidade relevantes para o projeto em questo, elaborando, para tanto, um plano. O plano de Gerenciamento da Qualidade especifica como a poltica de qualidade ser implementada pela equipe do projeto no decorrer das atividades. Perceba que todo o contedo discutido nesta aula ser usado para ajudar a desenvolver o plano de gerenciamento da qualidade aplicada ao desenvolvimento de projetos.

11.1. Conceito de Qualidade


O guia PMBOK conceitua Qualidade como: a totalidade de caractersticas de uma entidade que a torna capaz de satisfazer necessidades declaradas ou implcitas. Em outras palavras, para se ter qualidade, o produto ou servio dever atender aos seguintes critrios: - Adequao ao uso (o produto ou servio poder ser usado?); - Adequao ao propsito (o produto ou servio atende aos objetivos propostos?); - Satisfao do cliente (o produto ou servio atende as expectativas do cliente?); - Conformidade com as especificaes (o produto ou servio est de acordo com os requisitos estabelecidos?).

73

11.1.1. Princpios bsicos Os princpios definidos para o gerenciamento da qualidade do projeto so basicamente os seguintes: - Satisfao do cliente entender, gerenciar e influenciar necessidades de forma com que as expectativas do cliente sejam satisfeitas ou excedidas. Isto exige a combinao de conformidade com especificao (ou seja, o projeto deve produzir o que foi dito que produziria) e convenincia para o uso (o produto ou servio produzido deve satisfazer s necessidades reais). - Preveno ao invs de inspeo o custo destinado a evitar erros sempre muito menor que o custo para corrigi-los. - Responsabilidade do gerente o sucesso exige a participao de todos os membros da equipe, mas permanece a responsabilidade do gerente em fornecer os recursos necessrios para o xito.

11.2. Processo de Gerenciamento da qualidade em projetos


O gerenciamento da qualidade fornece os mtodos e ferramentas visando assegurar-se com que o projeto alcance seus objetivos de modo a satisfazer as necessidades para as quais ele foi empreendido. Este processo desempenha um papel importante no planejamento do projeto, e estabelece as principais funes do gerente, durante a fase de Execuo das atividades do projeto. Os objetivos do gerenciamento da qualidade, neste caso, so: - Aumentar o grau de confiabilidade nos produtos gerados pelo projeto; - Reduzir o risco de falhas; e - Aproveitar as oportunidades de melhoria contnua. O Gerenciamento da Qualidade deve incorporar tcnicas e ferramentas de controle de forma a garantir com que os produtos gerados apresentem as caractersticas para as quais foram concebidos. Esta parte do gerenciamento de projetos envolve tambm os processos para gerenciar mudanas, problemas e incidentes emergentes. O Gerenciamento da qualidade realizado a partir de trs estgios:

74

- Planejamento da qualidade; - Controle da Qualidade; e - Aes corretivas

11.3. Planejamento da qualidade


O objetivo desta atividade identificar quais padres de qualidade so relevantes para o projeto e a forma de satisfaz-los. Elaborar o Plano da Qualidade pode exigir ajustes no custo ou no cronograma para incorporar as atividades de preveno, alm de anlise detalhada de risco para problemas identificados pelo controle da qualidade. A elaborao do plano de gerenciamento da qualidade responsabilidade do gerente do projeto. Os principais passos na elaborao do plano so: - Definio das caractersticas e atributos dos produtos gerados pelo projeto; - Definio das normas, padres e procedimentos que sero usados para comparar as caractersticas esperadas dos produtos com as caractersticas efetivamente alcanadas durante a execuo projeto; - Seleo de pontos de controle das caractersticas e elaborao das checklists bem como dos critrios pelos quais os produtos gerados sero aceitos ou rejeitados; - Comunicao aos envolvidos no projeto acerca dos mecanismos que sero adotados para assegurar a qualidade. importante que os interessados sejam informados com relao forma como a qualidade ser alcanada. As habilidades e a experincia das pessoas que iro elaborar o plano da qualidade no projeto so fatores determinantes na efetividade deste processo. O plano da qualidade deve definir com clareza em que pontos as caractersticas dos produtos gerados pelo projeto sero medidas. Estes pontos so chamados de pontos de controle ou pontos de verificao. As fases do projeto devem ser estruturadas de forma a permitir com que as caractersticas dos produtos gerados sejam facilmente medidas e comparadas como o especificado.

75

11.3.1. Plano de Gerenciamento da Qualidade

O plano da qualidade estabelece as polticas, responsabilidades e procedimentos que sero usados para assegurar um adequado nvel de qualidade aos produtos ou servios que devem ser seguidos por todos os participantes no projeto. Este documento resume o sistema de decises e instrues com relao garantia e ao controle da qualidade. A elaborao do plano da qualidade baseada no entendimento das expectativas do cliente, esclarecidas nas fases iniciais do projeto. Na terminologia ISO 9000, o plano deve descrever o sistema de qualidade do projeto: a estrutura organizacional, responsabilidades, procedimentos, processos e os recursos necessrios para implementar a gerncia da qualidade. Alm da Garantia de Qualidade e do Controle da Qualidade, o plano de Gerenciamento da Qualidade aborda tambm os critrios de aceitao dos produtos gerados pelo projeto. A equipe do projeto e os principais stakeholders estabelecem, previamente, os critrios para definir o aceite de cada produto ou servio a ser entregue. No momento da entrega, os produtos ou servios so avaliados com relao a estes critrios antes que sejam formalmente aprovados. comum acordar que haja um documento para cada entrega principal, o qual necessite de aprovao e de um documento que defina os critrios da aceitao para o projeto como um todo. Os critrios de aceite variam de acordo com o que est sendo produzido. Ao criar um formulrio de aceite, a equipe deve prever uma coluna para cada critrio do aceite, uma coluna para expectativas do cliente, e uma outra para os resultados reais. Se a entrega atingir os critrios indicados, o cliente assina no campo apropriado, significando que ele aceita o produto e atesta conformidade com os requisitos. essencial que o gerente e a equipe do projeto entendam claramente os requisitos e expectativas do cliente (usurio) com relao qualidade do produto principal e dos produtos intermedirios do projeto, ao preparar ou revisar o plano da qualidade.

76

11.3.2. O que usamos para elaborar o plano

Poltica da qualidade: Uma declarao que descreve se a abordagem que a equipe do projeto ir adotar para garantir com que os produtos gerados pelo projeto esto em conformidade com as especificaes. A equipe poder adotar a poltica da qualidade da organizao que conduz o projeto, ou formular uma poltica prpria, caso no exista a poltica da empresa. Especificaes expectativas do cliente: A qualidade baseada na percepo do cliente sobre os produtos gerados e como eles atendem s suas expectativas. A adequao dos produtos do projeto aos objetivos para os quais foram criados fornecem o seu nvel de qualidade. A equipe do projeto dever identificar e documentar (se necessrio negociar) as expectativas (caractersticas, atributos) e assegurar com que a equipe e o cliente tenham entendimento comum sobre eles. Normas, padres e procedimentos: As normas e os procedimentos relevantes para o projeto devem ser identificados e documentados. Isto inclui todas as regulamentaes especificas da natureza do projeto em trabalho. Mecanismos devem ser colocados em prtica para assegurar com que as normas e procedimentos sejam completamente atendidos pelos produtos gerados a partir do projeto. Outros procedimentos internos da empresa: Procedimentos internos podem ser considerados importantes para o planejamento da qualidade do projeto. Exemplos destes procedimentos podem ser os processos relativos ao gerenciamento do risco ou ao suprimento.

11.4. Controle da qualidade


As atividades de controle da qualidade so realizadas continuamente durante a execuo do projeto, e em pontos definidos, para avaliar se o gerenciamento, e se os produtos ou servios entregues atendem aos critrios de aceite, estabelecidos na fase de planejamento, alm de identificar formas para eliminar causas de resultados insatisfatrios em decorrncia do projeto. O controle da qualidade , portanto, o processo contnuo de reviso e testes, realizado em pontos de controle pr-definidos onde o progresso e as caractersticas dos produtos gerados pelo projeto so examinados em detalhe.

77

O controle da qualidade adequadamente aplicado faz com que a equipe do projeto seja mais eficaz, uma vez que previne situaes nas quais o trabalho resulte em produtos que possam vir a ser rejeitados por no atenderem aos critrios estabelecidos. Neste caso, a equipe deve monitorar (medir) os resultados do projeto, e determinar se eles esto de acordo com os padres de qualidade estabelecidos, alm de identificar as formas para eliminar as causas de desempenhos insatisfatrios. Assim, a equipe identifica desvios e sugere aes corretivas para san-los. Os mtodos utilizados podem ser: - Teste dos produtos para determinar o nvel de conformidade com as especificaes; - Avaliao da satisfao dos stakeholders com os produtos do projeto; O patrocinador do projeto deve receber, regularmente, relatrios que resumam o andamento do controle da qualidade do projeto. Estes relatrios podem incluir dados estatsticos como, por exemplo, o nmero de no conformidades encontradas bem como aes corretivas tomadas.

11.5. Resultados do Controle da Qualidade


11.5.1. Decises de aceitao Os itens inspecionados sero aceitos ou rejeitados, sendo que os rejeitados podem exigir retrabalho.

11.5.2. Retrabalho uma ao tomada para adequar os itens com defeito, ou no conformidade, s exigncias ou especificaes do projeto.

11.5.3. Check-list concludas Uma checklist uma ferramenta estruturada, utilizada para verificar se um conjunto de passos necessrios est sendo efetuado.

78

Quando se utilizam checklists, aquelas j concludas devem fazer parte dos registros do projeto.

11.5.4. Ajustes no processo Envolvem a tomada de aes corretivas ou preventivas imediatas como um resultado das medidas de controle de qualidade. Em alguns casos, os ajustes no processo podem necessitar de compatibilizao com os procedimentos do controle geral das mudanas.

11.6. Ferramenta para o Controle da Qualidade


Brainstorming - Tambm conhecida como tempestade de ideias, uma atividade em grupo em que as pessoas apresentam suas ideias de maneira que possam ser caracterizadas como livres de obstculos, de crticas ou ainda de segundas intenes. Consiste em uma ferramenta bastante til, porque permite gerar rapidamente um grande nmero de ideias acerca dos principais problemas associados m qualidade do produto ou servio. Geralmente, uma sesso de Brainstorming conduzida em grupos de 5 a 10 pessoas, com participao voluntria. O prazo de realizao deve ser determinado e moderadores podem ser utilizados, desde que adequadamente treinados para lidar com pequenos grupos. Realiza-se tambm com o auxlio de flip-chart, no qual so anotadas as ideias sugeridas pelos seus componentes. importante ressaltar que a criatividade no inibida nestas sesses, ou seja, as ideias, por mais absurdas que possam parecer, em hiptese alguma, sofrem crticas dos outros membros. O propsito do Brainstorming criar uma lista de ideias originais, voltadas para um determinado tema, geradas em um ambiente sem inibies. Deste modo, busca-se a diversidade de opinies e ideias a partir de um processo de criatividade grupal. Esta tcnica uma poderosa ferramenta para socializao e desenvolvimento de equipes. O Brainstorming apresenta as seguintes caractersticas e premissas para o seu sucesso: - Capacidade de auto expresso, sendo livre de inibies ou preconceitos da prpria pessoa ou qualquer outro do grupo; - Criatividade; - Capacidade de aceitar e conviver com diferenas conceituais e multidisciplinares.

79

11.7. Aes corretivas

So as aes tomadas para tratar dos defeitos, no-conformidades e problemas identificados pelo processo de controle da qualidade. Aes corretivas podem incluir mudanas no plano do projeto, da qualidade, na metodologia empregada ou ainda nos procedimentos utilizados. O gerente do projeto deve coletar e analisar os resultados do processo de controle da qualidade, e outras informaes relevantes ao projeto. Esta anlise leva identificao de tendncias ou problemas, permitindo a imediata implementao de medidas corretivas no tempo adequado. As atividades de controle da qualidade iro identificar incidentes os quais sero analisados para verificar se: - So um fato isolado ou; - Mostram uma tendncia ou ainda um problema repetitivo. Em detrimento disto, aes realistas de correo devem ser tomadas pela equipe do projeto para resolver o problema. Se os custos para correo forem maiores que os benefcios, o gerente do projeto deve buscar solues alternativas (o que poderia ser, inclusive, no tomar nenhuma medida). Aes corretivas podem ser, por exemplo: - Retrabalho de um produto gerado; - Mudana de mtodos ou normas; - Mudana nos recursos do projeto; - Reavaliao da equipe do projeto (agregando pessoal mais experiente); - Mudanas no plano de gerenciamento da qualidade, incluindo revises mais freqentes dos produtos ou servios. - Mudana no plano do projeto; As aes corretivas devem prever mecanismos para evitar a recorrncia da no conformidade e assegurar com que o problema deixar de existir. J os passos para identificar e implementar aes corretivas so:

80

- Coletar e integrar as informaes das atividades do controle da qualidade; - Identificar e classificar os defeitos e no conformidades; - Analisar os dados e identificar casos isolados e tendncias; - Identificar aes corretivas realistas e selecionar a soluo mais efetiva; - Implementar a soluo e medir resultados; - Manter registros atualizados em relao ao andamento da ao corretiva; - Acompanhar e monitorar a efetividade da ao corretiva; - Incorporar nas lies aprendidas a partir do projeto.

11.8. Registros
A eficincia das aes corretivas depende dos registros do controle da qualidade. Registros completos e detalhados ajudam na escolha da melhor ao corretiva. Eles so importantes tambm para se verificar os resultados e a efetividade das aes depois de implementadas. E tambm so necessrios para demonstrar que os mecanismos de garantia da qualidade foram estabelecidos e esto sendo realizados conforme o planejado, por intermdio de um efetivo controle da qualidade. Os relatrios regulares de progresso do projeto devem incluir resumos das aes tomadas para resolver problemas identificados no controle da qualidade, a fim de demonstrar a eficcia da ao corretiva tomada, alm de garantir com que o problema no tornar a ocorrer. Os registros da qualidade podem estar disponveis em cpia fsica e/ou eletrnica e devem ser mantidos em ambiente que previna danos, deteriorao e extravios, sendo ainda legveis e prontamente recuperveis. Exemplos de registros da qualidade so os resultados de testes e ensaios, resultados de auditoria interna, dados de calibrao e anlises feitas no produto.

81

11.9. Custo da qualidade


Chama-se custo da qualidade o custo total de todos os esforos para alcanar a qualidade do produto ou servio. Ele inclui todo o trabalho necessrio para construir um produto que seja de acordo com as especificaes, bem como com o custo resultante das no conformidades com os requisitos. Custos normalmente associados qualidade: - Custo de fazer certo pela primeira vez; - Programas de treinamento; - Custos do controle estatstico do processo.

11.10. Custos da Conformidade


So os seguintes: - Planejamento da qualidade; - Treinamento; - Testes; - Validao do design; - Avaliao da equipe; - Auditorias da qualidade; - Manuteno e calibrao de instrumentos.

11.11. Custos da no Conformidade


So os seguintes: - Retrabalho de itens defeituosos; - Refugo;

82

- Material adicional; - Servios de reparo e garantia; - Tratamento de reclamaes; - Responsabilidades legais; - Recall de produtos; - Aes corretivas nos produtos; - Desperdcio de tempo e materiais; - Atrasos no cronograma; - Arranhes na imagem da empresa.

11.12. Principais categorias de custos da qualidade

11.12.1. Custos de Preveno: So os custos de todas as atividades exercidas com a finalidade de prevenir defeitos no projeto e desenvolvimento. Envolvem gastos com planejamento e administrao da qualidade, treinamentos de pessoal, relatrio sobre a qualidade, Engenharia de Controle da Qualidade, aquisio de dados da qualidade e controle de Processo.

11.12.2. Custo de Avaliao: So custos associados com as medies ou avaliao dos produtos, componentes internos e materiais adquiridos externamente, a fim de determinar se eles esto em conformidade com as especificaes ou so adequadas ao uso. Exemplos: Inspeo de Entrada, Inspeo de Processos, testes, materiais e servios consumidos.

83

11.12.3. Custos de Falhas Internas: So os custos associados aos itens que no esto em conformidade com as especificaes, ou no so adequadas ao uso, como os custos de anlise de falhas. Servem para identificar e corrigir defeitos antes que o cliente receba o produto. Exemplos: perda de rendimento, retrabalho, re-teste, anlise das falhas e disposio de produtos.

11.12.4. Custos de falhas externas: So os custos incorridos devidos a defeitos detectados pelo cliente. Inclui custos de garantia, de treinamento do pessoal de campo, tratamento de reclamaes, produtos devolvidos e perdas de negcios futuros.

11.12.5. Equipamentos de Medio e Testes: Representado pelos custos de capital do equipamento usado para efetuar as atividades de preveno e avaliao.

Sntese: Nesta aula, exploramos como a qualidade se relaciona com o gerenciamento do projeto, e vimos que o gerenciamento da qualidade um dos principais componentes de um projeto. Salientamos tambm que responsabilidade de todos os interessados apoiar e promover a qualidade dos produtos gerados pelo projeto. Percebemos que a gerncia da qualidade fornece as ferramentas para se assegurar de que o projeto se processa conforme o planejado. Ou seja, a qualidade desempenha um importante papel no planejamento e estabelece as principais funes do gerente durante a execuo do projeto. Sendo assim, a elaborao do plano da qualidade baseada no entendimento das expectativas do cliente, esclarecida nas fases iniciais do projeto. E deste modo, o produto ou servio dever atender aos seguintes critrios: 1. Adequao ao uso (o produto ou servio poder ser usado?). 2. Adequao ao propsito (o produto ou servio atende aos objetivos propostos?). 3. Satisfao do cliente (o produto ou servio atende s expectativas do cliente?).

84

4. Conformidade com as especificaes (o produto ou servio est em conformidade com os requisitos estabelecidos?). Por isso, o Gerenciamento da Qualidade deve incorporar tcnicas e ferramentas de controle de forma a garantir com que os resultados apresentem as caractersticas para as quais eles foram concebidos.

85

12. Gerenciamento do risco em projetos

O gerenciamento do risco atividade essencial e ocupa cada vez mais o tempo da agenda dos administradores de projetos. Esta atividade de gerenciamento trata, fundamentalmente, de se tomar as melhores decises em caso da ocorrncia de situaes indesejadas no projeto. A maioria das pessoas tem um entendimento intuitivo do que significa risco, e as definies podem variar de pessoa para pessoa. Da mesma forma, os autores que tratam do tema podem ter conceitos que diferem no modo de se conceber um projeto, mas, contudo, conservando a sua principal essncia.

12.1. Definio de risco em projetos


Podemos comear, definindo Risco como qualquer evento que tem potencial para afetar negativamente o projeto e dificultar a entrega dos produtos e servios contratados. Diferentemente, uma oportunidade um risco positivo uma vez que tem potencial para alavancar o projeto e melhorar seu desempenho. Deste conceito, conclumos que existem riscos positivos e riscos negativos. O administrador do projeto dever permanecer atento a todas estas situaes, tirando proveito das oportunidades e evitando ou reduzindo os efeitos dos riscos negativos. O Risco em projetos tem basicamente trs componentes: Um evento; A probabilidade de ocorrncia do evento; O impacto do evento.

12.2. Gerenciamento do Risco


O processo sistemtico de gerenciamento do risco fundamental para o sucesso do projeto, pois assegura com que todos os riscos identificados sejam documentados, analisados, e que respostas s exposies de risco sejam encontradas, de maneira consistente para alcanar os objetivos do projeto.

86

Este processo se refere a eventos futuros, cujas exatas consequncias so desconhecidas, e visam lidar com estas incertezas de maneira proativa. Exatamente por ser proativo em sua natureza, o gerenciamento do risco difere-se fundamentalmente do gerenciamento de crise ou de problema, o qual reativo e requer uso intensivo de recursos, normalmente restrito a um conjunto limitado de opes disponveis. Esta situao de escassez de alternativas se deve ao fato de que, tipicamente, as opes de soluo de problemas se reduzem, quando temos pouco tempo para resolv-las, o que justamente a situao enfrentada pelo administrador do projeto, quando ocorrem fatos indesejados. Os impactos negativos que estas opes de ltima hora causam no custo, no cronograma ou no desempenho, so maiores do que se elas fossem identificadas e tratadas com a devida antecedncia. A gesto do risco conduzida inicialmente como parte da anlise de viabilidade do projeto e documentada na proposta ou na anlise de custo/benefcio, pois nestes documentos esto definidos os objetivos do projeto. Esta anlise tambm conduzida durante todo o projeto para se assegurar com que as mudanas nas circunstncias sejam acompanhadas e controladas. Se voc souber com antecedncia quais so seus riscos em potencial, com frequncia conseguir mitig-los, ou at evit-los por completo.

12.2.1. O que usamos para elaborar o plano de gerenciamento dos riscos Eis os itens necessrios para se elaborar adequadamente um plano de gerenciamento de riscos: Project charter; Polticas de gerenciamento de riscos da organizao Algumas organizaes podem ter abordagens definidas para analisar e responder aos riscos que tm de ser customizados em detrimento de um projeto particular. Funes e responsabilidades definidas So funes e responsabilidades predefinidas com nveis de autoridade para a tomada de decises que influenciaro no planejamento. Tolerncia a riscos pelas partes envolvidas - Diferentes organizaes e diferentes indivduos tm diferentes tolerncias a risco. Isto pode ser expresso nas declaraes de polticas ou revelado em aes. Padres para planejamento do gerenciamento de risco da organizao. Algumas organizaes tm desenvolvido padres de uso para as equipes de projeto. Uma

87

organizao aprimorar continuamente o padro baseando-se na sua aplicao e utilidade no projeto.

12.2.2. Tcnica aplicada - Reunies de planejamento Equipes de projeto mantm reunies de planejamento para desenvolver o plano de gerncia do risco. Estas reunies podem fazer parte das reunies normais de acompanhamento do projeto ou serem especficas para tratar dos riscos, dependendo do grau de complexidade e dos problemas encontrados durante a execuo do projeto. Os participantes so, alm do gerente do projeto e integrantes da equipe, quaisquer pessoas que tenham contribuies para uma correta anlise e tomada de deciso em relao aos riscos do projeto.

12.2.3. Procedimento de gerenciamento de riscos O procedimento de gerenciamento dos riscos o documento que explica como os riscos sero identificados e tratados, bem como sero feitos o monitoramento e o controle durante o ciclo de vida do projeto. Este documento descrever: O processo que ser usado para identificar, analisar e controlar os riscos durante todo o ciclo de vida do projeto; Com que frequncia, os riscos sero revistos, o processo ser incorporado para a reviso, e quem estar envolvido; Quem ser responsvel em quais aspectos da gerncia de risco; Como o status do risco ser relatado e a quem.

88

12.2.3. Metodologia para a elaborao do Plano de Respostas aos Riscos

Vamos analisar individualmente cada um destes passos nas sees seguintes.

12.3. Identificao
O processo de Identificao dos Riscos visa identificar todos os riscos capazes de afetar o projeto, document-los com todas as suas caractersticas prprias. Trata-se, portanto, de um processo iterativo, que passa por constantes revises. Neste processo, voc pode envolver os integrantes da equipe do projeto, stakeholders, especialistas no assunto, clientes, e quem mais voc achar que poder ajuda-lo no processo. Na fase inicial, pode-se trabalhar apenas com a equipe do projeto, acrescentando depois outras pessoas para detalhar os riscos especficos. Eis uma lista parcial para voc comear a pensar com respeito s possibilidades de risco: Oramento Cronograma

89

Mudanas no escopo ou nas especificaes Mudana de integrante da equipe Falha na execuo de atividades Problemas tcnicos Problemas com pessoal Problemas com mquinas Problemas com fornecedores Problemas polticos Risco legal Risco ambiental A lista est longe de ser completa. Cabe a voc e equipe descobrir e documentar, por meio das ferramentas e tcnicas deste processo, todos os riscos possveis em detrimento do projeto.

12.3.1. O que usar na Identificao de Riscos O processo de identificao dos riscos usa diversos documentos, entre eles: Contrato (ou a Proposta); Informaes histricas.

12.3.2. Ferramentas e tcnicas de Identificao de Riscos Este processo pode utilizar ainda as seguintes ferramentas e tcnicas: Anlise da documentao; Coleta de dados; Listas de verificao;

90

Anlise de premissas; Tcnicas de diagramao. Procure informar-se a respeito destas tcnicas com base na literatura especializada no assunto.

12.4. Resultados da Identificao de Riscos


Todas estas tcnicas constituem maneiras de ajudar a identificar os riscos do projeto. Quanto mais eficiente for o seu trabalho de identificao de riscos na etapa de Planejamento, tanto melhor ser o seu plano de resposta a eles. Os resultados do processo de Identificao de Riscos compreendem uma lista de riscos e os respectivos gatilhos (sintomas).

12.4.1. Riscos Os riscos so todos os eventos potenciais e suas consequncias. Aps identific-los, vamos registr-los nos formulrios de registro de riscos, e armazen-los num banco de dados, ou em um sistema de monitoramento, a fim de organiz-los e acompanhar de perto sua situao. Relacione os riscos e atribua, a cada um, um nmero de acompanhamento, o que lhe permitir monitorar sua ocorrncia e as respostas implementadas.

12.4.2. Gatilhos Gatilhos so eventos que indicam que um determinado risco est prestes a ocorrer, e que est na hora de se iniciar as aes planejadas de resposta. Para no perder o momento de atuar, fique sempre atento aos sintomas que indicam a iminncia de ocorrncia do risco.

91

12.5. Passo 2 - Anlise Qualitativa de Riscos

A Anlise Qualitativa de Riscos visa identificao do impacto dos riscos, tendo em vista os objetivos do projeto e sua probabilidade de ocorrncia. Tambm classifica os riscos por prioridade, de acordo com os efeitos em relao aos objetivos do projeto. A Anlise Qualitativa de Riscos deve ser efetuada durante todo o projeto, e por ela que voc deve se pautar no desenvolvimento de um plano de resposta aos riscos. Com este tipo de anlise, possvel calcular a probabilidade de ocorrncia de um risco, avaliar suas consequncias e corrigir distores do plano do projeto.

12.5.1. O que usamos para a anlise qualitativa Neste processo podemos utilizar: Lista dos riscos identificados; Conhecimento do status do projeto; Tipo de projeto; Escalas de probabilidade e impacto. Voc j deve ter entendido o que significa lista de riscos identificados. Abordaremos brevemente outras entradas: Conhecimento do Status do projeto: Refere-se ao exame da fase do ciclo de vida em que o projeto se encontra. medida que avanamos, ocorrem mudanas e podem emergir novos riscos, ou riscos j identificados podem apresentar novas conseqncias. Tipo de projeto: Diz respeito complexidade do projeto, e se voc e sua equipe tm experincia em projetos desta natureza. Se voc estiver envolvido em um projeto semelhante em tamanho e escopo a outros, em que j trabalhou, ter uma idia melhor da probabilidade de ocorrncia dos eventos de risco e suas conseqncias. Entretanto, ao participar de um novo projeto de grande complexidade, ou ao utilizar uma tecnologia que no domina, voc dispor de menos informaes em relao probabilidade destes eventos. Portanto, este tipo de projeto implicar mais incertezas que aqueles de que j participou.

92

Escalas de probabilidade e impacto: Usadas para estabelecer e mensurar a probabilidade de riscos e o efeito destes sobre os objetivos do projeto. So predeterminadas pela empresa ou pela equipe do projeto, antes da realizao do processo de Anlise Qualitativa do Risco.

12.5.2. Anlise da probabilidade do risco As ferramentas e tcnicas da Anlise Qualitativa de Riscos visam descobrir a probabilidade de um evento de risco, e determinar seu impacto (ou conseqncias), caso venha a ocorrer. Este processo ir definir as prioridades dos riscos, identificando quais deles devem constar no Plano de Respostas aos Riscos. Todos os dados coletados acerca dos riscos e sua probabilidade devem ser os mais exatos possveis. Tambm importante coletar dados isentos, para evitar com que voc ignore inadvertidamente riscos de alta probabilidade, ou com consequncias graves. A finalidade deste processo calcular a probabilidade de um evento de risco e o seu impacto. A tcnica utilizada atribuir pontuao de probabilidade e impacto aos riscos.

12.5.3. Probabilidade e impacto do risco Esta tcnica atribui probabilidades aos eventos de risco identificados, e calcula seu efeito em relao aos objetivos do projeto. Estes mtodos de anlise de riscos nos permitem determinar quais riscos demandam o gerenciamento mais atento. Durante a Anlise Qualitativa de Riscos, basta atribuir ao risco um valor alto, mdio ou baixo. Estas atribuies incluem a probabilidade de ocorrncia do risco e a gravidade do impacto, isto se ele se concretizar. A prxima tcnica, a matriz de classificao por probabilidade e impacto, lida com esta questo de modo mais completo.

12.5.4. Matriz de classificao de riscos por probabilidade e impacto As matrizes de probabilidade e impacto (PI) atribuem uma classificao genrica a cada um dos riscos identificados no projeto, geralmente expressa como alta, mdia ou baixa. Os riscos elevados correspondem a uma situao vermelha, os mdios a uma situao amarela, e os baixos a uma situao verde. Este tipo de classificao denominado de escala ordinal, porque os valores so ordenados de forma descendente. (Na prtica, os valores ordinais tambm podem incluir uma classificao por posio, ou seja, os riscos podem ser enumerados na ordem: primeiro, segundo, terceiro e assim por diante).

93

A matriz de PI determinada a partir da multiplicao de dois valores: o valor da probabilidade do risco pelo valor de seu impacto (cada qual gerado na escala correspondente). A avaliao da probabilidade e impacto dos riscos costuma se dar por meio de tcnicas de opinio especializada e entrevistas. Alm disso, algumas das ferramentas e tcnicas indicadas no processo de Identificao de Riscos, tais como: o brainstorming, as entrevistas e a tcnica de Delphi, podem ser empregadas na determinao desses dois fatores. Veremos agora as escalas de probabilidade e impacto em maiores detalhes, juntando tudo em seguida numa discusso final dos valores da matriz de PI.

12.5.5. Escala de probabilidades Uma probabilidade a chance de um evento ocorrer. O exemplo clssico o de jogar uma moeda. H 50% de probabilidade de dar cara e 50% de probabilidade de dar coroa. Note-se que a probabilidade de ocorrncia do evento mais a probabilidade de sua no-ocorrncia sempre igual a 100%. No caso da moeda, se h 50% de chance de dar cara, as chances de no dar cara tm de ser tambm de 50%, de modo que os dois nmeros somem 100. As escalas de probabilidade so normalmente expressas como um nmero entre 0,0 ou seja, nenhuma probabilidade de ocorrncia do evento e 1,0 - ou seja, 100% de certeza de que o risco vai se concretizar. Por ser difcil avaliar a probabilidade de ocorrncia de um risco, buscamos opinio especializada de algum com muita experincia no assunto. Em outros termos, significa que procuramos adivinhar (ou pedimos que um especialista adivinhe) a probabilidade de ocorrncia de determinado evento de risco. Nosso palpite se baseia em experincias anteriores em projetos ou eventos de risco similares. O mais prudente usar toda a experincia da equipe e acreditar na intuio. Em projetos complexos, procuramos envolver o maior nmero possvel de especialistas cujas respostas devem ser cuidadosamente ponderadas, de modo a chegarmos s melhores escalas e valores de probabilidades possveis.

12.5.6. Escalas de impacto dos riscos gravidade do impacto do risco, chamada escala de impacto, atribuda um valor ordinal ou de escala cardinal. Os valores ou escalas cardinais so

94

12.5.7. Determinao dos valores da matriz de probabilidade e impacto A finalidade das matrizes de probabilidade e impacto (PI) atribuir a cada risco uma classificao genrica como alto, mdio ou baixo. Para tanto, multiplica-se a probabilidade pelo impacto do risco, como j dissemos. Voltando ao exemplo anterior, sua equipe identificou um evento de risco capaz de aumentar os custos do seu projeto. Calculando uma probabilidade de ocorrncia do evento de 0,2, temos 0,4 de impacto, caso o evento se concretize. Multiplicando um pelo outro, chegamos a um valor geral de risco de 0,08. A frmula a seguinte: Probabilidade de 0,4 x impacto de 0,2 = 0,08 de risco geral. Agora, temos de avaliar se 0,08 um nmero alto, mdio ou baixo. A Tabela 6.2 mostra um exemplo de matriz de PI cujos valores e classificao geral so determinados antes do comeo deste processo, em geral, pelo mesmo grupo de especialistas encarregados das escalas de probabilidade e impacto. Vejamos, primeiro, a coluna de probabilidades. Seu evento de risco tem uma probabilidade de 0,2. Agora, acompanhe a linha at chegar ao risco de 0,08. De acordo com os valores da sua matriz de PI, um valor de 0,08 para 0,2 de probabilidade fica dentro do limiar baixo, de modo que o risco classificado como baixo. Os valores atribudos aos riscos determinam como ser feito o Planejamento de Respostas, naturalmente, riscos com alta probabilidade e impacto elevado vo exigir novas anlises e respostas formais.

95

a-) sem formatao = valor baixo; b-) negrito = valor mdio; c-) itlico e negrito = valor alto.

12.5.8. Classificao dos riscos O objetivo da Anlise Qualitativa de Riscos classificar os riscos e determinar quais requerem uma anlise mais aprofundada e, posteriormente, planos de resposta a riscos. Como o prprio ttulo sugere, os riscos identificados e avaliados durante este processo so classificados por ordem de prioridade. Alm da pontuao obtida, podemos usar outros critrios como, por exemplo, o momento de ocorrncia do evento de risco ( preciso dar uma resposta imediata ao risco, ou no futuro?).

12.6. Passo 3 - Anlise Quantitativa


A Anlise Quantitativa de Riscos avalia os impactos e quantifica a exposio do projeto aos riscos por meio da atribuio de probabilidades numricas a cada um e aos seus impactos em relao aos objetivos do projeto. Para tanto, so usadas tcnicas como a Simulao de Monte Cario e a anlise de decises. As finalidades deste processo so as seguintes: Determinar a probabilidade de atingir os objetivos do projeto; Quantificar a exposio do projeto ao risco e determinar o tamanho das reservas de contingncia de custos e prazos;

96

Identificar riscos que requeiram maior ateno, quantificando sua contribuio para o risco geral do projeto; Determinar metas de cronograma, custos ou escopo realistas e viveis. Como a Anlise Qualitativa, a Anlise Quantitativa de Riscos verifica cada risco e seu possvel impacto sobre os objetivos do projeto. Voc pode usar estes dois processos para avaliar o risco ou apenas um deles, em funo da complexidade do projeto e da poltica organizacional relacionada ao planejamento de riscos. Caso utilize ambos, o qualitativo deve anteceder o quantitativo. Para realizar a anlise quantitativa, usamos os mesmos documentos da anlise qualitativa.

12.6.1. Tcnicas usadas na Anlise Quantitativa Estas so tambm as tcnicas empregadas na Anlise Quantitativa: Entrevistas Anlise de sensibilidade Anlise da rvore de decises Simulao Procure familiarizar-se com estas tcnicas na literatura especializada.

12.6.2. O que obtemos da anlise quantitativa Os resultados do processo da Anlise Quantitativa de Riscos so os seguintes: Listas dos riscos quantificados, ordenadas por prioridade: Neste processo, a lista ordenada por prioridades semelhante quela produzida durante o processo da Anlise Qualitativa de Riscos. A lista de riscos abrange aqueles que apresentam o risco mais alto para o projeto e seus impactos. Tambm lista os riscos com as maiores oportunidades para o projeto. Anlise probabilstica do projeto: A anlise probabilstica do projeto equivale aos resultados previstos no cronograma e aos custos do projeto em decorrncia das concluses da anlise de riscos. Estes resultados incluem as datas de trmino e os custos previstos, bem como o grau de certeza associado a cada um deles. Os graus de certeza descrevem o nvel de confiana no resultado. Por exemplo, supondo que a data de trmino prevista no

97

cronograma seja 12 de julho e o nvel de confiana seja 0,85, acreditamos que o projeto ser finalizado dentro deste prazo e que existem 85% de certeza de que esta data exata. Probabilidade de cumprimento dos objetivos de custo e tempo: As ferramentas e tcnicas da Anlise Quantitativa de Riscos tambm permitem atribuir uma probabilidade para o cumprimento dos objetivos de custos e tempo do projeto. Esta sada documenta tais probabilidades e, como tal, requer um entendimento aprofundado dos objetivos almejados e riscos do projeto atual. Tendncias dos resultados da Anlise Quantitativa de Riscos: provvel que as tendncias da Anlise Quantitativa de Riscos surjam medida que voc for repetindo os processos de anlise de riscos. Estas informaes mostram sua utilidade medida que o projeto avana, evidenciando os riscos mais ameaadores e criando a oportunidade de se efetuarem outras anlises, ou ainda de se iniciar o desenvolvimento de planos de respostas aos riscos.

12.7. Passo 4 - Planejamento de Respostas aos Riscos


O Planejamento de Respostas aos Riscos um processo que especifica as medidas a serem tomadas para reduzir ameaas, e tirar proveito das oportunidades encontradas nos processos de anlise de riscos. Este processo engloba ainda a designao de reas responsveis ou uma equipe para a execuo dos planos de respostas aos riscos. Quanto mais eficazes os planos de resposta aos riscos, maiores sero as chances de xito no projeto. Procure sempre elaborar planos de respostas para os riscos que combinarem alta probabilidade de ocorrncia com impacto significativo sobre o projeto. No eficiente desenvolver planos de resposta aos riscos de baixa gravidade ou impacto no-significativo. So usadas vrias estratgias neste processo para reduzir ou controlar o risco. importante escolher a estratgia certa para cada risco, de modo que o risco e seus impactos sejam tratados de forma eficaz. Aps determinar a estratgia a ser empregada, desenvolva um plano de ao para lev-la a cabo, se o evento de risco se concretizar. Estabelea tambm uma estratgia secundria ou de reserva. Este processo tem as seguintes entradas, em sua maioria j citadas ou bastante objetivas. So elas: Lista de riscos, em ordem de prioridade; Lista de respostas possveis; Sintomas de risco;

98

Donos dos riscos; Tendncias dos resultados nas anlises qualitativa e quantitativa dos riscos. As ferramentas e tcnicas deste processo abrangem as seguintes estratgias: Preveno; Transferncia; Mitigao; Aceitao. Vamos analisar cada uma destas ferramentas e tcnicas com mais detalhes.

12.8. Preveno
A preveno de riscos implica evit-los por completo, eliminando a causa dos eventos de risco ou modificando o plano do projeto de modo a resguardar seus objetivos contra tais eventos. Vamos supor que voc vai empreender uma viagem de carro de sua casa at um ponto turstico distante 200 km. O noticirio informa que existe um trecho em obras em uma das rodovias que voc pretende utilizar. Para evitar o risco de atrasos, voc muda seu plano e decide usar outra estrada, assim evita ficar retido no trecho em obras, e pode chegar ao destino na hora que deseja. Com a preveno contra o risco, voc praticamente elimina o risco por meio da eliminao de sua causa.

12.9. Transferncia
A transferncia do risco consiste em deslocar o risco e suas consequncias para terceiros. Ele no eliminado, mas voc se livra da responsabilidade pelo seu gerenciamento. A maioria das empresas prefere no assumir o risco alheio sem uma compensao financeira como medida de segurana. Como esta estratgia afeta o oramento, deve ser includa nos exerccios de estimativa de custos.

99

A transferncia do risco pode se dar de vrias formas, mas mais eficaz no caso de riscos financeiros. Este o caso dos seguros, por exemplo. As pessoas fazem seguros de automvel para que, o custo do reparo das avarias ou danos pessoais seja pago pela seguradora. Outro mtodo de transferncia do risco a terceirizao, que transfere riscos especficos para o fornecedor, dependendo do servio coberto pelo contrato. O fornecedor aceita a responsabilidade pelo custo da falha, pelo qual, mais uma vez, tem o seu preo: os contratados cobram por seus servios e, dependendo do tipo de contrato negociado, o custo pode ser bastante alto. Outras formas de transferncia abrangem as garantias, fianas e bonificaes por desempenho.

12.10. Mitigao
A mitigao do risco procura reduzir a probabilidade de ocorrncia e o impacto de um evento de risco para nveis aceitveis. uma estratgia muito parecida com a direo defensiva: ao avistar um obstculo na estrada, voc pensa nas suas opes e toma as medidas necessrias para contorna-lo, prosseguindo com segurana em sua jornada. Enxergar o obstculo (identificar o risco) permite reduzir a ameaa por meio do planejamento de alternativas de modo a evit-lo ou reduzir seu impacto, caso ele se concretize (estratgias de mitigao). A finalidade da mitigao diminuir a probabilidade de ocorrncia e o impacto do risco at um nvel que lhe permita absorver suas consequncias. mais fcil tomar providncias para reduzir a probabilidade de risco e suas consequncias do que consertar um estrago.

12.11. Aceitao
Aceitao significa que voc no vai criar nenhum plano para tentar evitar ou mitigar o risco, preferindo aceitar as suas consequncias. Esta deciso tomada porque a equipe no conseguiu elaborar nenhuma estratgia adequada de resposta ou porque os custos da ao de preveno so maiores que o dano causado pelo evento de risco.

100

12.12. Planejamento de contingncias


O planejamento de contingncias consiste na definio de um plano de ao para lidar com os eventos caso eles se concretizem. diferente da mitigao: esta visa reduo da probabilidade do risco e seu impacto, ao passo que o planejamento de contingncias no necessariamente procura reduzir estes fatores, mas reconhece a possibilidade de concretizao do risco e nos prepara para reagir a eles. A contingncia entra em jogo quando o evento de risco acontece, o que significa que os planos devem ser desenvolvidos e mantidos de prontido aps a identificao e quantificao dos riscos. As reservas ou provises para contingncias so uma opo usada com frequncia, e envolvem a manuteno de fundos para compensar eventuais ameaas que atinjam o escopo, cronograma, custo ou qualidade do projeto e no tenham como ser evitadas. A se inclui tambm a reserva de tempo e recursos para lidar com os riscos.

12.13. Resultados do Planejamento de Respostas aos Riscos


O Planejamento de Respostas aos Riscos tem vrias sadas: Plano de respostas aos riscos; Riscos residuais; Riscos secundrios; Acordos contratuais; Montante de reserva necessrio para contingncias; Entradas para reviso do plano do projeto. Os trs ltimos itens so bvios. Aps a elaborao destas respostas, pode ser preciso retornar a outros processos do Planejamento a fim de modificar os planos do projeto, como consequncia das reaes aos riscos. Examinaremos a seguir as trs primeiras sadas deste processo.

101

12.13.1. Plano de respostas aos riscos O plano de respostas aos riscos especifica as providncias a serem tomadas para cada evento de risco. Este plano, tambm conhecido como PRR deve incluir todos os riscos identificados, suas descries e a rea do projeto a sofrer o impacto. Seus detalhes tambm podem descrever as causas do risco, e como os objetivos do projeto sero afetados. Neste plano, so indicadas as reas da empresa ou os membros da equipe responsveis pelo gerenciamento dos riscos, assim como os detalhes das estratgias contra os riscos (aceitao, preveno, etc.). Todas as respostas devem especificar o tempo e o custo necessrios para sua implementao. Os planos de contingncia, reservas e planos de retirada tambm fazem parte do plano de respostas aos riscos.

12.13.2. Riscos residuais Risco residual , por assim dizer, um risco remanescente, aquele risco mnimo que ainda permanece aps a implementao de uma resposta a um risco, corno a mitigao, por exemplo. A reserva de contingncia existe para lidar com situaes desta natureza.

12.13.3. Riscos secundrios Riscos secundrios so aqueles que surgem em decorrncia da implementao de uma resposta ao risco. Ao fazer os seus planos contra riscos, identifique e planeje respostas tambm para os riscos secundrios que podem sobrevir.

Sntese:

Vimos que em todos os projetos, existem riscos, e o planejamento contra eles uma parte importante do processo de Planejamento do projeto. Ou seja, o simples ato de identificar os riscos e planejar respostas pode diminuir seu impacto, caso eles se confirmem. No adote, portanto, a abordagem do o que os olhos no vem, o corao no sente no planejamento contra riscos.

102

Este definitivamente um caso em que no ver pode acabar doendo mais. Riscos identificados com facilidade e com respostas planejadas de antemo, com certeza, no vo pr seus projetos nem sua carreira a perder. J aqueles que voc deveria ter detectado, mas ignorou, podem acabar custando uma fortuna organizao, provocando atrasos no cronograma ou at arruinando o projeto, alm de ainda poderem acarretar custos pessoais, j que no fcil explicar prazos e oramentos estourados no currculo de ningum. O gerenciamento do risco um componente essencial na conduo bem sucedida de um projeto. um processo que deve comear na concepo do projeto, e continua at que o projeto esteja terminado e seus benefcios previstos sejam alcanados. A gerncia de risco deve ser focalizada nas reas de risco mais alto com monitorao contnua de outras reas do projeto de modo a identificar novos riscos ou o aumento do grau dos riscos atuais. O sucesso na estratgia de uma gerncia de risco do projeto depende: Das habilidades e a experincia com que a equipe de projeto identifica e avalia riscos, e tambm durante o planejamento eficaz para se lidar com riscos; Do trabalho colaborativo da equipe de projeto e das reas de negcio para identificar e controlar riscos do negcio e do projeto; Do processo de gerncia de risco ocorrer continuamente durante todo o projeto; Do uso de uma metodologia apropriada da gerncia de risco; e De relatrios regulares de desempenho para o tratamento do risco, conforme o plano de gerenciamento realizado pela equipe do projeto, De processos independentes para a garantia de qualidade. a-) Passos principais para a identificao dos riscos do projeto: Analisar causa, probabilidade e consequncia de cada risco; Quantificar o impacto de cada risco; e Documentar o resultado da anlise de riscos. b-) Passos principais para o desenvolvimento e execuo do plano de resposta aos riscos: Identificar as alternativas de tratamento do risco;

103

Avaliar a eficcia de custo de cada tratamento; Documentar o plano de tratamento do risco. c-) Etapas principais na monitorao e atualizao do perfil de risco do projeto: Rever regularmente o perfil do risco; Monitorar a emergncia de novos riscos; Atualizar o plano de tratamento do risco; e Relatar todas as mudanas ao patrocinador do projeto e outros interessados.

104

13. Gerenciamento de Recursos Humanos em projetos

Durante este curso, j aprendemos a definir o escopo do projeto, bem como: elaborar o cronograma, o oramento e um plano para monitorar a qualidade dos produtos gerados pelo projeto. Sabemos tambm que as atividades no se realizam sozinhas, o que significa que algum ter que faz-las. Voc j deve ter ouvido dizer que o maior patrimnio de qualquer organizao so as pessoas que nela trabalham. Este conceito aplica-se integralmente aos projetos. Todo projeto necessita de pessoas para realizar as tarefas planejadas. O gerenciamento de pessoal tem como objetivo o uso efetivo de todos os recursos humanos alocados ao projeto, para haja o alcance de seus objetivos. Desta forma, ele envolve todos os interessados no projeto: patrocinador, cliente, integrantes da equipe, entre outros.

13.1. Habilidades comportamentais do Administrador do projeto


A natureza temporria dos trabalhos faz com que as relaes pessoais e organizacionais sejam tambm temporrias e novas. Devido a esta situao, o administrador do projeto dever aplicar tcnicas dinmicas de gerenciamento de recursos humanos para, ao mesmo tempo, lidar com os stakeholders assim como acompanhar o ambiente de contnua mudana mediante as condies do projeto. Para que os trabalhos sejam bem conduzidos, o administrador do projeto dever ter a habilidade de lidar com pessoas e possuir certas competncias indispensveis como: liderana, boa comunicao, negociao e administrao de conflitos, entre outras. Existe um volume substancial de literatura que trata destes aspectos da administrao. Procure familiarizar-se com as habilidades desejadas para que consiga lapidar sua competncia nesta rea, pois isto lhe tornar mais eficiente na funo de administrador de projetos.

105

13.2. Processos do Gerenciamento de Recursos Humanos


Os processos da administrao de recursos humanos no projeto podem ser resumidos de acordo com os seguintes estgios: Planejamento de pessoal; Montagem da equipe; Desenvolvimento da equipe. Vamos ver cada um destes estgios a seguir.

13.2.1. Planejamento de pessoal Neste estgio, o administrador identifica as necessidades de pessoal e documenta as funes, alm das responsabilidades de cada indivduo envolvido. Na maioria dos projetos, o planejamento de pessoal feito nas fases iniciais. Entretanto, ele deve ser revisto, em base regular, durante o desenvolvimento do projeto a fim de garantir com que a equipe esteja completa. Por exemplo, um projeto de construo civil pode envolver uma equipe com: engenheiro, arquiteto, mestre, carpinteiro, pedreiro, ajudante, etc. J um projeto de instalao de rede de telefonia pode exigir uma equipe com especialistas em hardware e software, alm de eletricistas, instaladores, entre outros. Portanto, a necessidade de pessoal est intimamente ligada natureza do servio a ser realizado no projeto. Para identificar com que pessoas voc dever contar para realizar as atividades do projeto, voc dever tomar o cronograma (ou a Estrutura Analtica do Projeto) j produzido anteriormente, e tentar responder s seguintes perguntas: Quantas pessoas sero necessrias para concluir as atividades; Qual a qualificao destas pessoas (em termos de conhecimentos, habilidades e atitudes); Qual o nvel de experincia que devem possuir; Em que rea da empresa elas atualmente esto;

106

Como convoc-las para formar a equipe do projeto. Depois de responder s questes acima, voc ter uma estimativa do pessoal necessrio, podendo iniciar as gestes adequadas para se conseguir com que estas pessoas venham a compor sua equipe. Esta estimativa dever estabelecer as funes no projeto (quem faz o que) e as responsabilidades (quem decide o que).

13.3. Montagem da equipe


Com a estimativa de pessoal obtida no estgio anterior, chegou a hora de buscar os integrantes da sua equipe. A montagem da equipe envolve conseguir com que os recursos humanos necessrios (indivduos ou grupos) sejam alocados ao projeto. Voc j sabe onde as pessoas esto (estgio anterior), portanto dever usar de habilidade pessoal (comunicao, negociao) para fazer com que elas venham para a sua equipe. Em alguns casos, voc poder no conseguir com que todos os recursos necessrios sejam indicados para compor a sua equipe, devendo lidar com lacunas na qualificao ou quantidade de pessoas. Desta forma, vital para o sucesso do seu projeto o fato de que voc defina um plano de treinamento a fim de eliminar as lacunas de conhecimento em relao aos integrantes do time. Num projeto, a competncia da equipe ir influenciar diretamente no seu sucesso ou fracasso. A partir desta noo, voc dever colocar todos os seus esforos para obter as melhores pessoas de forma a integrar sua equipe. Uma vez indicados os integrantes da equipe, procure verificar as seguintes condies com os responsveis pelos indicados: Experincia qual o grau de experincia do pessoal? J trabalharam em projetos similares? Como foi seu desempenho nestes projetos? Nvel de Interesse os membros indicados para o time tem interesse em trabalhar neste projeto? Comportamento - como os indicados iro trabalhar com os outros membros da equipe? Disponibilidade os membros estaro disponveis durante o perodo necessrio?

107

Conhecimento quais os conhecimentos dos indicados em relao ao projeto e as atividades a serem realizadas?

13.4. Limitaes para compor a equipe


Quando existem restries que se referem aos recursos humanos, voc ter de ser muito criativo para lidar com os fatores que limitam suas opes de forma a realizar as atividades do projeto.

13.4.1. Equipe pr-indicada Em alguns casos (muito frequentes), voc receber uma equipe indicada sem que tenha chance de escolher quem far parte do seu time. Esta situao pode se apresentar por diversas razes como, por exemplo: Indisponibilidade do pessoal; Importncia relativa do projeto em comparao com outros; Influncia do patrocinador; Complemento de formao para profissionais; Qualquer que seja a razo pela qual voc recebe uma equipe j indicada, no deixe de avaliar todos os itens acima e as expectativas que estas pessoas tem em relao ao trabalho no projeto. Lembre-se de sempre apontar os desvios entre as habilidades e quantidades necessrias delas para a obteno da equipe desejada. A formao de uma equipe aqum da necessria pode conduzir a mudanas no cronograma e no oramento para se adequar as atividades ao perfil de quem ir execut-las.

13.4.2. Recrutamento no mercado Em algumas circunstncias, voc ter de buscar recursos no mercado para completar os trabalhos do projeto. Vejamos algumas razes que levam a esta situao: Falta de pessoal qualificado na empresa;

108

O custo de terceirizar menor do que se realizar a partir da prpria equipe interna; Indisponibilidade do pessoal para este projeto.

13.4.3. Produto da Montagem da Equipe O projeto estar com o pessoal devidamente alocado, quando as pessoas tiverem sido realmente designadas para trabalhar nele. O pessoal pode ser designado em tempo integral, parcial, ou varivel, dependendo das necessidades do projeto.

13.4.4. Plano de Pessoal Vejamos alguns pontos importantes relacionados ao plano de pessoal: - Descreve a quantidade e a qualificao das pessoas necessrias para o projeto; - Mantm uma relao completa e precisa das habilidades do pessoal disponvel; - Trabalha com o setor de Recursos Humanos para obter o pessoal com habilidades adequadas.

13.5. Desenvolvimento da Equipe


O desenvolvimento da equipe envolve o aumento na capacidade dela funcionar como um time, melhorando o desempenho do projeto. Sem dvida, o funcionamento do grupo como equipe coesa crtico para que o projeto alcance seus objetivos. Neste sentido, o desenvolvimento da equipe pode se tornar complicado se os membros da equipe respondem tanto gerncia funcional quanto ao administrador do projeto. Portanto, voc dever saber usar de muita habilidade para contornar certas dificuldades de duplo reporte dos integrantes da equipe, sabendo tambm como proceder para comuniclas adequadamente, depois de validadas, aos gerentes das respectivas reas de trabalho envolvidos no projeto. Esta uma competncia fundamental para qualquer bom Administrador de Projetos.

109

Sntese

Nesta aula, vimos como os Recursos Humanos constituem o ativo mais importante de qualquer projeto, j que so tambm os elementos mais difceis de se administrar. Por maior que seja o grau de automao ou a tecnologia aplicada ao projeto, preciso dispor de pessoas capazes para tanto desenvolver quanto usar a tecnologia no sentido de operar adequadamente as ferramentas disponveis. Percebemos assim que planos, portanto, no se auto realizam, pois preciso gente para efetiv-los. Por isso, a Gesto de Recursos Humanos exige gerentes competentes, familiarizados com as principais metodologias, tcnicas e instrumentos de gesto e, simultaneamente, com a postura comportamental adequada aos desafios deste tempo, no qual a rpida mudana sempre uma constante. E, deste modo, planejar a organizao do projeto, obter os recursos mais adequados s suas necessidades, atribuir funes e responsabilidades bem como desenvolver tanto as habilidades e competncias individuais, assim como o esprito de equipe, so atribuies necessrios a um bom gerente de projetos. Finalmente, para se alcanar os objetivos almejados, o gerente deve saber como usar habilidades, tais como: negociao, administrao de conflitos, comunicao, e liderana.

110

14. Planejamento da Comunicao

O bordo de um apresentador de TV ficou muito conhecido em sua poca, pois dizia o seguinte: quem no se comunica se trumbica. Este raciocnio perfeitamente vlido tambm para o ambiente de projeto. O gerenciamento da comunicao uma das funes essenciais na administrao de projetos, a qual pode influenciar dramaticamente em seus resultados. Uma das principais atribuies do administrador de projetos manter informados os stakeholders (equipe, patrocinador, cliente, fornecedores, entre outros) em relao ao progresso do projeto, pois ao longo do projeto ser produzida uma grande quantidade de informaes, as quais informaro a respeito do seu andamento. A melhor forma de se manter informados todos os envolvidos com o projeto desenvolver um plano de comunicaes e implement-lo adequadamente. Para executar esta atividade, o administrador do projeto deve analisar as necessidades de informao de cada um dos envolvidos de modo que possa desenvolver um plano que informe o status e as previses relativas ao desempenho do projeto durante todo seu ciclo de vida. Desta forma, o gerenciamento da comunicao no projeto trata da gerao, coleta, formatao, armazenamento e distribuio da informao, de maneira que esta possa ser utilizada convenientemente por quem a receber. Neste processo, o tempo varivel muito importante. preciso ter em mente que os stakeholders devem receber informaes atualizadas para que possam decidir a partir delas. A comunicao mantm todos os envolvidos em circuito permanente, pois evita surpresas desagradveis e constri confiana no progresso e sucesso do projeto. Normalmente, as pessoas no reclamam por receberem muita informao, mas se ressentem de receber menos informao do que julgam necessrio. Por isso, o Plano de comunicaes vital para o sucesso do projeto. Nos projetos pequenos, o processo de comunicao simples e no requer muito esforo. A comunicao torna-se mais complexa medida que os projetos aumentam de tamanho e envolvem mais pessoas. Grandes projetos exigem planejamento antecipado, principalmente considerando as necessidades especficas de cada stakeholder.

111

Comunicar eficientemente significa fornecer a informao necessria (e nada mais) na hora certa, e no formato certo.

14.1. Pontos importantes a considerar:


Alguns pontos devem ser observados ao se elaborar um plano de comunicaes do projeto: 1 Mantenha a informao o mais simples possvel; 2 Identifique todos os stakeholders internos e externos; 3 Fornea a informao no momento em que necessria; 4 Saiba ouvir; 5 Planeje bem as apresentaes; 6 Elabore relatrios de progresso; 7 Evite impor barreiras; 8 Procure deixar acessveis as informaes essenciais: faa indexaes e utilize, na medida do possvel, arquivos on-line, atualizando-os regularmente.

14.2. Etapas do processo de Gerenciamento da Comunicao


Todos os envolvidos no projeto devem estar preparados para receber e enviar informaes de modo que entendam que a comunicao afeta o projeto como um todo. De acordo com o PMI, podemos desdobrar o processo de comunicao do projeto em quatro tpicos principais: Planejamento da comunicao - Analisa as necessidades de informao de cada stakeholder quando e como eles devem receb-la. Distribuio da informao - Processo pelo qual a informao fornecida no momento certo para o stakeholder que necessitar dela. Relatrios de desempenho Servem para coletar a informao de progresso do projeto e distribu-la de maneira que seja til.

112

Fechamento administrativo - Obtm e distribui a informao necessria para encerrar o projeto ou uma fase sua. Vamos descrever cada um destes tpicos a seguir.

14.3. Planejamento da Comunicao


Informao adequada significa menos discusses e conflitos. Desta forma, a preparao e implementao de um plano de comunicaes pode economizar tempo e energia durante todo o projeto. O Planejamento da comunicao envolve a definio das necessidades de informao para cada stakeholder do projeto bem como identifica quem ir fornec-la, de que forma e quando. O Plano de comunicaes , normalmente, um plano formal, elaborado nas fases iniciais do projeto e incorporado como uma seo do plano mestre, o qual permite com que o administrador estabelea meios de comunicar efetiva e eficiente para todos os envolvidos. Como todos os planos do projeto, este plano tambm necessita ser regularmente revisado, pois as necessidades de informao podem variar medida que o projeto avana. Estas mudanas devem se refletir no plano atualizado.

14.3.1. Como criar um plano de comunicaes a-) Identifique quem necessita de informao Como voc j sabe, com base no que vimos nas aulas anteriores, h vrios tipos de stakeholders: cliente, usurios, fornecedores, outros gerentes de projeto, etc. Primeiramente, procure identificar quais pessoas ou grupos de pessoas voc ir colocar no seu plano de comunicaes. b-) Identifique as necessidades de informao A comunicao no projeto pode assumir uma multiplicidade de formas e tipos. Verifique quais informaes precisam ser formalmente comunicadas, a sua linguagem adequada e a estrutura dos documentos. Tente categorizar por tipo e formato. Voc ir perceber que executivos necessitam de informao permanente, assim como membros da diretoria necessitam de relatrios de status e estratgia, sendo que os clientes podem ainda necessitar de determinado tipo de orientao, e os membros da equipe de orientao e estmulo. Especificamente em grandes projetos, a equipe dever ser criativa para

113

determinar como, o que, para quem, onde e qual a frequncia das comunicaes que devero ser feitas. c-) Identifique os meios para transmitir (Tecnologias de comunicao) Defina os mtodos usados para transmitir a informao entre os envolvidos. Estes mtodos podem variar, dependendo do ambiente e das necessidades dos stakeholders, desde uma conversa de corredor at reunies formais, indo de memorandos manuscritos a relatrios produzidos em bancos de dados digitais. Os fatores que podem afetar a tecnologia utilizada para as comunicaes do projeto dependem da velocidade com que as informaes importantes devem ser transmitidas, da disponibilidade de uso da tecnologia, e dos recursos para coletar, formatar e distribuir a informao do modo desejado. d-) Elabore o Plano de Gerenciamento das Comunicaes O plano de gerenciamento das comunicaes descreve os mtodos usados para gerar e coletar os dados, assim tambm como para criar formatos adequados recuperao de informaes, formas de acesso e meios para sua atualizao. Este tipo plano pode ser formal ou informal, muito detalhado ou bastante amplo, dependendo das necessidades do projeto. A princpio, um plano voltado ao gerenciamento de comunicaes deve ser um documento de fcil leitura, incorporado ao plano mestre do projeto e incluindo, no mnimo, o seguinte: Procedimentos para a coleta de informaes que detalhem quais mtodos sero usados para reunir e armazenar os vrios tipos de informao; Uma estrutura de distribuio que indique que informaes sero transmitidas (relatrios de Status, cronogramas, documentos tcnicos, etc) e quais os mtodos (e-mail, conferncias, relatrios escritos, atas de reunies, etc) que sero utilizados para distribuir os vrios tipos de informao; Uma descrio da estrutura para coleta e compartilhamento da informao; Uma descrio da forma de atualizao das informaes; Listas de distribuio, indicando quais informaes devem ser repassadas, a quem, por quem, quando e de que forma; Um cronograma das reunies ordinrias agendadas; Uma descrio de como as informaes sero atualizadas e como podem ser recuperadas.

114

14.3.2. Distribuio da informao O processo de distribuio da informao comea quando os stakeholders solicitam determinadas informaes, e o administrador do projeto se dispe a transmiti-las, de maneira efetiva. Paralelamente comunicao planejada, o administrador do projeto deve estar atento a solicitaes no esperadas, as quais costumam consumir muito de seu tempo. Os dados a serem divulgados no processo de distribuio das informaes so os seguintes: os resultados de todas as atividades realizadas, os produtos entregues, o nvel de qualidade alcanado, os custos incorridos, o plano do projeto e o plano das comunicaes, alm dos relatrios de performance. O plano do projeto fornece direcionamento adequado para a execuo das atividades, e composto pelos seguintes itens: o Termo de Referncia, o cronograma, o oramento, a anlise do risco, os nveis de responsabilidade, a indicao da equipe e os controles a serem executados. Por esta razo, ele um recurso para se guiar a distribuio da informao. Vemos como a habilidade de comunicao uma importante ferramenta para a disseminao clara e completa das informaes que atestam elementos do projeto de forma com que o receptor possa interpretar consistentemente todos os dados doravante apresentados.

14.3.4. Tipos de Comunicao A distribuio das informaes pode ser classificada a partir de trs principais tipos: verbal, eletrnica e impressa.

115

A informao pode ainda ser classificada como interna (presente na prpria equipe do projeto) e externa (direcionada a partir da equipe para outros stakeholders). Os sistemas de recuperao de dados so tambm ferramentas usadas para a disseminao da informao. A partir do uso de bancos de dados, acesso a redes de dados, softwares de gerenciamento de projeto e aplicativos, que permitem o acesso documentao tcnica (como plantas e desenhos de engenharia), as informaes podero ser adequadamente compartilhadas.

14.3.5. Registros do projeto O que se espera da distribuio da informao que os registros do projeto cheguem no tempo certo s pessoas que deles necessitam para tomarem decises acertadas. Para o sucesso do projeto, imperativo que estes registros sejam mantidos e organizados pelo administrador do projeto ou por algum por ele indicado. Desta forma, um sistema de controle da documentao deve ser implementado, revisado e monitorado a fim de garantir que continue a atender s necessidades vitais do projeto.

116

14.4. Relatrios de Desempenho


medida que o projeto avanar, voc dever coletar e disseminar informaes de desempenho para fornecer aos interessados as informaes relativas ao uso dos recursos alocados. Os relatrios podem ser de vrios tipos, como: Relatrios de Status - descrevem a posio atual do projeto; Relatrios de progresso - descrevem o que a equipe do projeto realizou at o momento; Previses em funo do obtido at agora, voc ir prever a futura situao e progresso do projeto. Os relatrios de desempenho organizam e sumarizam as informaes obtidas, bem como apresentam os resultados de anlises, fornecendo o nvel de detalhe em relao ao escopo, cronograma, custo, qualidade, risco e suprimentos, quando requeridos pelos vrios stakeholders, e conforme documentado no plano de gerenciamento da comunicao. preciso levar em considerao que determinadas situaes de desvios do desempenho desejado podem originar solicitaes de mudana as quais sero tratadas como descrito no processo de controle do projeto.

14.5. Encerramento Administrativo


Depois de realizar as atividades previstas e alcanar seus objetivos, ou ainda termin-las prematuramente, o projeto deve ser encerrado. O encerramento administrativo consiste em verificar e documentar os resultados do projeto para formalizar a aceitao do produto do projeto pelos patrocinadores, clientes, etc. Para realizar o encerramento administrativo, voc ir necessitar de toda documentao do projeto, vale dizer: o plano do projeto, especificaes, plantas, desenhos, registros de testes e ensaios. Este processo inclui a coleta dos registros do projeto para garantir que eles reflitam as especificaes finais, a anlise do sucesso e da efetividade do projeto, e o arquivamento destas informaes para uso futuro. No deixe para efetuar as atividades do encerramento administrativo, quando estiver no final do projeto. Encerre cada uma das fases e assegure com que as informaes teis e importantes sejam mantidas. Como produtos deste estgio, voc ir produzir pelo menos os seguintes documentos:

117

a-) Acervo do projeto - Um conjunto completo dos registros do projeto, preparado para arquivamento, pela equipe do projeto. Os bancos de dados pertinentes ao projeto devem ser atualizados. E os registros financeiros merecem uma ateno especial quando os projetos so feitos sob contrato ou quando envolvem um volume significativo de fornecimento de terceiros. b-) Aceitao formal - A documentao de que o cliente ou patrocinador aceitou o produto do projeto deve ser preparada e distribuda. c-) Lies aprendidas - As causas dos desvios, as razes das aes corretivas tomadas, e outros tipos de aprendizado prtico devem ser documentados, integrando um banco de dados histrico no s para o projeto em andamento, mas para os demais projetos da organizao executora.

Sntese

O gerenciamento da comunicao uma das funes que podem afetar dramaticamente o resultado do projeto. O gerente do projeto deve identificar os stakeholders e seus respectivos interesses no projeto, de modo a criar um sistema eficiente de comunicao que realize pelo menos duas funes principais: Coletar dados corretos; e Distribuir a informao adequada no tempo certo. Para realizar esta funo, a equipe se prope a identificar os interessados, desenvolver planos, escolher os meios, estabelecer o cronograma e gerenciar o fluxo de informao do projeto. O Plano de comunicaes deve determinar e atender s necessidades de comunicao dos stakeholders do projeto. imperativo que o plano de comunicaes do projeto defina: O pblico- alvo - Quem necessita da informao - o grupo de interessados (stakeholders) e seus interesses no projeto; A necessidade de informao - O que e quando cada stakeholder necessita receber; Ferramentas e formas de comunicao - Como a informao deve chegar e quais mtodos so mais apropriados para cada stakeholder;

118

Prioridades e responsabilidades quem ser responsvel por implementar as aes e quando isto ocorrer. A melhor abordagem desenvolver um plano abrangente que envolva a identificao de todos os interessados, suas necessidades de informao e a maneira de fornecer tais informaes da maneira mais correta no tempo propcio. Para serem eficientes, os relatrios do projeto devem ser concisos e fornecerem informao correta e precisa das atividades em andamento, bem como das variaes de performance e das aes corretivas tomadas, numa forma de fcil entendimento. Os processos principais de comunicao so: Planejamento da comunicao: i. Identificar e analisar os stakeholders; ii. Determinar as necessidades de informao dos stakeholders; iii. Determinar os elementos do plano de comunicao.

Distribuio das informaes: i. Criar um processo de obteno da informao; ii. Criar modelos para relatrios de status; iii. Criar um cronograma de distribuio; iv. Estimar os custos dos esforos de comunicao; v. Usar a tecnologia para compartilhar a informao.

Relatrios de performance: i. Identificar as mtricas adequadas; ii. Usar anlise de valor ganho; iii. Criar relatrios significativos.

119

Fechamento administrativo: i. Preparar elementos para o encerramento do projeto; ii. Conduzir as atividades de fechamento.

O uso de certas tecnologias como sistemas cliente/servidor e softwares de bancos de dados relacionais permitem um alto grau de flexibilidade no acesso, comunicao e formato dos relatrios de performance, alm disso, a informao pode ser inserida ou acessada eletronicamente, reduzindo erros e deixando a informao acessvel em tempo real. A correta informao em tempo certo faz com que stakeholders importantes sejam comunicados das informaes vitais e entendam o andamento do projeto e as mudanas necessrias. A comunicao frequentemente vista como a principal habilidade requerida para gerentes de projeto. Uma eficiente estratgia de comunicao contribui significativamente para o sucesso do projeto, pois est intimamente alinhada com as atividades de gerenciamento dos interessados (stakeholders).

120

15. Suprimentos e Contrataes

Agora que voc j elaborou todos os documentos para o seu plano do projeto, chegou a hora de escolher quem ir fornecer os insumos e os servios que o projeto necessita para alcanar seus objetivos. A aquisio de recursos externos atividade vital para a administrao do projeto, e suas estratgias de compra podem variar de acordo com as estratgias de compra da empresa em razo de restries especficas do projeto, bem como da disponibilidade de recursos crticos, alm claro, considerando ainda as exigncias do cliente. Bem, entender e esclarecer a combinao de responsabilidades do administrador do projeto e das atividades do pessoal de Compras, neste processo, pode impactar consideravelmente de modo a influenciar no resultado do projeto como um todo. O gerenciamento do suprimento trata dos processos necessrios para adquirir bens e servios de fornecedores externos empresa executora do projeto. Nesta aula, iremos nos referir a bens e servios como produtos. Com a presso que as empresas sofrem em compartilhar seus recursos escassos a fim de minimizar riscos cresce-se cada vez mais a importncia do processo de compra para os projetos. O projeto recebe insumos de reas internas e externas da empresa, porm esta ltima forma cria um vnculo legal entre o projeto e os fornecedores, e, portanto, as atividades realizadas por terceiros, ou ainda os produtos adquiridos devem ser muito bem definidos e especificados de modo a evitar posteriores disputas ou reclamaes que poderiam afetar no custo, prazo ou qualidade tcnica dos produtos gerados pelo projeto.

15.1. Processo de gerenciamento do suprimento

O processo de gerenciamento do suprimento pode ser dividido em 6 passos para um melhor entendimento, conforme apresentaremos a seguir. Uma atribuio-chave do administrador de projeto identificar e comprar produtos e servios, sendo que esta atividade se reveste de extrema importncia para se assegurar o sucesso do projeto.

121

Vamos tratar separadamente cada um destes estgios:

15.2. Planejamento do Suprimento


Neste estgio, a equipe reflete em relao aos documentos produzidos at esta fase em questo, e tambm efetua uma anlise conhecida como Fazer ou comprar (Make or Buy), na qual se identificam quais necessidades do projeto so mais bem atendidas a partir da procura de produtos ou servios no mercado, no considerando apenas a execuo com base no uso dos recursos internos da empresa. Para identificar adequadamente tudo que possa ser eventualmente necessrio, deve-se considerar tanto os custos diretos como os custos indiretos quando se produz internamente ou se compra no mercado, de modo a compar-los para se tomar a melhor deciso. Alm dos custos, a equipe deve considerar questes de capacidade, competncia e sigilo industrial. Para alguns produtos, o controle atividade crtica e no pode ser terceirizado. Outra situao que leva compra externa a indisponibilidade dos recursos da empresa no momento exato em que o projeto necessita deles, deixando o administrador sem outra opo que no a de obter tais recursos por meio de terceiros. Uma vez identificados os produtos que sero adquiridos no mercado, consideram-se os aspectos do que deve ser procurado, ou seja: o que procurar, como procurar, onde procurar, quanto procurar e quando procurar.

122

Em algumas situaes ou em projetos mais complexos, necessrio obter auxlio de especialistas para procur-los bem como se torna imprescindvel a contratao de profissionais para que tomem a deciso mais adequada de produzir tais recursos internamente ou ainda para compr-los fora dos domnios da organizao. Se ns quisermos ter alguma influncia no controle dos subcontratados, poderemos indicar potenciais fornecedores de tais contratados para suprir o projeto. O escopo do projeto (desenvolvido na aula 04), a descrio do produto, bem como os planos at agora desenvolvidos (Oramento, Cronograma, Recursos de Pessoal, Riscos, Qualidade, Comunicao), alm das condies do mercado, constituem a base de anlise para se planejar o que ser comprado. Uma vez identificados os itens de compra passamos para o estgio seguinte: a Preparao das aquisies. Alm dos documentos citados acima, a equipe pode ainda utilizar determinadas ferramentas a fim de identificar os produtos e servios a serem comprados a partir de terceiros, seguindo os passos que descreveremos a partir de agora.

15.2.4. Anlise do que fazer ou comprar Nesta anlise, a equipe define se um determinado produto (necessrio para o projeto) pode ser produzido com efetividade de custo pela empresa. Para realizar esta atividade, toma-se o cronograma e os planos auxiliares j produzidos, e busca-se separar as atividades que seriam mais bem realizadas, bem como os recursos internos da empresa daquelas que seriam econmica ou tecnicamente vantajosas de serem compradas de terceiros. Esta anlise leva em considerao o status do projeto, os custos do produto comprado e os custos da administrao da compra.

15.2.5. Avaliao de especialista

Dependendo da complexidade do projeto, pode-se necessitar de uma avaliao especializada para definir o que pode ser comprado de terceiros. Neste caso, iremos procurar dentro ou fora da empresa pessoas ou organizaes que possam fornecer a expertise exigida.

123

15.2.6. Escolha do tipo de contrato Existem diferentes tipos de contratos que podem ser utilizados para diferentes tipos de compras. Os contratos geralmente se enquadram em uma das trs categorias abrangentes: (a-) Preo global ou contratos de preo fixo: Esta categoria de contratos envolve um preo total fixo para um produto bem definido. Existem riscos para o comprador e para o fornecedor caso o produto no estiver bem definido, pois o comprador pode receber um produto com especificaes diferentes das contratadas e o vendedor pode incorrer em custos adicionais para produzir o produto. Os contratos de preo global podem tambm incluir incentivos quando se consegue atingir ou exceder determinados marcos do projeto tais como metas de prazos, por exemplo. (b-) Contratos de custos reembolsveis: Esta categoria de contratos envolve o pagamento (reembolso) ao fornecedor pelos seus custos reais. Os custos so classificados como diretos ou indiretos. Os custos diretos so custos incorridos para a realizao das atividades do projeto (salrios do pessoal de tempo integral, insumos, etc). Os custos indiretos, tambm chamados custos de overhead, so custos alocados ao projeto pela empresa por fora da realizao do negcio (salrios dos executivos, aluguis de prdios, etc). Os custos indiretos so usualmente calculados como uma percentagem dos custos diretos. Os contratos de custos reembolsveis frequentemente incluem incentivos quando se consegue atingir ou exceder determinados objetivos do projeto tais como metas de prazo ou custos totais. (c-) Contratos por preo unitrio: Ao fornecedor paga uma quantidade pr-estabelecida (por hora de servios profissionais ou por quantidade de servios). Neste tipo de contrato, o valor total depende das quantidades envolvidas para completar o trabalho.

15.2.7. Plano de gerenciamento do suprimento Uma vez identificados os produtos e servios a serem comprados de terceiros, a equipe ir desenvolver um documento que descreva os passos seguintes do processo. Este plano vai definir e estabelecer as condies de compra, por exemplo, o tipo de contrato para cada aquisio, a necessidade (ou no) de avaliao especializada, como ser feita a administrao dos vrios fornecedores, a coordenao das entregas com o cronograma do projeto, o papel do rgo de compra da empresa, etc.

124

Para projetos complexos ou crticos, o plano deve ser um documento detalhado. Projetos mais simples requerem grau menor de formalidade.

15.2.8. Preparao das aquisies Neste estgio, a equipe prepara os documentos necessrios para solicitar dados sobre os produtos e as condies de fornecimento por parte dos potenciais fornecedores. Se a condio principal para se escolher um fornecedor for o preo, os termos usados para se obter estas informaes so coleta de preos ou cotao. Se, alm do preo, capacidades e competncias do provvel fornecedor forem importantes, o termo normalmente usado ser proposta. Os documentos de aquisio devem ser rigorosos o bastante para garantir consistncia e respostas equivalentes, mas ao mesmo tempo precisam ainda ser flexveis o suficiente para permitir sugestes dos fornecedores quanto s melhores formas de atender aos requerimentos. Os documentos de aquisio devem conter os critrios usados para avaliar os diversos proponentes.

15.2.9. Tipos de documentos de aquisio - Solicitao de Propostas (RFP - Request for Proposal ou Tender) Solicita o preo, mas tambm uma proposta detalhada de como o trabalho ser feito, quem ser responsvel por faz-lo, os currculos dos profissionais envolvidos, experincias anteriores do fornecedor, etc. Em geral, utilizada em aquisies de valores relativamente altos de itens no comuns e/ou complexos e que necessitem de maior detalhamento de escopo. - Convite para Licitao ou Coleta de Preos (IFB - Invitation for Bid) Solicita um preo para executar todo o trabalho. Geralmente mais apropriado para itens de compra comuns e de rotina, nos quais o objetivo principal encontrar o melhor preo. O comprador dever descrever completamente o item a ser adquirido. Geralmente, no h negociao, pois o fornecedor que oferece o melhor preo ganha a concorrncia. - A Solicitao de Cotao (RFQ - Request for Quotation)

125

Solicita uma cotao de preo por item, por hora, por unidade de medida, etc. Em geral, utilizada em aquisies de valores relativamente baixos de itens comuns.

15.2.9. Estrutura dos documentos Os documentos de aquisio devem considerar pelo menos os seguintes aspectos: Finalidade da Solicitao de Proposta; Especificao do trabalho e de informaes do cronograma; Requisitos Bsicos das respostas desejadas; Procedimentos para as respostas; Critrios de avaliao; Anexos. Modelo de contrato.

15.3. Solicitao e recebimento de ofertas

Neste estgio, a equipe recebe as informaes (coletas de preos e propostas) dos potenciais fornecedores quanto ao atendimento das necessidades do projeto. Normalmente, a empresa dispe de uma lista de possveis fornecedores para cada tipo de produto a ser comprado. Se este no for o caso, a equipe dever buscar, por meio de convites ou anncios, compor uma lista com as informaes importantes relativas aos possveis fornecedores. Os convites para participar do projeto podem ser enviados para alguns ou para todos os fornecedores potenciais. Durante o processo, a equipe do projeto poder conduzir reunies com os potenciais fornecedores a fim de assegurar com que todos tenham claro entendimento do processo de compra (especificaes tcnicas, clusulas contratuais, etc). As respostas s questes podem ser incorporadas aos documentos de aquisio como emendas.

126

As ofertas (coletas de preos, cotaes e propostas) so documentos preparados pelos fornecedores de acordo com os documentos de aquisio e descrevem a capacidade e condies de fornecer o produto ou servio solicitado.

15.4. Seleo de fornecedores


Este estgio envolve a recepo de coletas de preos ou propostas, e a aplicao dos critrios de avaliao para selecionar um fornecedor. Em grande parte dos processos de compra, as propostas so separadas em duas sees: tcnica (quanto abordagem) e comercial (preo), e avaliadas separadamente. Normalmente, avalia-se primeiramente a parte tcnica, eliminando-se neste ponto os proponentes incapacitados, para depois julgar a parte comercial. Em itens crticos para o projeto, este processo pode ser iterativo. Selecionasse uma lista de fornecedores qualificados, baseados numa proposta preliminar, para em seguida, proceder a uma avaliao mais cuidadosa a partir de uma proposta mais detalhada e abrangente. Neste processo de seleo do fornecedor, so conduzidas reunies de negociao nas quais so esclarecidos assuntos pertinentes ao contrato a ser assinado. Os assuntos abordados incluem responsabilidade e autoridade no contrato, termos e leis aplicveis, prazos fatais, condies de financiamento, preo, etc. No caso de aquisio de itens complexos ou vitais para o projeto, a negociao contratual pode ser um processo independente produzindo, por exemplo, um memorando de entendimento mtuo. O produto deste estagio um contrato, ou seja, um compromisso mtuo que obriga o fornecedor a entregar o produto especificado e o comprador a pagar por ele. Deve-se estar atento para este documento, pois um contrato um relacionamento legal sujeito a recurso e aes jurdicas, em caso de descumprimento. As empresas devem indicar os seus prepostos, a partir de polticas e procedimentos documentados, os quais tm autoridade para assinar acordos em nome da empresa. Por envolver terceiros e a possibilidade de aes jurdicas, a maioria dos contratos deve ser submetida aprovao de outros rgos da empresa como, por exemplo, a rea jurdica ou, dependendo da magnitude do contrato, a diretoria ou outro rgo colegiado. Em todos os casos, um foco principal do processo de reviso e aprovao deve ser assegurar com que a linguagem do contrato descreva um produto ou servio que atenda s necessidades identificadas.

127

15.5. Administrao de contratos


o processo de assegurar com que o desempenho do fornecedor esteja adequado aos termos contratuais, e inclui a integrao dos fornecimentos de terceiros com a gerncia do projeto como um todo. Esta integrao frequentemente ocorre em mltiplos nveis, sempre que houver diversos fornecedores e produtos envolvidos. Para avaliar o desempenho do fornecedor, a equipe utiliza o contato assinado, a medio do trabalho executado, as mudanas aprovadas e as solicitaes de pagamento (faturas) dos fornecedores. O produto da avaliao do desempenho o relatrio de desempenho que fornece informaes a respeito da eficincia do fornecedor e ao atendimento dos objetivos do contrato. O relatrio do desempenho do contrato deve ser integrado com o relatrio do desempenho global do projeto. Se a equipe verificar que o contrato est sendo atendido, ir providenciar para que seja efetuado o pagamento respectivo.

15.6. Encerramento de contrato


Este estgio envolve tanto a verificao do produto entregue (Ser que o trabalho foi todo realizado e de forma correta, ou seja, satisfatoriamente?) quanto o fechamento administrativo (atualizao dos registros para refletir os resultados finais e arquivar as informaes para uso futuro). Os termos e condies contratuais podem determinar procedimentos especficos para encerramento do contrato. O trmino precoce de um contrato um caso especial de encerramento do contrato. A pessoa ou a empresa responsvel pela administrao do contrato deve informar o trmino do contrato ao fornecedor, a partir de notificao formalmente escrita. Os requerimentos para aceitao formal e fechamento so, normalmente, definidos no contrato.

15.6.4. Dicas para o Encerramento H um conjunto bsico de recomendaes a seguir para se permanecer com uma estrutura organizada de modo a terminar o projeto com sucesso:

128

Criar uma lista das tarefas restantes que devem ser terminadas. Geralmente, esta uma lista pequena das tarefas comparadas ao projeto original. Reunir com todos os responsveis para discutir a lista e os planos do que deve ser feito, quando se deve fazer, com quais recursos e quem o responsvel. Assegurar com que os documentos do projeto, suas especificaes e mudanas estejam plenamente atualizados, visando refletir exatamente as atividades do projeto. Pois, documentao incompleta ou atrasada frequentemente tambm atrasa no pagamento final e custa muito mais para ser produzida do que durante o ciclo de vida do projeto. Todas as solicitaes de mudana, independentemente do porte, devem seguir o processo normal de aprovao. Rever o custo comprometido para assegurar com que todas as despesas tenham sido pagas. Reconciliar e fechar contas financeiras relacionadas ao projeto.

Sntese

Nesta aula, descrevemos os elementos necessrios para o processo de aquisio de produtos e servios de fornecedores externos empresa. Com isto, reconhecemos o que deve ser feito para se ter sucesso nos seis estgios principais da administrao do suprimento do projeto: planejamento da procura, planejamento das requisies, concorrncia, seleo do fornecedor, administrao dos contratos e encerramento dos contratos. O gerenciamento das aquisies a parte do gerenciamento do projeto que inclui os processos necessrios para adquirir bens ou servios de fornecedores externos organizao executora do projeto, e evolve identificar quais necessidades do projeto podem ser melhor atendidas, usando produtos e servios de organizaes externas. Em seguida, formulamos a anlise do fazer ou comprar, preparando um plano efetivo de suprimento para guiar a equipe, e utilizando fontes externas de suprimento de maneira benfica para a empresa. Vimos que a anlise comprar ou fazer determina quais produtos devem ser feitos internamente ou comprados de terceiros, pois envolve frequentemente anlise financeira para se decidir:

129

O que comprar; Onde comprar; De quem comprar; Quanto comprar; Quando comprar. O gerenciamento das aquisies uma das nove reas de conhecimento definidas pelo PMBOK, e consiste necessariamente das seguintes fases: (1-) Planejamento do suprimento determinar o que comprar e quando. (2-) Preparao das aquisies documentar as especificaes dos produtos e identificar potenciais fornecedores. (3-) Solicitao e recebimento de Ofertas obter ofertas conforme apropriado a cada caso (tomada de preo, carta convite, licitao). (4-) Seleo de fornecedores escolher entre os proponentes. (5-) Administrao de contratos gerenciar o relacionamento com os fornecedores. (6-) Encerramento de contrato completar e liquidar o contrato incluindo itens pendentes. A participao de terceiros comum nos projetos, e inclui a coordenao e comunicao de especificaes com seus requisitos. Estas atividades envolvem documentos legais definindo-se a relao entre as partes, a durao, natureza e extenso dos servios, alm dos termos e condies necessrias. J o Plano de Gerenciamento do Suprimento define a estratgia para alinhar a cadeia de fornecedores de modo a alcanar os objetivos do projeto, pois forma a base para se gerenciar fornecedores internos e externos. Em contrapartida, o plano de gerenciamento das aquisies deve cobrir pelo menos os seguintes assuntos: Quais so as capacidades exigidas pelo projeto? Quais delas existem na organizao executora e quais devem ser adquiridas de terceiros? Os fornecedores atuais atendem aos requisitos e necessidades? Ou novos fornecedores devem ser desenvolvidos?

130

Quantas so as fontes de fornecimento? Quem so os fornecedores potenciais e qual o tipo de relao existe ou deve ser desenvolvido com eles? (Exemplo: acordo de longo prazo, fornecedor preferencial, etc.) Como sero avaliados e selecionados os possveis fornecedores? Quais indicadores de performance sero usados? Como ser medido o desempenho dos fornecedores? Com que frequncia isto dever ocorrer? Que aes corretivas sero tomadas em caso de desvios? Quais partes do projeto sero competitivamente objeto de concorrncia? Quais sero compradas das fontes com acordos e quais tero fornecedor especfico? Como ser gerenciada e documentada a comunicao com os fornecedores? De que forma os fornecedores sero integrados no projeto? Quais os riscos de fornecimento e como sero mitigados? De certo modo, o plano de gerenciamento das aquisies deve ser desenvolvido na fase de planejamento do projeto e integrado aos outros documentos gerados, os quais compilados formam o plano do projeto. Ao passo que o Plano das Aquisies particularmente importante em projetos de alto risco, complexos ou com grande dependncia de fornecedores externos. Um fornecimento complexo caracterizado por especificaes que mudam constantemente, englobando diversos stakeholders, muitos fornecedores, e em decorrncia da necessidade de mtodos avanados para gerenciamento de contratos.

131

16. Execuo (progresso e mudanas)


Parabns! Voc completou toda a documentao do plano do projeto! Neste ponto, voc j deve ter desenvolvido os seguintes procedimentos: 1. Um cronograma para saber quais atividades previstas e quando elas sero realizadas. 2. Um oramento que indica quanto o projeto ir custar. 3. Um plano de pessoal que lhe indicar quem ira executar as atividades. 4. Um plano da qualidade que determina quais testes e ensaios sero realizados, quando, por quem e quais os resultados deles esperados. 5. Um plano para lidar com o inesperado (Risco) e suas consequncias. 6. Um plano de comunicaes para informar aos interessados o progresso do projeto. 7. Um plano de suprimentos que mostra o que tem de ser adquirido no mercado, de quem, quando e por quanto. Enfim, estes documentos formam o plano do projeto que ser o seu guia para a realizao das atividades. Posto isto, agora arregaar as mangas e executar as atividades que a equipe planejou! Como administrador, cabe-lhe toda a responsabilidade pelo sucesso do projeto. Aps ter negociado adequadamente o planejamento, voc dever colocar o plano em ao. O objetivo da fase de Execuo e Controle realizar o produto ou o servio que o projeto se props a gerar, usando, para isso, os planos desenvolvidos na fase de planejamento. Eventos e situaes indesejadas iro inevitavelmente acontecer, e tanto o administrador quanto a equipe do projeto tero de tratar deles para minimizar seus efeitos nos objetivos do projeto. Durante esta fase, voc deve ainda se preocupar em monitorar as atividades listadas abaixo (as quais voc definiu na fase de planejamento). H uma srie de indicadores que vo lhe fornecer a viso a respeito do desempenho do projeto. Se algo sair diferente do planejado, voc ter ento de saber como tomar aes para corrigir o rumo indesejado. Vejamos ento, alguns pontos que asseguram a realizao adequada do projeto: Execuo das atividades; Monitorao e relatrios; Controle do prazo;

132

Controle do custo; Controle da qualidade; Controle de mudanas; Gerenciamento do risco; Gerenciamento do suprimento; Aceite de entregas parciais; Gerenciamento da comunicao; Gerenciamento da equipe.

16.1. O Processo de Controle


O PMBOK define controle como o seguinte: assegurar que os objetivos do projeto esto sendo atingidos, atravs da monitorao e da avaliao do seu progresso, tomando aes corretivas quando necessrias. Desta forma, o desempenho do projeto deve ser medido regularmente para identificar as variaes do plano. Estes desvios so analisados, dentro dos processos de controle e, na medida em que so identificados desvios significativos (aqueles que colocam em risco os objetivos do projeto), realizam-se ajustes ao plano por meio da repetio dos processos de planejamento que sejam adequados quele caso. Por exemplo, ultrapassar a data de trmino de uma atividade, pode requerer ajustes nos recursos humanos, na necessidade ou no de horas-extras, ou no balanceamento entre o oramento e os objetivos de prazo do projeto. O mesmo monitoramento deve ser realizado para analisar o Oramento, os Riscos, a Qualidade e o Escopo. Controlar tambm inclui tomar aes corretivas, antecipando-se aos problemas.

16.2. O que acontece na fase de execuo


Uma vez que o projeto esteja na fase de execuo, a equipe e os recursos devem estar disponveis para realizar as atividades planejadas.

133

O foco das atenes do administrador e da equipe do projeto volta-se agora para observar e analisar se o plano est sendo cumprido como foi estabelecido. Graficamente, podemos representar o processo de execuo do projeto, da seguinte forma:

Nesta fase, as tarefas crticas a serem realizadas so: Acompanhar e monitorar as atividades para mensurar o desempenho do projeto; Revisar e comunicar o status e as aes futuras; Monitorar e controlar os riscos e agir para mitigar quando necessrio; Acompanhar e controlar, incorporando mudanas aprovadas no plano do projeto; Estabelecer as aes corretivas para alinhar aes realizadas com as atividades previstas. Para bem realizar estas funes, o administrador do projeto dever trabalhar diariamente dando apoio equipe e interagindo com os stakeholders.

16.3. A reunio de partida - como iniciar positivamente


Logo no incio da fase de execuo, rena todos os membros da equipe para uma reunio de partida, e procure explicar-lhes exatamente em que consiste o projeto. Explique metas e limitaes, informe sobre como o projeto poder benefici-los pessoal e profissionalmente, e tambm defina regras bsicas para o compartilhamento de informao e tomada de decises. Deixe-os fazer perguntas. Ao final do encontro, todos devem ter bem claro o que precisa ser feito e se sentir motivados a consegui-lo.

134

Para entender melhor os benefcios desta reunio, que se prope a levantar subsdios para o sucesso do projeto, vamos esclarecer os objetivos deste primeiro encontro da equipe. A reunio de partida tem os seguintes objetivos principais: a. Tornar clara a estratgia de realizao do projeto para toda a equipe. b. Demonstrar os objetivos do projeto bem como os papis e responsabilidades esperadas de cada membro da equipe. c. Esclarecer as expectativas de todos os envolvidos. d. Criar esprito de equipe no grupo. Dependendo do escopo, das caractersticas e da complexidade do projeto, a reunio de partida pode durar de algumas horas at 2 ou 3 dias. Os participantes so o ncleo da equipe e os principais envolvidos. A conduo realizada pelo administrador do projeto o qual deve entender que esta reunio serve como um quebragelo para que todos saiam com um mesmo entendimento em relao aos objetivos do projeto. Embora a durao e o formato da reunio de partida possam variar dependendo da natureza do projeto, ela, normalmente, consiste de blocos, cada um focando num determinado aspecto do projeto. Assegure-se tambm de que voc tenha explicado completamente a situao, e que os membros da equipe no tm dvidas com respeito aos objetivos do projeto. Voc precisa que todos os integrantes da equipe estejam inteiramente comprometidos com o sucesso do projeto, e isto, sem dvida, poder se obter por meio de uma boa apresentao, logo no incio desta fase. Este evento serve ainda para alinhar as expectativas de cada um dos envolvidos no desenvolvimento do projeto.

16.3.1. As reunies de Avaliao O andamento do projeto deve ser examinado regularmente em reunies de avaliao. Conduza-as do modo certo, estimulando a equipe e fornecendo a todos os participantes uma viso precisa do progresso do plano traado. O patrocinador participar de algumas reunies nas quais as decises importantes estejam sendo tomadas. Os membros da equipe em geral devero comparecer a todas. Outras pessoas s sero convidadas se puderem efetivamente contribuir para o sucesso do projeto. Se algum dos convidados estiver apenas envolvido em poucos itens da pauta,

135

estime quando eles sero discutidos, e informe-os a respeito de quando sua presena ser ento necessria. Se for necessrio tomar uma deciso, assegure-se da presena de quem tem autoridade para tom-la.

16.3.2. Tipos de Reunio de Avaliao Normalmente, so conduzidas reunies regulares para examinar em detalhe a evoluo das atividades programadas. O perodo de realizao depende da durao do projeto, mas podem ser em bases quinzenais ou mensais. Um outro tipo de reunio deve ser conduzido quando marcos importantes do projeto so alcanados ou ainda metas so atingidas, e, em vista disso, o patrocinador e importantes stakeholders precisam ser informados. Nesses encontros, cujo foco estar centrado nos objetivos do projeto, tais pessoas podero verificar se os resultados esto atendendo aos critrios estabelecidos.

16.3.3. Disciplina na reunio O segredo de conduzir eficientemente uma reunio a disciplina. Lembre-se de que seu objetivo manter todos atualizados, para permitir-lhes a compreenso do que est acontecendo. Vrios fatores tornam uma reunio ordinria num caos. Porm, se voc observar certas regras (abaixo descritas) poder conduzir eficientemente as reunies do projeto. Vejamos ento cada uma destas regras que contribui para que uma reunio entre os envolvidos em determinado projeto seja bastante proveitosa. Durao - O aspecto-chave a durao da reunio. Algumas pessoas se atrasam e outras saem antes de ela terminar. Voc dever estabelecer uma agenda e informar os participantes com adequada antecedncia para que se preparem. Esta providncia importante, mas o essencial iniciar e terminar no horrio previsto considerando uma folga para ultrapassar (pouco) esta previso. Coloque na maioria das vezes um alongamento de 15 a 20 minutos, mas comece sempre na hora estabelecida. Agindo assim, voc demonstra a importncia da reunio e acostuma as pessoas a serem pontuais. Pauta - Estabelea uma sequncia dos assuntos, e procure estimar a durao das discusses de cada um deles. Procure manter esta agenda sem perder a flexibilidade. Objetivo - Evite disperses e discusses paralelas. Mantenha o foco nos objetivos da reunio. No permita que a reunio se afaste da pauta, registre de quando em quando tudo o que ainda falta discutir e controle os tempos planejados para cada item. Se as pessoas

136

derivarem do assunto ou conversarem improdutivamente, reforce os objetivos da reunio, dizendo, por exemplo: No estamos aqui para discutir esse assunto, voltemos ao ponto que interessa. Quando for o caso, resuma as avaliaes e as decises tomadas. Aps a discusso de cada item, libere quem j no precise mais ficar na reunio.

16.4. Execuo das Atividades


Esta a parte do projeto que consome a maioria dos recursos, pois quando as atividades previstas so efetivamente realizadas. Algumas dicas podem ser seguidas para voc executar adequadamente este estgio, como, por exemplo: Estabelea objetivos tenha objetivos frequentes, no deixando passar dias ou semanas sem que voc possa medir se est se aproximando do objetivo do projeto. Avalie a Qualidade do que est sendo gerado a medio constante da qualidade e a comparao com as especificaes tem o efeito de manter o projeto dentro do nvel de qualidade desejado. No deixe para medir as caractersticas quando os produtos j estiverem completamente prontos, pois poder inviabilizar aes corretivas.

16.5. Gerenciamento da Mudana


Se existe alguma certeza na conduo do projeto que ele no ir se realizar exatamente conforme foi planejado. Voc poder descobrir novas maneiras de realizar as tarefas, encontrar problemas que devero ser solucionados, melhorar o rendimento de alguma mquina, etc. Estes e outros fatos so fontes de mudana. Portanto, normal lidar com mudanas durante a execuo das atividades do projeto. Como mudanas so inevitveis, os projetos devem ser flexveis. Se um deles tiver seu propsito alterado por uma ordem superior, voc dever negociar as modificaes, adaptar o plano e manter todos os informados em relao ao que est ocorrendo. No geral, podemos considerar que temos trs tipos principais de mudanas: Com relao ao prazo; Com relao aos recursos;

137

Com relao ao produto do projeto. Lembre-se de que qualquer uma destas categorias de mudanas poder afetar na concluso do projeto, e que voc dever administr-las e controla-las sempre adequadamente. Algumas mudanas estaro sob seu controle - por exemplo, encurtar determinados prazos porque a equipe conseguiu aumentar a velocidade de execuo das atividades. Outras sero impostas - um cliente pode solicitar algo diferente, ou um superior pode decidir trocar membros de sua equipe. Em qualquer caso, vital a habilidade de ajustar o plano segundo as circunstncias. Depois de implantar a mudana, verifique se o efeito desejado no projeto foi alcanado.

16.6. Avalie o impacto da Mudana


Como uma forma de se proteger e proteger o projeto, avalie o impacto da mudana no projeto antes de se comprometer com sua incorporao. Pea equipe para examinar os efeitos no cronograma, no oramento, na qualidade e nos recursos. Estude alternativas, verificando se h outros meios de atingir os objetivos do projeto. Busque tambm a aprovao do patrocinador e demais interessados antes de implant-las. Para isto, voc dever considerar pelo menos as seguintes questes: Quem solicita a mudana? O que vai mudar e por qu? Qual a importncia da mudana para o projeto? Quais os efeitos nos objetivos do projeto (custo, prazo, qualidade)? Quem aprova a mudana? O que acontecer se voc implementar a mudana?

138

16.7. Discuta as Mudanas


Rena a equipe para avaliar como as mudanas podem afetar o plano do projeto. Procure alternativas em relao a metas, ordem das atividades, oramento, pessoas, recursos e tempo originalmente programados. Analise com a equipe os impactos da mudana e esteja preparado para recusar aquelas que podem afetar negativamente o projeto. Procure o solicitante e argumente, mostrando os benefcios que sero perdidos e os danos que podem ser causados. Oferea alternativas para assegurar com que os objetivos do projeto sejam mantidos. Antes de efetuar a mudana, esteja atento a efeitos indesejados. Por exemplo: mudar um integrante da equipe por outro com mais qualificao pode afetar seriamente o moral da equipe. A coisa mais importante com relao s mudanas que elas simplesmente acontecem. Em alguns casos, porque h a necessidade de mudar, e, em outros, por erros ou omisses que supostamente foram cometidos. Portanto, preste muita ateno s situaes de mudana, procurando fazer com que o projeto melhore, ou no mnimo permanea como o programado.

16.8. Controle do risco


medida que o projeto progride, durante a execuo, os riscos mudam de perfil devido a mudanas nas condies internas, como, por exemplo: novas especificaes; e nas condies externas, como, por exemplo: mudanas na legislao ou nos fornecedores. Por isso, essencial o contnuo monitoramento atualizado dos riscos. Novos riscos podem aparecer devido s mudanas no projeto, mesmo que os riscos j identificados tenham sido eliminados ou mitigados pela ao de tratamento de riscos. A frequncia destas revises depende da durao do projeto, mas, como regra geral, elas devem ser realizadas a cada um quarto do prazo do projeto. Especial ateno deve ser dada a esta questo, tendo em vista que o perfil de risco necessite ser reavaliado quando: Inicia-se uma nova fase do projeto; H mudana significativa do escopo; H mudana significativa dos participantes do projeto como um novo patrocinador ou um novo administrador do projeto. A reavaliao normalmente conduz :

139

Identificao de novos riscos; Descarte dos riscos eliminados; Reclassificao dos riscos remanescentes, se houver mudana na probabilidade de ocorrncia ou no impacto no projeto. Portanto, tenha muita ateno no tratamento dos riscos durante esta fase, pois a falha em detectar novos riscos ou em tomar as aes corretivas necessrias no tempo certo pode significar o fracasso do projeto.

16.9. Relatrios de desempenho


medida que o projeto avana o administrador deve, regularmente, informar aos stakeholders o status atual do projeto e as expectativas futuras. Falhas na comunicao podem levar a expectativas diferentes redundando em problemas a serem administrados. As reunies de status e as respectivas atas podem ajudam a reduzir as surpresas desagradveis. Ao redigir um relatrio, procure responder s seguintes questes: O projeto ficar pronto no prazo? O projeto ficar pronto dentro do oramento? As Entregas sero concludas com a qualidade desejada? As mudanas esto sendo bem gerenciadas? Os riscos do projeto esto sendo tratados e minimizados? Os problemas do projeto esto sendo identificados e resolvidos? As solicitaes do cliente esto sendo atendidas? Se alguma das questes acima tiver resposta negativa, voc dever providenciar informaes adicionais com relao ao item considerado. Para completar, liste as principais realizaes no perodo, e a previso de realizaes para o prximo perodo de relatrio.

140

Descreva quaisquer outros comentrios que o interessado deva saber, e que no tenham sido mencionados no Relatrio de Status.

16.10. Entregas
Projetos dependem de resultados. Os produtos tangveis, servios, ou planos entregues como resultados do projeto so chamados de Entregas. Alguns marcos importantes do projeto (milestones) coincidem com entregas de produtos ou de servios. Os resultados do projeto envolvem os resultados parciais e os resultados finais. Os resultados parciais devem ser considerados para cada estgio do projeto como metas determinadas, marcos importantes, etc.

16.11. Planejamento das Entregas


O plano de Entregas ou plano de Marcos produzido na fase de planejamento, e constitui um meio de avaliao do desempenho do projeto. Neste documento, o Administrador do projeto e a equipe estabelecem um cronograma de todas as entregas e os respectivos critrios de aceite. As entregas parciais devem ter datas e critrios de aprovao claramente definidos e aprovados por quem tenha autoridade para tal.

16.12. Entregas parciais


Durante a Execuo, determinados produtos vo sendo concludos e podem ser entregues como forma de demonstrar o avano do projeto. Os critrios de aceite dos produtos intermedirios (entrega) devem ser sempre estabelecidos na fase de planejamento. No ponto de entrega parcial, os produtos gerados devem ser comparados com suas especificaes, as quais foram definidas previamente. Os produtos podem ser classificados e aceitos ou ainda rejeitados da seguinte forma: Aprovao integral - atendem integralmente especificao; Aprovao parcial - atendem parcialmente especificao e podem ser utilizados sem aes corretivas;

141

Aprovao parcial - atendem parcialmente especificao e devem ser re-trabalhados para serem utilizados; Rejeio os produtos no atendem s especificaes e devem ser totalmente refeitos. A cada Entrega deve ser preenchido um documento de aceite, caracterizando que o produto foi verificado e suas caractersticas comparadas com as especificaes. Este documento deve ser assinado por quem tenha autoridade para tal, estabelecida no Termo de Abertura do projeto.

16.13. Entrega final


Depois de produzida a ultima Entrega Parcial, os resultados do projeto devem ser colocados disposio do cliente. O Administrador deve obter ento a aprovao, promovendo a transio dos produtos para uso por parte do cliente. Normalmente, requerida uma assinatura do Patrocinador concordando com os termos do documento de Entrega Final. Desta forma, o projeto formalmente reconhecido como concludo.

Sntese

Vimos que a fase de Execuo do projeto o perodo no qual a maior parte dos recursos do projeto consumida. Nesta fase, o administrador deve monitorar todas as atividades que esto sendo realizadas e comparar seus resultados com o previsto no Plano do Projeto. Os resultados so medidos e confrontados com suas especificaes, que so indicadores de desempenho. Caso sejam constatados desvios, a equipe deve tomar aes corretivas de forma a fazer com que o projeto retorne ao rumo estabelecido. Percebemos tambm como as mudanas devem ser monitoradas e suas implicaes avaliadas e registradas, sendo que o plano do projeto deve ser atualizado de modo a refletir as Mudanas de grande magnitude incorporadas. Sendo assim, os riscos do projeto devem ser acompanhados e suas caractersticas continuamente revistas para que a equipe no tenha surpresas desagradveis no decorrer desta fase.

142

O plano de comunicaes (elaborado na fase de planejamento) deve ser efetivado tambm nesta fase. Informar o progresso do projeto aos stakeholders-chave, gerenciando suas expectativas essencial para o sucesso do projeto. medida que o projeto avana no desenvolvimento de produtos tangveis, servios e planos so produzidos. Estes produtos vo sendo entregues conforme o projeto cumpra seus objetivos finais. O cliente (ou quem tiver autoridade para tal) dever aceitar ou rejeitar tais produtos, atestando o progresso do projeto. Por ltimo, a entrega final assim como a transio dos resultados do projeto para o uso por parte do cliente devem ser registradas em documento prprio, demonstrando que o projeto foi concludo e aceito.

143

17.

Fechamento do Projeto

O fechamento do projeto consiste nas atividades necessrias para se documentar o resultado final do projeto em termos de caractersticas do produto e do gerenciamento do projeto. Nesta fase, vamos avaliar os pontos fortes e fracos do trabalho envolvido, encerrar os contratos ainda em aberto, e relatar lies aprendidas bem como as melhores prticas para futuros projetos. Esta fase inicia-se quando os objetivos definidos do projeto so alcanados e o cliente aceitou o produto gerado pelo projeto. O processo de Fechamento ou (Encerramento) composto de, pelo menos, os seguintes elementos: Aceite final do produto do projeto pelo cliente; Encerramento de todos os acordos contratuais com fornecedores e terceirizados; Formalizao da aceitao do cliente; Fechamento e conciliao das pendncias financeiras; Identificao, documentaes e comunicao das lies aprendidas; Preparao e distribuio do RAPI; Coleta, compilao e arquivamento dos registros do projeto; Avaliao da satisfao do cliente; Celebrao do sucesso; Devoluo dos recursos pessoal, mquinas, equipamentos, sistemas etc... O fechamento deve ser realizado ao trmino de cada fase do ciclo de vida, para garantir com que as atividades de cada fase tenham sido completadas satisfatoriamente e com que informaes teis e valiosas no sejam perdidas. Esta providncia evita que o administrador e a equipe tenham de lidar com itens ainda abertos ou com informao antiga ou desatualizada. O Fechamento tambm inclui as informaes relativas ao desempenho da equipe para as reas de origem e para a rea de Recursos Humanos, de modo que os integrantes da equipe possam ser avaliados pela sua participao no projeto. Alm disso, o processo envolve outras atividades administrativas para assegurar com que os ativos utilizados pelo projeto sejam devolvidos s respectivas origens.

144

A documentao de fechamento no deve ser confundida com uma simples obteno de assinatura de aceitao ou aprovao do cliente, mas envolve uma srie de estgios para assegurar com que o produto atenda s expectativas, estando de acordo com as especificaes necessrias. O Relatrio de Avaliao de Ps-Implementao (RAPI) o documento que caracteriza o trmino da fase de Fechamento. Nele, so identificadas atividades especialmente importantes para grandes projetos que utilizam muitos recursos e bastante documentao. A fase de encerramento pode ser dividida em dois grandes blocos, ou seja: 1. Relatrio de Avaliao de Ps-implementao. 2. Fechamento Administrativo. Vamos ento discorrer um pouco em relao a estes dois principais blocos.

17.1. Relatrio de Avaliao de Ps Implementao (RAPI)


Este relatrio documenta o sucesso ou fracasso do projeto, pois ele fornece um registro histrico do oramento bem como os cronogramas planejados e realizados. Outras variveis do projeto podem ser coletadas, com base na documentao armazenada. Este relatrio tambm inclui recomendaes para projetos futuros de tamanho e escopo similares. O RAPI inclui pelo menos a anlise dos seguintes tpicos: Termo de aceitao definitivo; Gerenciamento do cronograma; Gerenciamento do oramento; Gerenciamento do risco; Gerenciamento da qualidade; Lies aprendidas.

145

17.1.1. Lies aprendidas A sesso de Lies Aprendidas do relatrio elaborada para se aproveitar pontos positivos e alertar para aspectos negativos em projetos futuros. A base para tais recomendaes diz respeito s observaes dos aspectos analisados conforme acima mencionado. Algumas questes tpicas a serem respondidas neste estgio podem ser, por exemplo: O produto atende s especificaes e objetivos do projeto? O cliente ficou satisfeito com os resultados do projeto? O projeto foi concludo dentro do oramento? Quanto se afastou? Em que nvel o cronograma foi cumprido? Quanto se desviou? Os riscos foram adequadamente tratados? O que pode melhorar? O que poder ser feito para melhorar a administrao nos prximos projetos? Normalmente estas definies so tomadas em reunio especifica que sinaliza o trmino do projeto. Os convidados a participar desta reunio em grande parte dos casos so: A equipe do projeto; O Cliente; O patrocinador; As reas de Operao e Manuteno; Estas reunies so o marco oficial de encerramento do projeto e podem ser utilizadas para um reconhecimento pblico do mrito da equipe no projeto.

17.2. Registro das Lies Aprendidas


Um dos objetivos do RAPI documentar as Lies Aprendidas. Significa que os problemas encontrados pela equipe do projeto so apresentados de forma aberta e transparente. A identificao de problemas em projetos concludos fornece um mtodo para discutir e evitar que estes mesmos problemas aconteam em projetos futuros. Neste aspecto, a discusso, e no uma caa s bruxas em busca de reas com problemas, essencial para desenvolver recomendaes teis para projetos futuros.

146

Este documento serve como balizador para a Alta Administrao e para outras equipes de projeto de forma a prevenir com que os mesmos problemas aconteam ou de forma a estimular com que as mesmas oportunidades ocorram e sejam aproveitadas. Uma vez que pontos sensveis ou estratgicos podem ser tratados neste documento, interessante que todos que possam contribuir recebam uma cpia do material antes da publicao formal do documento.

17.3. Preparao do RAPI


Normalmente, o administrador do projeto tem a responsabilidade por preparar o relatrio, utilizando contribuies da equipe do projeto, do cliente e dos stakeholders principais. A opinio do cliente em relao ao produto final do projeto de suma importncia para o aproveitamento das lies aprendidas. Para preparar o relatrio, o administrador conduz uma pesquisa de opinio com os principais envolvidos no projeto. Para assegurar uma avaliao profunda e imparcial, o feedback deve ser solicitado a uma gama variada de envolvidos, inclusive os stakeholders externos empresa. O relatrio deve conter o resumo estatstico de todas as respostas em cada categoria e uma anlise racional das opinies.

17.4. Encerramento administrativo


Este processo inclui a coleta dos registros do projeto, (assegurando com que eles reflitam as especificaes finais), a anlise da efetividade e do sucesso do projeto bem como a disponibilizao destas informaes para uso futuro. Toda documentao referente ao produto do projeto (desenhos, manuais, esquemas, etc) e que ainda no tenha sido entregue ao cliente deve ser completada e entregue ao administrador do projeto. A lista a seguir descreve tais documentos e processos a serem entregues.

17.5. Assinatura do Cliente


Como descrito anteriormente, o item de fundamental importncia no Encerramento do projeto a aprovao dos produtos do projeto pelo cliente.

147

A melhor forma de conduzir este processo conduzir uma reunio final com todos os stakeholders necessrios para revisar o produto e compar-lo com as especificaes definidas. Neste ponto, quaisquer desvios da especificao devem ser documentados, justificados e aprovados. Todos os pontos ainda em aberto devem ser formalmente fechados. Ao trazer todos os stakeholders para uma reunio nica, o administrador do projeto evita reunies individuais de esclarecimentos com cada um deles. O produto final desta reunio deve ser uma declarao dos stakeholders, descrevendo o produto final e aprovando o produto como est. A aprovao definida pela assinatura dos stakeholders que assinaram os documentos iniciais do projeto.

17.6. Pessoal e Equipamentos


Ao trmino do projeto, importante devolver rapidamente as pessoas que trabalharam em tempo integral para a realizao do projeto, levando em conta as suas reas de origem. Esta providncia evita ociosidade e permite a realocao em outros projetos em curto espao de tempo. Caso o projeto tenha utilizado mquinas e equipamentos ou espaos da empresa, o administrador do projeto deve disponibiliz-los para uso em outros projetos ou de forma a serem incorporados aos ativos da empresa.

17.7. Fechamento Financeiro


Compreende as atividades de fechamento dos aspectos financeiros e de oramento. Envolve tanto o fechamento de contratos com terceiros como os acordos internos entre reas da empresa, quando houver.

17.8. Fechamento de contratos


Compreende as atividades de encerramento formal de contratos com terceiros que tenham sido assinados como parte deste projeto.

148

Estes contratos so a forma de fornecer suporte tcnico, consultoria, ou outro tipo de servio que a equipe resolveu no executar com os recursos prprios da empresa. O fechamento de contratos uma atividade simples, porm parte importante da Administrao de Projetos, pois evita expor a empresa a possveis responsabilidades legais com os contratantes. De maneira a fechar formalmente o contrato, a empresa contratante fornece contratada uma declarao formal sobre a aceitao do produto ou servio fornecido, alm das razes para o encerramento do contrato. O padro para este texto normalmente encontrado no prprio contrato. Por medida de segurana, o administrador do projeto mantm, em local acessvel, um conjunto completo de todos os documentos gerados pelo contrato, para o caso de que venham a serem usados no futuro.

17.9. Arquivamento
Depois da preparao do RAPI, as informaes do projeto so arquivadas. Pois, dados histricos do projeto so importante fonte de informao para ajudar a melhorar projetos futuros. Tipicamente, so arquivados os seguintes itens: Planos do projeto, incluindo o escopo, o termo de referncia, o plano de gerenciamento do risco, o plano da qualidade, etc; Correspondncias; Atas de reunio; Relatrios; Contratos; Documentos tcnicos; Outras informaes; e Todas as cpias impressas do projeto.

149

17.10. Celebrao do sucesso


Os critrios pelos quais um projeto ser considerado bem sucedido so definidos nas fases iniciais do projeto. O sucesso no medido somente pelo oramento e cronograma. Embora sejam fatores muito importantes, existem projetos que podem custar mais do que o programado, e, mesmo assim, serem considerados bem sucedidos. Algumas questes devem ser respondidas para se determinar se um projeto foi bem sucedido, tais como: Os objetivos estabelecidos foram alcanados? Os stakeholders aceitam positivamente os resultados do projeto? O projeto foi satisfatrio no que se refere a Marcos e Entregas intermedirias? O projeto foi conduzido de acordo com os termos contratuais? A equipe trabalhou coesa em sintonia com os objetivos da empresa?

17.11. Reconhecimento
Uma constatao universal que o reforo do comportamento positivo ou a gratificao do comportamento uma ferramenta efetiva de gerenciamento. importante reconhecer o bom desempenho coletivo ou individual. Se alguns integrantes se destacarem, no se esquea de parabeniz-los assim como a equipe toda pelo alcance dos objetivos. Existem muitas formas de reconhecer o mrito dos integrantes da equipe por bom desempenho. Poder ser desde uma celebrao informal no ps horrio de servio at um reconhecimento formal e premiao em evento com todos os participantes. Outras maneiras incluem placas, meno no rgo da empresa, certificados, etc. Se estas formas de reconhecimento incidirem em custos devero estar previstas no oramento.

150

Sntese: Ao trmino do projeto, o administrador tem importantes atribuies a realizar. muito importante que estas aes sejam completamente entendidas e executas para se concluir o projeto com sucesso. A fase de Fechamento se destina reviso do produto e avaliao do seu grau de consistncia com os objetivos estabelecidos no incio do projeto. Uma vez que o projeto seja declarado terminado, o administrador busca, por meio de uma pesquisa de opinio com os principais stakeholders, avaliar o desempenho geral da equipe assim como tambm obter a aprovao do cliente para o produto gerado pelo projeto. A organizao das informaes desta pesquisa d origem ao Relatrio de Avaliao de PsImplementao (RAPI), documento que identifica as lies aprendidas (acertos e falhas) e recomenda a aplicao das melhores prticas em futuros projetos ou mesmo na administrao geral da empresa. Durante a fase de Fechamento, a documentao pertinente e importante compilada e armazenada em local de fcil acesso para uso futuro por outras equipes ou pela alta administrao. A atualizao do perfil de competncias dos integrantes da equipe ajuda na identificao de futuros lderes, alm de proporcionar informao para treinamento e qualificao da fora de trabalho. O encerramento dos contratos e o fechamento contbil do projeto so outras atividades tpicas desta fase do ciclo de vida do projeto.

151

18.

Referncias Bibliogrficas.

ADAMS, J. R.; CAMPBELL, P. Roles and responsibilities of the Project manager. NEW YORK: PMI, 1996. DISNMORE. PAUL. Human factors in project management. NEW YORK: American Management Association (amacon), 1984 MAXIMIANO, Antonio Csar Amaru. Administrao de projetos: como transformar idias em resultados. So Paulo: Atlas, 2a ed, 2002. SCHUBERT, Pedro. Implantao de projetos: sua administrao, uma experincia brasileira. Rio de Janeiro: Editora LTC, 1989. OLIVEIRA, Djalma de Pinho Rebouas de. Planejamento estratgico: conceitos metodologias e prticas. So Paulo: Atlas, 12a ed., 1998. MATHIAS, Washington Franco. Projetos: planejamento, elaborao, anlise. So Paulo: Atlas, 1986. CLELAND, David I. Project Management: Strategic Design and Implementation, 1994. CLELAND David I., IRELAND Lewis R. Gerncia de projetos. Rio de Janeiro: Editora Reichmann e Affonso Editores, 2002. FRAME, J. Davidson. The New Project Management, 1994. LEWIS, James P. Project Planning, Scheduling & Control, 1995. MEREDITH and MANTEL. Project Management: A Managerial Approach. Vrios autores. A Guide to the Project Management Body of Knowledge PMBOK, captulo 5, edio 2000. Vrios Autores. A Guide to the Project Management Body of Knowledge (PMBOK). USA: Project Management Institute, 2004. KERZNER, H. Project Management: A Systems Approach to Planning, Scheduling and Controlling. 6th Edition. USA: John Wiley & sons, 2000. KEELING, Ralph. Gesto de projetos: uma abordagem Global. So Paulo: Editora Saraiva, 2002. HELDMAN, Kim. Gerncia de Projetos: Guia para o exame oficial do PMI.

152

Rio de Janeiro: Editora Campus, 2005. KERZNER, H. Project Management: A Systems Approach to Planning, Scheduling and Controlling. 6th Edition. USA: John Wiley & sons, 2000.

153