FGVIDT

FGV IDT
Gestão de Projetos
 FGVIDT

Sumário
APRESENTAÇÃO 9

UNIDADE 01 – PROJETO 10

1.1 - DEFINIÇÃO DE PROJETO 10

1.2 - CARACTERÍSTICAS DE UM PROJETO 10
1.3 - DE ONDE SURGEM OS PROJETOS? 11
1.4 - PROJETO VERSUS PROCESSO 12
1.5 - PROJETO VERSUS SERVIÇOS/OPERAÇÕES 13
1.6 - CONVENÇÕES E TÉCNICAS 14
1.6.1 - CICLO DE VIDA DOS PROJETOS 15
1.6.2 - CARACTERÍSTICAS DO CICLO DE VIDA DOS PROJETOS 15
1.6.3 - BENEFÍCIOS DO CICLO DE VIDA DO PROJETO 16
1.6.4 - FASES DO PROJETO 16
1.6.5 - OBJETIVO DO PROJETO 16
1.6.6 - DURAÇÃO DO PROJETO 17
1.7 - CARACTERÍSTICAS DOS PROJETOS BEM SUCEDIDOS 17
1.8 - ERROS COMUNS NA GESTÃO DE PROJETOS 19

UNIDADE 02 – GERENCIAMENTO DE PROJETOS 20

2.1 - O QUE É GERENCIAMENTO DE PROJETOS? 20

2.2 - PROCESSOS DE GERENCIAMENTO DE PROJETOS 20
2.2.1 - GERENCIAMENTO DE PORTFÓLIO 20
2.2.2 - GERENCIAMENTO DE PROGRAMAS 21

2.2.3 - GERENCIAMENTO DE PROJETOS 21

22

UNIDADE 03 – METODOLOGIAS DE GERENCIAMENTO

DE PROJETOS 23

3.1 - PRINCIPAIS METODOLOGIAS DE GERENCIAMENTO DE PROJETOS 23

 FGVIDT

3.1.1 - METODOLOGIAS ÁGEIS 24

3.1.1.1 - ÁGIL 24
3.1.1.2 - SCRUM 26
3.1.1.3 - KANBAN 27
3.2 - METODOLOGIA EM CASCATA (WATERFALL) 28
3.3 - PRINCE 2 (PROJECT IN CONTROLLED ENVIROMENT) 29
3.4 - CANVAS ADAPTADO A PROJETOS (PROJECT MODEL CANVAS) 30
3.5 - PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK) 32
3.5.1 - DOMÍNIOS DE DESEMPENHO DO PROJETO 32
3.5.1.1 – PARTES INTERESSADAS 33
3.5.1.2 – EQUIPE 33
3.5.1.3 – CICLO DE VIDA 33
3.5.1.4 – PLANEJAMENTO 33
3.5.1.5 – INCERTEZA E AMBIGUIDADE 34
3.5.1.6 – ENTREGA 34
3.5.1.7 – DESEMPENHO 34
3.5.1.8 – TRABALHO DO PROJETO 34
3.5.2 – PRINCÍPIOS DO GERENCIAMENTO DE PROJETOS 34
3.5.2.1 – 1º PRINCÍPIO - STEWARDSHIP 34
3.5.2.2 - 2º PRINCÍPIO – EQUIPE 35
3.5.2.3 - 3º PRINCÍPIO – PARTES INTERESSADAS 35
3.5.2.4 - 4º PRINCÍPIO – FOCO EM VALOR 35
3.5.2.5 - 5º PRINCÍPIO – PENSAMENTO HOLÍSTICO 35
3.5.2.6 - 6º PRINCÍPIO - LIDERANÇA 35
3.5.2.7 - 7º PRINCÍPIO - TAILORING 36
3.5.2.8 - 8º PRINCÍPIO – QUALIDADE 36
3.5.2.9 - 9º PRINCÍPIO – COMPLEXIDADE 36
3.5.2.10 - 10º PRINCÍPIO – RISCOS 36
3.5.2.11 - 11º PRINCÍPIO - ADAPTABILIDADE E RESILIÊNCIA 37
3.5.2.12 - 12º PRINCÍPIO – MUDANÇAS 37
3.5.3 - SISTEMA DE ENTREGA DE VALOR 37
3.5.4 – ABORDAGEM BASEADA EM PROCESSOS 38
3.6 - MÉTODO DO QUADRO LÓGICO (MQL) 38
3.6.1 - GRÁFICO DA MATRIZ LÓGICA 39
3.6.1.1 - PREENCHIMENTO DA MATRIZ DE ESTRUTURA LÓGICA DO PROJETO 40

UNIDADE 04 – PLANO DE GERENCIAMENTO DE

PROJETO 45
4.1 – A IMPORTÂNCIA DO PLANO DE GERENCIAMENTO DE PROJETO 45
4.2 – IDENTIFICAR AS PARTES INTERESSADAS 45
4.3 – DEFINIR PAPÉIS E RESPONSABILIDADES 46
4.4 – REUNIÃO INICIAL - KICKOFF 46
4.5 - DEFINIR ESCOPO, ORÇAMENTO E CRONOGRAMA DO PROJETO 46
4.5.1 - ESCOPO 46
4.5.2 - CRONOGRAMA DO PROJETO 47
4.5.3 – ORÇAMENTO 47
4.6 – DEFINIR OS OBJETIVOS E METAS 47
4.6.1 – OBJETIVOS E RESULTADOS-CHAVE (OKR) 47
4.7 – DEFINIR ENTREGAS 48
4.8 – AVALIAR OS RISCOS 48
4.9 – COMUNICAR O PLANO DO PROJETO 49
4.10 – GERENCIAMENTO DO CICLO DE VIDA DO PROJETO 49
 FGVIDT

4.11 - GRUPOS DE PROCESSOS 49

4.11.1 - INICIAÇÃO 49
4.11.2 - PLANEJAMENTO 51
4.11.3 - EXECUÇÃO 52
4.11.4 - MONITORAMENTO E CONTROLE 52
4.11.5 - ENCERRAMENTO 53

UNIDADE 05 - PLANO DE GERENCIAMENTO DO ESCOPO 54

5.1 - GERENCIAMENTO DO ESCOPO 54

5.2 - IDENTIFICAR OS PRESSUPOSTOS 54
5.3 - IDENTIFICAR AS RESTRIÇÕES 55
5.3.1 – RESTRIÇÃO CUSTO 55
5.3.2 - RESTRIÇÃO ESCOPO 55
5.3.3 - RESTRIÇÃO QUALIDADE 56
5.3.4 - RESTRIÇÃO RISCO 56
5.3.5 - RESTRIÇÃO RECURSOS 56
5.3.6 - RESTRIÇÃO TEMPO 56
5.3.7 - TRÍPLICE RESTRIÇÃO 56
5.4 - PREMISSAS 57
5.4.1 – EFEITOS E EXTERNALIDADES 57
5.4.2 - EFEITOS PARA FRENTE 57
5.4.3 - EFEITOS PARA TRÁS 58
5.5 - EXTERNALIDADES 58
5.6 - COLETAR OS REQUISITOS 59
5.7 - DEFINIR O ESCOPO 60
5.8 - CRIAR A ESTRUTURA ANALÍTICA DO PROJETO (EAP) 61
5.8.1 - CRITÉRIOS PARA DECOMPOSIÇÃO DA EAP 62

UNIDADE 06 - PLANO DO GERENCIAMENTO DO

CRONOGRAMA 64

6.1 - GERENCIAMENTO DO CRONOGRAMA 64

6.1.1 - DEFINIR AS ATIVIDADES 64
6.1.2 - SEQUENCIAR AS ATIVIDADES 65
6.1.3 - ESTIMAR AS DURAÇÕES DAS ATIVIDADES 66
6.1.4 - DESENVOLVER O CRONOGRAMA 67
6.1.4.1 - PASSOS PARA A ELABORAÇÃO DO CRONOGRAMA 69
6.2 - DIAGRAMAS DE REDE DO CRONOGRAMA DO PROJETO 70
6.2.1 ANÁLISE DO CAMINHO CRÍTICO 70
6.2.2 - VANTAGENS DOS DIAGRAMAS DE REDE 72

UNIDADE 07 – PLANO DE GERENCIAMENTO DOS CUSTOS 74

7.1 - GERENCIAMENTO DOS CUSTOS 74

7.1.1 - ESTIMAR OS CUSTOS 74
7.1.1.1 - TÉCNICAS DE CÁLCULO DE CUSTOS 74
7.1.2 - DETERMINAR O ORÇAMENTO 76
7. 2 - OUTROS CONCEITOS DE CUSTOS 76
7.2.1 - TCO - TOTAL COST OF OWNERSHIP - CUSTO DE PROPRIEDADE 76
 FGVIDT

7.2.2 - CUSTOS DO PROJETO 76

7.2.3 - CUSTOS DE OPERAÇÃO 76
7.2.4 - CUSTO DAS ALTERNATIVAS (TRADE-OFF) 76
7.2.5 - CUSTOS AFUNDADOS 76
7.2.6 - ROUGH ORDER OF MAGNITUDE (ROM) 77
7.2.7 - TOP DOWN 77
7.2.8 - BOTTOM UP 77
7.2.9 - DEPRECIAÇÃO E OBSOLESCÊNCIA 77
7.2.9.1 - DEPRECIAÇÃO FÍSICA 77
7.2.9.2 - DEPRECIAÇÃO CONTÁBIL 77
7.2.9.3 - DEPRECIAÇÃO LINEAR 78

UNIDADE 08 – PLANO DE GERENCIAMENTO DOS

RECURSOS 79

8.1 ESTIMAR OS RECURSOS DAS ATIVIDADES 79

8.1.1 - ESTIMATIVA DE RECURSOS HUMANOS 79
8.1.1.1 - IDENTIFICAÇÃO DOS RECURSOS HUMANOS 79
8.1.1.2 - QUANTIDADE DOS RECURSOS HUMANOS 80
8.1.1.3 - ALOCAÇÃO DOS RECURSOS HUMANOS 80
8.1.1.4 - DESCRIÇÃO SUCINTA DOS RECURSOS HUMANOS 80
8.1.1.5 - CLASSIFICAÇÃO DOS RECURSOS HUMANOS 80
8.1.1.6 - ESPECIFICAÇÃO DOS RECURSOS HUMANOS 81
8.1.1.7 - DESCRIÇÃO DE TAREFAS DOS RECURSOS HUMANOS 81
8.1.1.8 - LISTAGEM INICIAL DOS RECURSOS HUMANOS 81
8.1.1.9 - MATRIZ RACI 81
8.2 - ESTIMATIVA DE EQUIPAMENTOS E RECURSOS FÍSICOS 82
8.2.1 - DESCRIÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS 82
8.2.2 - CONFLITO E SUPERPOSIÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS 83
8.2.3 - SEQUENCIAÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS 83
8.2.4 - DISPÊNDIO DOS EQUIPAMENTOS E RECURSOS FÍSICOS 83
8.2.5 - MODALIDADES DE AQUISIÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS 83
8.2.6 - FORNECEDORES DOS EQUIPAMENTOS E RECURSOS FÍSICOS 84
8.2.7 - RECUPERAÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS 84
8.2.8 - RESPONSABILIDADE SOBRE OS EQUIPAMENTOS E RECURSOS FÍSICOS 85
8.2.9 - TIPOS DE CONTRATO DOS EQUIPAMENTOS E RECURSOS FÍSICOS 85
8.3 - ESTRUTURA ANALÍTICA DE RECURSOS (EAR) 85

UNIDADE 09 – PLANO DE GERENCIAMENTO DOS RISCOS 87

9.1 - GERENCIAMENTO DOS RISCOS 87

9.1.1 - IDENTIFICAR OS RISCOS 88
9.1.1.2 - RISCOS OPERACIONAIS E RISCOS ADMINISTRATIVOS E DE MARKETING 88
9.1.1.3 - RISCOS FINANCEIROS E RISCOS INSTITUCIONAIS E LEGAIS 89
9.2 - REALIZAR A ANÁLISE QUALITATIVA DOS RISCOS 89
9.3 - REALIZAR A ANÁLISE QUANTITATIVA DOS RISCOS 90
9.4 - PLANEJAR RESPOSTAS AOS RISCOS 91
9.4.1 - SEGURO 91
9.4.2 - ABSORÇÃO 92
9.4.3 - DUPLICIDADE 92
9.4.4 - TRANSFERÊNCIA 92
 FGVIDT

9.4.5 - COMPARTILHAMENTO 92
9.4.6 - EMERGÊNCIA PROGRAMADA 92
9.5 PLANO DE CONTINGÊNCIA 93
9.5.1 - ELABORAÇÃO DE UM PLANO DE CONTINGÊNCIA 93

UNIDADE 10 – PLANO DE GERENCIAMENTO DA

QUALIDADE 94

10.1 - CONCEITOS DE GERENCIAMENTO DA QUALIDADE DO PROJETO 94

10.1.1 - SATISFAÇÃO DO CLIENTE 94
10.1.2 - CUSTO DA QUALIDADE 94
10.1.3 - MELHORIA CONTÍNUA 95
10.2 - ETAPAS DO GERENCIAMENTO DE PROJETOS DE QUALIDADE 95
10.2.1 - QUALIDADE DO PLANO 95
10.2.2 - GARANTIA DA QUALIDADE 95
10.2.3 - CONTROLE DE QUALIDADE 96
10.2.4 - FERRAMENTAS DE CONTROLE DA QUALIDADE 96

UNIDADE 11 - PLANO DE GERENCIAMENTO DAS

COMUNICAÇÕES 97

11.1 - GERENCIAMENTO DAS COMUNICAÇÕES 97

11.2. - ESTRUTURA DO PLANO DE GERENCIAMENTO DAS COMUNICAÇÕES 98
11.2.1 - ABORDAGEM DO GERENCIAMENTO DAS COMUNICAÇÕES 98
11.2.2 - RESTRIÇÕES DO GERENCIAMENTO DAS COMUNICAÇÕES 98
11.2.3 - REQUISITOS DE COMUNICAÇÃO DAS PARTES INTERESSADAS 99
11.3 - PRINCIPAIS PAPÉIS NO GERENCIAMENTO DAS COMUNICAÇÕES 100
11.3.1 - PATROCINADOR DO PROJETO 100
11.3.2 - GERENTE DE PROGRAMA 100
11.3.3 - PRINCIPAIS INTERESSADOS 100
11.3.4 - CLIENTES 100
11.3.5 - GERENTE DO PROJETO 100
11.3.6 - EQUIPE DO PROJETO 100
11.3.7 - COMITÊ DE DIREÇÃO 101
11.3.8 - LÍDER TÉCNICO 101
11.4 - MÉTODOS E TECNOLOGIAS DE COMUNICAÇÃO 102
11.5 - DIRETRIZES PARA AS REUNIÕES 103
11.5.1 - AGENDA DA REUNIÃO 103
11.5.2 - ATAS DE REUNIÃO 103
11.6 - PADRÕES DE COMUNICAÇÃO 103
11.7 PROCESSO DE ESCALA DE COMUNICAÇÃO 103
11.8 - MATRIZ DE COMUNICAÇÕES 104

UNIDADE 12 - PLANO DE GERENCIAMENTO DAS

AQUISIÇÕES 106

12.1 ETAPAS DO PLANO DE GERENCIAMENTO DE AQUISIÇÕES 106

12.1.1 - DEFINIR OS TERMOS 106
12.1.2 - ESBOÇO DO TIPO DE ACORDO 106
 FGVIDT

12.1.3 - IDENTIFICAR E MITIGAR RISCOS 106

12.1.4 - DEFINIR CUSTOS 107
12.1.5 - IDENTIFICAR AS RESTRIÇÕES 107
12.1.6 - OBTER A APROVAÇÃO DOS CONTRATOS 107
12.1.7 - CRIAR CRITÉRIOS DE DECISÃO 107
12.1.8 - CRIAR UM PLANO DE GERENCIAMENTO DE FORNECEDORES 107
12.2 - LICITAÇÕES E CONTRATOS 108

UNIDADE 13 - PLANO DE ENGAJAMENTO DAS PARTES

INTERESSADAS 109

13.1 - PARTES DE UM PLANO DE ENVOLVIMENTO DAS PARTES INTERESSADAS 109

13.1.1 - LISTAR AS PARTES INTERESSADAS 109
13.1.2 - CLASSIFICAR AS PARTES INTERESSADAS 110
13.1.3 - ABORDAGEM DE ENGAJAMENTO 112
13.1.4 - APOIO DAS PARTES INTERESSADAS VERSUS RESISTÊNCIA 113

UNIDADE 14 – MONITORAR E CONTROLAR O TRABALHO DO

PROJETO 115

14.1 - EXECUTAR O CONTROLE INTEGRADO DE MUDANÇAS 115

14.2 - VERIFICAR ESCOPO 116
14.3 - CONTROLAR O ESCOPO 116
14.4 - CONTROLAR O CRONOGRAMA 116
14.5 - CONTROLAR OS CUSTOS 117
14.6 - REALIZAR O CONTROLE DE QUALIDADE 117
14.7 - RELATÓRIO DE DESEMPENHO 117
14.8 - MONITORAR E CONTROLAR OS RISCOS 117
14.9 - ADMINISTRAR AS AQUISIÇÕES 117

UNIDADE 15 - REALIZAR O CONTROLE INTEGRADO DE

MUDANÇAS 118

15.1 - IMPLEMENTAÇÃO DE UM CONTROLE INTEGRADO DE MUDANÇAS 119

15.1.1 - PREVENIR A CAUSA-RAIZ DA NECESSIDADE DE MUDANÇAS 119
15.1.2 - OBTER OS REQUISITOS FINAIS O MAIS RÁPIDO POSSÍVEL 119
15.1.3 - IDENTIFICAR CORRETAMENTE OS RISCOS DO PROJETO 120
15.1.4 - PLANEJAR RESERVAS ADICIONAIS DE TEMPO E CUSTOS 120
15.2 - PROCESSOS PARA REALIZAR O CONTROLE INTEGRADO DE
MUDANÇAS 120
15.2.1 - SOLICITAÇÕES DE MUDANÇAS 120
15.2.2 - APROVAÇÃO DE MUDANÇAS 121
15.2.3 - AVALIAR A NECESSIDADE DO PROJETO OU DO NEGÓCIO 121
15.2.4 - INCLUIR SOMENTE AS MUDANÇAS APROVADAS 122

UNIDADE 16 - ENCERRAR O PROJETO OU FASE 123

 FGVIDT

16.1 - FLUXO DE ENTREGAS 123

16.2 - VERIFICAÇÃO DE DOCUMENTOS 123
16.3 - DEMAIS RECURSOS 123
16.4 RELATÓRIO DE LIÇÕES APRENDIDAS 123
16.5 - FECHAMENTO 124

BIBLIOGRAFIA BÁSICA 125

BIBLIOGRAFIA COMPLEMENTAR 126

 FGVIDT

Apresentação

Em todo o mundo, está se tornando cada vez mais comum, a prática da gestão de
projetos nas organizações privadas e públicas.

Elas têm sido pressionadas por apresentarem resultados e expectativas cada vez
maiores, em termos de desempenho em relação ao tempo, custos e qualidade.

Em face dessas exigências modernas, o gerenciamento de projetos vem recebendo

cada vez mais atenção.

E os projetos vêm sendo empregado ao longo da existência humana como forma de

resolução de problemas simples aos complexos.

A preparação de um evento, como uma festa de aniversário, pode ser considerada um

projeto simples.
A descoberta de uma vacina para um vírus desconhecido é considerada um projeto
complexo.
Muitos gerentes de projeto estão ao nosso redor, seja construindo uma casa
personalizada, desenvolvendo um sistema de informação ou pesquisando uma nova droga
contra uma doença.

Por meio da gestão de projetos muitas pessoas estão conduzindo e liderando

mudanças...
Dentre as principais razões das organizações adotarem o gerenciamento de projetos
estão: responder com eficiência e eficácia diante dos desafios das mudanças, dos
orçamentos apertados, dos resultados inadequados, dos clientes insatisfeitos, do alto
estresse gerado no ambiente etc.

A disciplina Gestão de Projetos tem como objetivo apresentar as principais técnicas de

formulação de projetos empregadas em projetos de diferentes setores.

E, para isso, esta apostila foi organizada com a finalidade destacar os principais
fundamentos e conceitos, de forma prática, para que qualquer profissional possa
desenvolver as habilidades e os conhecimentos necessários para trabalhar como membros
de equipes em projetos de forma eficaz.
 FGVIDT

Unidade 01 – PROJETO
O ser humano realiza projetos desde o início de sua existência.

Reconhecemos as grandes obras da antiguidade, como as pirâmides do Egito ou a

Grande Muralha da China como complexos projetos. Com certeza, os líderes daquelas
épocas, gerenciaram recursos, pessoas, tarefas e atividades, dentro de um prazo
determinado, para atingir os objetivos.

Nos dias atuais, preparar um evento, como um workshop, um treinamento ou uma festa
podem ser considerados projetos.

O termo projeto foi incorporado ao nosso vocabulário e o utilizamos com muita

frequência no dia a dia.

Os projetos estão se tornando cada vez mais comuns nas empresas e as expectativas
são cada vez maiores em termos de desempenho relacionados ao tempo de duração, aos
custos e às especificações.
Portanto, é importante conhecer como conduzir os projetos que ajudem as
organizações a atingirem suas expectativas, objetivos e finalidades.
Os projetos estão sempre apertados no prazo e no orçamento. O desafio é saber como
equilibrá-los, junto com a qualidade esperada, para alcançar resultados de sucesso.

1.1 - DEFINIÇÃO DE PROJETO

Um projeto é definido como uma organização transitória, que compreende uma
sequência de atividades dirigidas à geração de um produto ou de um serviço singular em
determinado tempo.

“Projeto é um empreendimento único, que tem por objetivo atingir um resultado claro e
definido, caracterizado por uma sequência de atividades temporárias, dentro de parâmetros
pré-definidos de recursos, tempo, custo e qualidade.”
A NBR ISO 10006 define projeto como um “Processo único, consistindo em um grupo
de atividades coordenadas e controladas com datas de início e término, empreendida para
alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo
e recursos”.

1.2 - CARACTERÍSTICAS DE UM PROJETO

Um projeto:
 FGVIDT

- Tem objetivos e metas definidos para alcançar – o projeto deve entregar produtos,
serviços ou resultados exclusivos: uma saída, ou um produto claramente identificável em
termos de custos, prazos e qualidade. Por exemplo: uma entrega exclusiva, um produto ou
serviço produzido, ou pesquisas desenvolvidas.

- Tem sua elaboração progressiva. O projeto é desenvolvido em etapas e contínuas

e por incrementos. Requer equipes multifuncionais e abordagem interdisciplinar. Por
exemplo: fase 1, fase 2...
- Deve obedecer ao orçamento aprovado. Requer um conjunto de recursos.

- Envolve riscos e incerteza.

- É único por natureza.

- É temporário ou transitório – projeto é um empreendimento não repetitivo, com uma

sequência bem definida de eventos com início e fim. O projeto não é um esforço contínuo.
O ciclo se extingue quando o objetivo é atingido. Transitório se opõe a permanente;
sequência de atividades se opõe a conjunto de atividades; um produto ou serviço singular
se opõe a produtos e serviços e em um tempo dado se opõe a qualquer momento.

Construir um prédio é um esforço temporário que gera um resultado único.

Existem milhares de prédios na cidade, mas cada um teve seu período de
planejamento, execução e encerramento.
Cada prédio é único, cada um tem seu próprio número e fica em um lugar
diferente da cidade.

1.3 - DE ONDE SURGEM OS PROJETOS?

O homem moderno é o homem dentro de organizações. A vida contemporânea é
dominada por organizações grandes, complexas, formais.

A sociedade moderna é uma sociedade de organizações. Nossas vidas são

“construídas” em contextos organizacionais e somos influenciados constantemente pelas
organizações e pelas relações que se estabelecem entre elas.
As organizações têm diferentes visões de tempo e cada uma desenvolve uma
abordagem operacional ou estratégica para cumprir o propósito dela nesse horizonte de
tempo.

Os projetos surgem de uma necessidade de:

- Novas oportunidades de mercado ou retração de mercados;

- Imposições legais de governos;

 FGVIDT

- Necessidades organizacionais;
- Solicitações de clientes;

- Inovações tecnológicas;
- Novos públicos ou retração de públicos;

- Respostas a concorrentes;
- Novas barreiras de mercado;

- Respostas a pressões políticas;

- Maximização de rendimentos;

- Realização das estratégias organizacionais.

Uma empresa pode oferecer, por meio da gestão de projetos, seus serviços ao mercado,
aos governos...

1.4 - PROJETO VERSUS PROCESSO

Um projeto é diferente de um processo, apesar de processos também serem
entendidos como organizações que compreendem uma sequência de atividades complexas
destinadas a entrega de um produto.

Os projetos existem para criar um produto ou serviço que não existia antes. Nesse
sentido, um projeto é único. Único significa que o resultado final é novo; que nunca foi feito
anteriormente.
 FGVIDT

Os processos são organizações perenes e não transitórias e produzem produtos

padronizados e não singulares. Um processo é uma série de ações que provocam um
resultado.
Os projetos são compostos de processos.

Ao longo do projeto podemos identificar duas categorias que se sobrepõem e interagem

entre si:

Os processos de administração de projeto descrevem e organizam o trabalho do

projeto.

Já os processos orientados a produto especificam e criam os produtos do projeto.

Por exemplo, uma montadora de veículos pertence ao ramo de negócios de projetar e
montar carros. Cada modelo de veículo que ela projeta e produz pode ser considerado um
projeto. Os modelos dos veículos diferem uns dos outros em suas características e são
comercializados para pessoas com várias necessidades.
Uma picape atende à uma finalidade e à uma clientela diferente daquela que opta por
um carro de luxo. Esses dois modelos de veículos são projetos únicos, mas na produção, as
atividades de montagem dos veículos são consideradas operações (ou seja, um processo
repetitivo que é seguido pela maioria das marcas e modelos).

Para um banco, construir um prédio para abrigar a sua sede é um projeto.

Para uma construtora, construir prédios é um processo.

Para o banco, a construção de um prédio é uma atividade singular, com início,

meio e fim.

Para a construtora, construir prédios é uma atividade de rotina, repetida

indefinidamente.

1.5 - PROJETO VERSUS SERVIÇOS/OPERAÇÕES

Um projeto é diferente de um serviço, porque os serviços não têm um prazo definido
para acabar. Por exemplo, um órgão público ou um hospital que contrata o serviço de
manutenção de instalações.
 FGVIDT

1.6 - CONVENÇÕES E TÉCNICAS

Ao modelarmos um projeto, devemos aplicar uma série de convenções e de técnicas,
tendo em vista estabelecer a sequência das atividades a serem desenvolvidas; estimar a
provisão, o uso dos recursos e os custos a eles associados; cuidar de sua apresentação
para que possa ser compreendido e aceito; definir o foco, isto é, as finalidades, o objetivo, o
produto ou o serviço a ser gerado; esclarecer sua inserção no contexto em que terá lugar,
isto é, as relações entre o projeto e a economia, a sociedade e as organizações.

A elaboração é a instância técnica inicial de um projeto. As demais instâncias são a

administração e a avaliação, a qual compreende a monitoração, a análise e o julgamento.

A administração do projeto engloba os conhecimentos, as habilidades, as

ferramentas e as técnicas necessárias à condução de um projeto devidamente
configurado.
A elaboração tem como escopo a preparação para outras etapas.

Um projeto está bem elaborado quando é administrável e passível de avaliação, ou

seja, quando estão claramente expostas as atividades, os objetivos, o tempo e os recursos
requeridos, bem como as condições de gestão para que o projeto se complete.
Além disso, precisamos que as condições de gestão sejam monitoradas, analisadas e
que tenham um julgamento.

A administração do projeto não se confunde com a administração por

projetos, que é uma variante da administração por objetivos em que as operações da
organização são conduzidas como projetos.
 FGVIDT

1.6.1 - CICLO DE VIDA DOS PROJETOS

O ciclo de vida de um projeto é a sequência de fases pelas quais um projeto passa
desde o início até o encerramento.
O número e a sequência de fases do ciclo são determinados pela gestão e vários outros
fatores, como as necessidades da organização envolvida no projeto, a natureza do projeto
e sua área de aplicação.

As fases têm um início, um fim e um ponto de controle definidos e são limitadas pelo
tempo.

O ciclo de vida do projeto pode ser definido e modificado de acordo com as

necessidades e aspectos da organização.

Mesmo que cada projeto tenha um início e um fim definidos, os objetivos, entregas e
atividades específicas variam amplamente.
O ciclo de vida fornece a base básica das ações que devem ser executadas no projeto,
independentemente do trabalho específico envolvido.

1.6.2 - CARACTERÍSTICAS DO CICLO DE VIDA DOS PROJETOS

No início, os níveis de custo e de pessoal são baixos e atingem um pico quando o
projeto está em andamento. Em seguida, ele novamente começa a cair rapidamente
conforme o projeto se direciona ao fim.

A curva típica de custo e equipe não se aplica a todos os projetos. Despesas

consideráveis podem ser necessárias para garantir os recursos essenciais no início do ciclo
de vida.
O risco e a incerteza estão em seu pico no início do projeto. Esses fatores diminuem
ao longo do ciclo de vida do projeto à medida que as decisões são tomadas e as entregas
são aceitas.
 FGVIDT

A capacidade de afetar o produto final do projeto sem impactar drasticamente o custo

é maior no início do projeto e diminui à medida que o projeto avança para a conclusão.

1.6.3 - BENEFÍCIOS DO CICLO DE VIDA DO PROJETO

O conhecimento adequado sobre o ciclo de vida do projeto beneficia as organizações
da seguinte forma:

- Ajuda as equipes a serem mais eficientes e lucrativas.

- Ajuda a organização a atingir seus propósitos.

- Torna o fluxo de comunicação mais fácil.

- Se baseia na experiência de projetos anteriores.

1.6.4 - FASES DO PROJETO

O gerenciamento de projetos baseia-se na ideia de que um projeto passa por uma série
de fases caracterizadas por um conjunto distinto de atividades ou tarefas que levam o projeto
da concepção à conclusão. Isso tem por finalidade melhorar as atividades de controle e de
qualidade e dividir o projeto em estágios mais gerenciáveis, cada um com uma entrega
específica, e feito em uma sequência específica.

No final de cada fase, normalmente, é realizada uma revisão da entrega e do

desempenho da equipe do projeto. Desta forma, a equipe poderá determinar se o projeto
segue para a próxima fase ou se passa por uma revisão.
Ao acompanhar o projeto por fases, determina-se como melhorar o desempenho de
todos os envolvidos.
Ao todo, as fases de um projeto são conhecidas como o Ciclo de Vida do Projeto.

1.6.5 - OBJETIVO DO PROJETO

O objetivo do projeto é o produto ou serviço que estará disponível quando o projeto
estiver concluído.
O objetivo do projeto é, muitas vezes, bem distinto do produto/serviço, mas, outras
 FGVIDT

vezes, se confunde com ele.

Esse aparente paradoxo fica mais claro se utilizarmos alguns exemplos...

Suponhamos que um projeto de intervenção em uma organização tenha como

produto a organização reestruturada.

A finalidade última da reestruturação, ou seja, seu propósito, poderá ser a diminuição

de custos da organização.

Contudo, o objetivo do projeto – reestruturar a organização – e o produto – organização

reestruturada – são quase a mesma coisa.

1.6.6 - DURAÇÃO DO PROJETO

Há casos em que não é necessária uma técnica para definirmos o produto/serviço do
projeto.
Trata-se, na realidade, de um contínuo. Pode ser que haja casos em que a definição
de objetivos é imediata, outros em que a maioria é problemática e outros ainda em que o
produto/serviço não pode ser definido.

Isso significa que existem projetos com produtos/serviços indeterminados.

Esses são casos excepcionais. Em geral, são projetos de pesquisa ou projetos no setor
cultural.
Por exemplo, poderíamos precisar um produto para uma pesquisa que ainda não
iniciamos? Como definir o produto de uma pesquisa que visa descobrir um remédio se não
sabemos se o remédio existe? Como definir o produto de uma escavação arqueológica se
podemos não ter mais do que montes de terra deslocados inutilmente?
A resposta é simples – pela duração do projeto.

Outro exemplo, um projeto de pesquisa médica. Na impossibilidade de saber se

encontraremos a cura de uma enfermidade – a solução para o problema – e se queremos
configurar a pesquisa utilizando os recursos técnicos da modelagem, devemos nos voltar
para a segunda condicionante dos projetos, ou seja, a duração.

1.7 - CARACTERÍSTICAS DOS PROJETOS BEM

SUCEDIDOS
Um projeto bem-sucedido, praticamente é aquele que:
- produziu todas as entregas planejadas;

- foi completado dentro do cronograma aprovado;

- foi executado dentro do orçamento aprovado;

- foi entregue de acordo com todas as especificações funcionais, de performance e de

 FGVIDT

qualidade;
- alcançou todas as suas metas, objetivos e propósitos;

- atingiu todas as expectativas das partes interessadas;

- está alinhado com os objetivos da organização;

- tem o apoio efetivo da alta administração;

- tem uma liderança efetiva;

- todas as partes interessadas estão de acordo com o propósito, as metas e os objetivos

do projeto;

- todas as partes interessadas compartilham uma visão comum dos resultados e têm
expectativas realistas a respeito do projeto;

- as expectativas das partes interessadas são continuamente gerenciadas e validadas

no decorrer do projeto;

- o escopo, a abordagem e as entregas do projeto são claramente definidos e

acordados durante o seu planejamento;

- o papel e a responsabilidade de cada parte interessada e de membros da equipe do

projeto são claramente comunicados e entendidos;

- o cronograma é realista e acordado entre todas as partes interessadas;

- as comunicações do projeto são consistentes, efetivas e focadas no entendimento;

- o progresso do projeto é medido frequentemente em relação à uma linha de base;

- um forte senso de colaboração e trabalho em grupo é alcançado;
- as expectativas e mudanças em relação a escopo, cronograma, custos e qualidade
são gerenciadas cuidadosamente;
- os recursos humanos do projeto são capacitados e estão disponíveis quando
necessário;
- a equipe do projeto identifica proativamente seus riscos e trata essas vulnerabilidades
diminuindo a sua exposição.
Resumindo, um projeto concluído no prazo e dentro do orçamento pode ser
considerado um sucesso. No entanto, um projeto também deve ser avaliado sob as óticas
de:

Ele atende aos requisitos de negócios?

Ele foi entregue dentro do prazo e do orçamento?

Ele entrega o valor esperado e o Retorno sobre o Investimento (ROI)?

 FGVIDT

1.8 - ERROS COMUNS NA GESTÃO DE

PROJETOS
Entre os erros mais comuns na Gestão de Projetos estão:
- o não entendimento do alinhamento do projeto com a organização;

- a falta de gerenciamento das expectativas das partes interessadas em relação ao

projeto;
- a falta de acordo das partes interessadas em relação aos fatores de sucesso do
projeto;
- a falta de um cronograma realista, em que fatores como quantidade de trabalho,
dependências obrigatórias, estimativas de custos e nivelamento de recursos tenham sido
previstos;

- a falta de definição e comunicação sobre as responsabilidades da equipe do projeto;

- a falta de aceitação formal do cronograma do projeto;

- a falta de identificação preliminar de riscos para o projeto;

- a falta de recursos humanos capacitados e disponíveis para trabalhar no projeto;

- a falta de definição de requerimentos e escopo do projeto;

- a inadequação do gerenciamento e liderança da equipe do projeto.
 FGVIDT

Unidade 02 – GERENCIAMENTO DE
PROJETOS
2.1 - O QUE É GERENCIAMENTO DE PROJETOS?
O Gerenciamento de Projetos é a aplicação do conhecimento, habilidades,
ferramentas e técnicas à eventos não repetitivos, únicos e complexos, a fim de satisfazer as
necessidades e expectativas dos interessados de um projeto.
É também uma forma sistemática de fazer com que um trabalho seja feito e por isso
envolve a coordenação, organização e controle das atividades de um grupo, para que seja
possível atingir um objetivo dentro do tempo, custo e desempenho esperados.

A tarefa central do gerenciamento de projetos sempre foi a combinação do trabalho de

diferentes pessoas para a execução de tarefas que seriam úteis para os clientes ou as
organizações.
O gerenciamento de projetos foi criado há mais de cinquenta anos para administrar o
desenvolvimento técnico e os projetos de fabricação de grande complexidade.
Mesmo na atualidade, muitas pessoas pensam em gerenciamento de projetos como
uma série de gráficos, tabelas e procedimentos implementados por meio de um pacote de
software cujo objetivo é planejar e concluir um trabalho repetitivo e previsível, ou preencher
as horas vagas de burocratas aborrecidos.
O gerenciamento de projetos evoluiu ao longo dos anos e, atualmente, é mais do que
uma disciplina técnica e misteriosa.
O gerenciamento de projetos inclui uma série de princípios cujo objetivo é fornecer uma
abordagem estruturada para a tomada das decisões diárias que mantêm um negócio em
andamento, mesmo que seja um pequeno negócio ou um laboratório.

2.2 - PROCESSOS DE GERENCIAMENTO DE

PROJETOS
2.2.1 - GERENCIAMENTO DE PORTFÓLIO
É o processo sistemático pelo qual a organização avalia as oportunidades existentes,
transformando-as em projetos mediante a avaliação de seu alinhamento à estratégia da
empresa, valor que gera para a organização, o risco e a capacidade de execução. O
gerenciamento de portfólio reforça o apoio executivo e é responsável por fazer a avaliação,
em longo prazo, do atendimento de objetivos de negócio pelos projetos e programas.
 FGVIDT

A gestão de portfólio é a seleção, priorização e controle dos programas e

projetos de uma organização, de acordo com seus objetivos estratégicos e
capacidade de entrega.

2.2.2 - GERENCIAMENTO DE PROGRAMAS

Programas são conjuntos de projetos e iniciativas que têm objetivos comuns e que
precisam ser coordenados entre si. O gerenciamento de programas cuida do
compartilhamento de recursos e do capital intelectual entre os projetos, bem como do
gerenciamento dos riscos globais.

Um programa é um esforço estratégico único e temporário realizado para

alcançar mudanças benéficas e para incorporar um grupo de projetos
relacionados e atividades normais de negócios.

2.2.3 - GERENCIAMENTO DE PROJETOS

O Gerenciamento de Projetos tem como objetivo principal viabilizar a entrega de
projetos individuais que atendam às especificações de prazo, escopo, custo e qualidade
acordadas com o cliente.

Um projeto é um esforço temporário empreendido para criar um produto, serviço ou

resultado exclusivo.

Um subprojeto é uma subdivisão dentro de um projeto de escopo amplo e complexo.

Exemplos:

- O Ministério da Saúde tem em seu Portfólio vários programas, como O Programa

Nacional de Imunização, Farmácia Popular do Brasil, Promoção da Saúde e Prevenção de
Riscos e Doenças, dentre outros.
- O Programa Nacional de Imunização tem projetos experimentais de vacinas.

- Um projeto de implantação do subsistema de controle de estoque e distribuição de

imunobiológicos tem subprojetos...

Em síntese:
O portfólio é uma coleção de projetos, programas e outras atividades agrupadas para
a obtenção dos objetivos estratégicos da organização. Eles podem ou não compartilhar
recursos, mesmo fazendo parte da estratégia organizacional.
Os programas são grupos de projetos que têm objetivos em comum e podem
compartilhar os mesmos recursos e serem administrados de forma coordenada para garantir
benefícios e controles não disponibilizados por projetos individuais.
FGVIDT
 FGVIDT

Unidade 03 – METODOLOGIAS DE
GERENCIAMENTO DE PROJETOS
Não existem dois projetos exatamente iguais!

Mesmo quando são usados modelos de projetos anteriores, considerando as diferentes

metas, indicadores (KPIs), objetivos e métodos de produção não apenas de diferentes tipos
de equipes, mas também de diferentes tipos de segmentos de indústrias, faz sentido que
não haja uma abordagem única para o gerenciamento de um projeto.

O projeto que pode ser adequado para uma empresa e uma equipe, pode não funcionar
melhor para outro tipo de equipe.

Ao longo do tempo muitos desenvolvedores de software perceberam que os métodos

tradicionais de gerenciamento de projetos estavam atrapalhando - em vez de ajudar – nos
seus fluxos de trabalho, afetando e impactando negativamente o desempenho e resultados.
A partir dessa percepção, as equipes de desenvolvimento de software desenvolveram
uma nova metodologia de gerenciamento de projetos, que foi projetada para atender às
suas preocupações específicas.

Em pouco tempo, outras equipes e setores começaram a adaptar esses novos

métodos de gerenciamento de projetos para atender às suas necessidades e preocupações
exclusivas.
Dessa forma, diferentes metodologias de gerenciamento de projeto foram
reaproveitadas, modificadas e adaptadas para os diferentes setores e ajustadas para se
adequar a casos de uso específicos.

3.1 - PRINCIPAIS METODOLOGIAS DE

GERENCIAMENTO DE PROJETOS
No mundo atual de gerenciamento de projetos, muitas empresas não aderem à uma
única metodologia - elas procuram combinar várias práticas para acomodar tudo o que o
projeto exige.

Não existe uma metodologia “certa”.

Existem metodologias que atendem às necessidades das empresas de acordo

com o segmento do negócio ou a indústria a que ela pertence.
 FGVIDT

As diferentes metodologias de gerenciamento de projetos têm seus próprios fatores

prós e contras para diferentes tipos de projetos. Alguns são voltados para velocidade de
resolução de problemas, outros para maior abrangência.
A metodologia escolhida pela empresa terá um impacto profundo e contínuo em como
ela trabalha, entrega e acompanha os resultados.

3.1.1 - METODOLOGIAS ÁGEIS

3.1.1.1 - ÁGIL
A metodologia Ágil de gerenciamento de projetos tem seu principal foco no
desenvolvimento de software e sistemas.

Ela surgiu como uma resposta à falha do método em cascata para gerenciar projetos
complexos. Embora as ideias de gerenciamento de projetos Ágeis já estivessem em uso na
indústria de software por um bom tempo, elas passaram a existir formalmente em 2001,
quando vários representantes de TI lançaram o "Manifesto Ágil".

Como o nome indica, esse método favorece uma abordagem rápida e flexível. Não há
coleta de requisitos pesados. Em vez disso, ela é iterativa com pequenas mudanças
incrementais que respondem às mudanças de requisitos.
Essa metodologia é mais adequada para projetos que requerem flexibilidade e têm
elevado nível de complexidade ou incerteza. Por exemplo, um produto ou serviço que ainda
não foi desenvolvido pela equipe da empresa.

As metodologias Ágeis mais conhecidas são: Extreme Programming (XP), Scrum, Lean
Development, Feature-Driven Development (FDD), Kanban, RUP, Crystal, Dynamic Systems
Development Method (DSDM) e OpenUP.
Vantagens

Flexibilidade e liberdade: como não há estágios fixos ou foco nos requisitos, isso dá
aos seus recursos muito mais liberdade para experimentar e fazer mudanças incrementais.
Isso a torna particularmente adequada para projetos criativos.
Com o gerenciamento Ágil, obtém-se o feedback regular das partes interessadas e faz
as alterações necessárias. Isso reduz drasticamente o risco de falhas do projeto, uma vez
que as partes interessadas estão envolvidas em todas as etapas.
Desvantagens

Não possui um plano fixo: a abordagem Ágil enfatiza a resposta às mudanças conforme
elas ocorrem.

Essa falta de um plano fixo torna o gerenciamento de recursos e a programação mais

difíceis.
 FGVIDT

Exige colaboração intensa: a falta de um plano fixo significa que todos os

departamentos envolvidos - incluindo as partes interessadas e patrocinadores - terão que
trabalhar em estreita colaboração para entregar resultados.
A abordagem com foco no feedback também significa que as partes interessadas
devem estar dispostas (e disponíveis) para oferecer esse feedback rapidamente.
O conceito de gerenciamento ágil de projetos passou a despertar várias subestruturas
e metodologias específicas, como Scrum, Kanban e Lean.
E todas elas têm em comum os seguintes princípios-chave das metodologias de
gerenciamento de projetos ágeis:
- É colaborativa.

- É rápida.
- Está aberta a mudanças, é baseada em dados.
As metodologias ágeis de gerenciamento de projetos, geralmente, envolvem fases
curtas de trabalho com testes, reavaliações e adaptações frequentes.

Em muitos métodos ágeis, todo o trabalho a ser feito é adicionado a um backlog (pilha
de pedidos ou demandas) que as equipes podem trabalhar em cada fase ou ciclo, com os
gerentes de projeto ou proprietários do produto priorizando o backlog para que as equipes
saibam no que se concentrar primeiro.

Quando usar a metodologia de gerenciamento de projetos ágeis:

a) Se o projeto estiver sujeito a mudanças.
b) Se não houver certeza de como será a solução.

c) Se houver a necessidade de trabalhar rapidamente e se for mais importante ver e

acompanhar um progresso rápido do que ter resultados finais perfeitos.

d) Se os stakeholders (interessados) ou os clientes precisarem (ou desejarem) estar

envolvidos em todas as fases.

Quando NÃO usar a metodologia de gerenciamento de projetos ágeis:

a) Se precisar preparar muita documentação (ou se houver necessidade de incluir
novas pessoas durante o projeto).
b) Se precisar realizar entregas previsíveis e precisar ser muito claro e objetivo sobre
os requisitos desde o início.
c) Se o projeto não pode se dar ao luxo de enfrentar mudanças durante o curso.

d) Quando não houver pessoas automotivadas na equipe.

e) Quando os prazos do projeto são rígidos ou os resultados finais precisam estar em
 FGVIDT

dia e atrelados ao cronograma.

3.1.1.2 - SCRUM
Scrum é uma forma ágil de gerenciamento de projetos, mas não é uma metodologia de
gerenciamento de projetos completa.

Embora tome emprestados os princípios e processos do Manifesto Ágil, o Scrum tem

seus próprios métodos e táticas específicas para lidar com o gerenciamento de projetos.

Ela descreve uma abordagem de gerenciamento ágil com foco em equipes de projeto.
O trabalho é dividido em ciclos curtos conhecidos como “sprints” (chegadas) curtas que
geralmente duram cerca de 1-2 semanas.
O trabalho é obtido do backlog (pilha de pedidos ou demandas) para cada iteração de
sprint.
A abordagem Scrum é melhor para equipes de projeto altamente experientes,
disciplinadas e motivadas que podem definir suas próprias prioridades e entender os
requisitos do projeto claramente.

A abordagem Scrum coloca a equipe do projeto na frente e no centro do projeto.

Frequentemente não há Gerente do Projeto. Em vez disso, espera-se que a equipe seja
auto-organizada e autogerenciada. Isso a torna ideal para equipes altamente focadas e
qualificadas, mas não tanto para outras.

Ela tem todas as falhas do método Ágil junto com todos os seus benefícios. Funciona
para projetos grandes, mas falha se a própria equipe do projeto for muito grande.

"Ágil é a filosofia e Scrum a metodologia.

Enquanto Scrum é Ágil, Ágil não é Scrum."

Vantagens

Scrum “sprints”: A abordagem Scrum é fortemente focada em “sprints” de 30 dias. Por

meio desse processo as equipes do projeto dividem uma lista de desejos de objetivos finais
em pequenos pedaços e, em seguida, trabalham com eles em sessões de 30 dias com
reuniões diárias em pé. Isso facilita o gerenciamento de projetos grandes e complexos.
Ritmo rápido: a abordagem “sprint” com seu limite de 30 dias e reuniões diárias em pé
promove a iteração e desenvolvimento rápidos e feedback regular das partes interessadas.
Foco na equipe: Uma vez que se espera que a equipe do projeto gerencie a si mesma,
as equipes Scrum têm uma visibilidade clara do projeto. Isso também significa que os líderes
de projeto podem definir suas próprias prioridades de acordo com seu próprio conhecimento
de suas capacidades.
 FGVIDT

Desvantagens
Aumento do escopo: Como não há data de término fixa, nem um Gerente do Projeto
para agendamento e orçamento, Scrum pode facilmente levar ao aumento do escopo.
Risco mais alto: como a equipe do projeto é autogerenciada, há um risco maior de
fracasso, a menos que a equipe seja altamente disciplinada e motivada. Se a equipe não
tiver experiência suficiente, Scrum tem uma chance muito alta de fracasso.

Falta de flexibilidade: O foco da equipe do projeto significa que qualquer recurso que
deixar a equipe intermediária terá um impacto enorme nos resultados. Essa abordagem
também não é flexível o suficiente para equipes grandes.

3.1.1.3 - KANBAN
Kanban é outra metodologia derivada do ambiente Ágil e é semelhante ao Scrum
porque se concentra em lançamentos iniciais com equipes colaborativas e autogerenciadas.

Seu conceito foi desenvolvido na linha de produção das fábricas da Toyota, na década
de 1940.

É um método bastante visual que visa entregar resultados de alta qualidade mostrando
um quadro do processo de fluxo de trabalho (workflow) para que os gargalos possam ser
identificados no início do processo de desenvolvimento.
O método Kanban alcança eficiência usando pistas visuais que sinalizam vários
estágios do processo de desenvolvimento. As dicas envolvidas no processo são um quadro
Kanban, cartões Kanban e até mesmo raias Kanban para quem procura um pouco mais de
 FGVIDT

organização.
Quadro Kanban: é usado para visualizar o processo de desenvolvimento. Um quadro
Kanban pode ser físico (um quadro branco, notas adesivas e marcadores) ou digital.

Cartões Kanban: Cada cartão Kanban representa um item de trabalho ou tarefa no

processo de trabalho. Eles são usados para comunicar o progresso à equipe e representa
as informações como status, tempo de ciclo e prazos iminentes.

Identificador único de TICKET # 0930

número de atividade
Pessoa responsável
Realizar o pedido de material pela atividade
Resumo da atividade de consumo João

Flag vermelha indica

Tempo estimado para (2) atividade crítica
resolução da atividade

Raias Kanban: as raias Kanban são um elemento visual no quadro que permitem
distinguir as tarefas ou itens, categorizando-os. Seu objetivo é oferecer uma visão geral
melhor do fluxo de trabalho.

3.2 - METODOLOGIA EM CASCATA (WATERFALL)

A metodologia em Cascata é uma das mais tradicionais utilizada no gerenciamento de
 FGVIDT

projetos. Ela é uma abordagem de projeto linear e sequencial, onde o progresso flui para
baixo em uma direção - como uma cascata.

Seu princípio é de que só se pode passar para a próxima fase de desenvolvimento

depois que a fase atual tiver sido concluída e enfatiza a importância da documentação. A
ideia é que se um membro da equipe saísse durante o processo de desenvolvimento, sua
substituição poderia começar do ponto onde parou, familiarizando-se com as informações
fornecidas nos documentos.
Foi muito utilizada no desenvolvimento de software, mas como apresentava problemas
devido às restrições de design e à falta de feedback do cliente durante o processo de
desenvolvimento, passou a ser substituída por outras metodologias, porque quando havia
mudanças no escopo do projeto podia interromper o fluxo de trabalho e ocasionar
transtornos.

Apesar de ser considerada uma metodologia tradicional e amplamente empregada em

setores de fabricação ou construção, ela não pode ser considerada flexível.

É mais adequada para projetos grandes e que requerem a manutenção de estágios e

prazos rigorosos ou projetos que foram feitos várias vezes em que as chances de surpresas
durante o processo de desenvolvimento são relativamente baixas.

3.3 - PRINCE 2 (PROJECT IN CONTROLLED

ENVIROMENT)
PRINCE2 (Projetos em ambientes controlados) é a metodologia oficial de
gerenciamento de projetos do governo do Reino Unido (o que significa que a maioria dos
projetos do governo do Reino Unido a utiliza).

Essa metodologia é mais adequada para projetos grandes e complexos com requisitos
fixos.

A metodologia PRINCE2 é baseada em 7 princípios, 7 temas e 7 processos.

Os 7 princípios PRINCE2, por exemplo, são:

- Justificativa de negócios contínua

- Aprenda com a experiência

- Funções e responsabilidades definidas

- Gerenciar por estágios

- Gerenciar por exceção

- Foco em produtos

- Adaptada para se adequar ao ambiente do projeto

 FGVIDT

Vantagem
Um projeto PRINCE2 requer documentação extensa. Além disso, um dos princípios
orientadores da metodologia PRINCE2 é "Aprender com a experiência". Esse foco na
documentação e na experiência anterior pode ajudar a reduzir o risco.

Desvantagem
A desvantagem da extensa documentação do PRINCE2 é que as alterações podem
ser difíceis de acomodar. Se os requisitos mudarem, será necessário refazer a
documentação e realocar recursos, o que pode prejudicar o andamento do projeto.

3.4 - CANVAS ADAPTADO A PROJETOS

(PROJECT MODEL CANVAS)
A metodologia CANVAS adaptada a Projetos foi baseada no Design Thinking e no
Business Model Canvas.

O metódo foi elaborado pelo professor José Finnochio, a partir da metodologia proposta
Business Model Generation (BMG) e apresenta uma diagramação visual que permite avaliar
todo o projeto, integrando escopo, tempo, requisitos, stakeholders etc, por meio da intuição
e sensibilidade daquilo que será planejado posteriormente.

O Canvas adaptado a Projetos prevê a criação de um novo projeto a partir das

respostas às perguntas: Por quê? O quê? Quem? Como? Quando e quanto?

A confecção de um quadro com essas respostas é o ponto de partida para a criação

do canvas, obtendo a visualização gráfica de todo o projeto e facilitando sua compreensão
e as justificativas de cada etapa.
Este modelo derruba o mito que há em muitas empresas de que a modelagem e
configuração de projetos é algo muito complexo.
O espaço de trabalho apresenta a disposição das perguntas em balões interligados,
para que os membros da equipe do projeto possam compartilhar o conhecimento sobre o
problema a ser resolvido.

Ao final, a visualização gráfica permitirá que todos tenham o entendimento amplo do

projeto e como poderá ser resolvido.

Veja, em seguida, um modelo CANVAS adaptado a Projetos.

 FGVIDT

POR QUE? O QUE? QUEM? COMO? QUANDO/QUANTO?

Produto Stakeholders Premissas Riscos

Justificativa
externos

Obj SMART Requisitos

Linha do Tempo
Equipe Grupo de Entrega

Benefícios

Restrições Custos

Preenchimento do Canvas:

Justificativa: apresentar os argumentos que indicam a necessidade e oportunidade

do projeto, se há algum projeto antecedente que o justifique e defender sua importância.

Objetivos Smart (Inteligentes):

- Específico; (Specific)

- Mensurável; (Mesurable)
- Alcançável; (Atteinable)

- Realista; (Realistic)
- Temporal. (Time Based)

Benefícios: liste os benefícios intangíveis esperados, de médio prazo e obtidos após

o término do projeto.

Produto: Explicar, brevemente, o que o projeto ou o produto do projeto pretende

entregar ao final.

Requisitos: Apresentar as especificações necessárias esperadas pelas partes

interessadas ao receber o produto/serviço.

Stakeholders (Interessados): Indicar as partes interessadas mais relevantes ao

projeto: clientes, beneficiários, usuários, envolvidos e afetados.
 FGVIDT

Equipe: Indicar o nome e posição do patrocinador (sponsor), do gerente do projeto e a

composição da equipe formada.

Restrições: Listar as limitações ou condições obrigatórias a serem seguidas na

execução.

Premissas: Listar as suposições consideradas verdadeiras e necessárias para

viabilizar o projeto.

Riscos: Identificar os possíveis riscos com base nas fases/atividades do ciclo de vida
do projeto que podem causar crises e levar o projeto ao insucesso.

Grupo de Entrega: Listar as estratégias de execução, as fases e as atividades que

levam o projeto da concepção à conclusão: projeto-piloto, implantação e pós-implantação.

Linha do Tempo: Apresentar as datas em que devem ocorrer as entregas.

Custos: Estimar ou calcular os custos de acordo com as atividades previstas nas
entregas ou grupos de entregas.

3.5 - PROJECT MANAGEMENT BODY OF

KNOWLEDGE (PMBOK)
O PMBOK é um guia e um padrão de conceitos-chaves que reúne o conhecimento em
gerenciamento de projetos do Instituto de Gerenciamento de Projetos - Project Management
Institute (PMI).

Como guia, ele consolida todas as boas práticas em gerenciamento de projetos

conhecidas e ratificadas como bem sucedidas.
A sétima edição do PMBOK (2021) apresenta uma estrutura baseada em princípios
que resume o quê é e o porquê do gerenciamento de projetos.

O guia define oito domínios de desempenho do projeto como grupos de atividades

relacionadas que são críticas para a entrega efetiva dos resultados do projeto.

O Padrão para Gerenciamento de Projetos do PMBOK foi construído em torno de um

conjunto de declarações que orientam as ações e comportamentos dos profissionais de
gerenciamento de projetos, independentemente da abordagem de desenvolvimento.

3.5.1 - DOMÍNIOS DE DESEMPENHO DO PROJETO

Um Domínio de Desempenho do Projeto é definido como um grupo de atividades
relacionadas que são críticas para a entrega efetiva dos resultados do projeto.
 FGVIDT

Domínios de Desempenho do Projeto da 7ª Edição do PMBOK

3.5.1.1 – PARTES INTERESSADAS

O Domínio das Partes Interessadas aborda as atividades e funções associadas com
as partes interessadas. A interação eficaz das partes interessadas contribui para o sucesso
e os resultados do projeto. O envolvimento das partes interessadas inclui a implementação
de estratégias e ações para promover o envolvimento das partes interessadas nas tomadas
de decisão do projeto.

3.5.1.2 – EQUIPE
O Domínio da Equipe contempla as atividades e as funções associadas às pessoas
responsáveis pela produção das entregas do projeto. A equipe do projeto é representada por
um conjunto de indivíduos que executam o trabalho do projeto para atingir seus objetivos. O
ambiente de trabalho pode promover o desenvolvimento da equipe, encorajando
comportamentos de liderança de toda a equipe do projeto e dos membros da equipe para a
obtenção dos resultados.

3.5.1.3 – CICLO DE VIDA

O Domínio do Ciclo de Vida aborda as atividades e as funções associadas ao
desenvolvimento, à cadência e fases do ciclo de vida do projeto.

As entregas do projeto determinam a abordagem de desenvolvimento, como uma

abordagem preditiva, adaptativa ou abordagem híbrida.

A cadência das entregas e a abordagem do desenvolvimento do projeto influenciam o

ciclo de vida e suas fases.

3.5.1.4 – PLANEJAMENTO
O Domínio de Planejamento contempla as atividades e funções associadas e
 FGVIDT

necessárias para a entrega e obtenção dos resultados. O planejamento organiza, elabora e

coordena o trabalho ao longo do projeto.

3.5.1.5 – INCERTEZA E AMBIGUIDADE

O Domínio da Incerteza e Ambiguidade aborda as atividades e funções associadas
com risco e incerteza. Os projetos existem em ambientes com graus variados de incerteza
e a incerteza apresenta ameaças e oportunidades que as equipes de projeto exploram e
avaliam e, em seguida, decidem como lidar.

3.5.1.6 – ENTREGA
O Domínio da Entrega contempla as atividades e funções associadas à entrega do
escopo e da qualidade que o projeto foi realizado para alcançar. Os projetos apoiam a
execução da estratégia e o avanço dos negócios. Os projetos agregam valor aos negócios,
desenvolvendo novos produtos ou serviços ou resolvendo problemas.

3.5.1.7 – DESEMPENHO
O Domínio do Desempenho aborda as atividades e funções associadas à avaliação
do desempenho do projeto e contempla as medidas adequadas para manter o desempenho
aceitável. A medição do desempenho envolve avaliar o desempenho do projeto e
implementar as respostas apropriadas para avaliar se as entregas do projeto e o
desempenho estão atingindo os resultados pretendidos.

3.5.1.8 – TRABALHO DO PROJETO

O Domínio do Trabalho do Projeto aborda as atividades e funções associadas ao
estabelecimento de processos de projeto, gerenciando os recursos físicos e promover um
ambiente de aprendizagem. O trabalho do projeto está associado ao estabelecimento dos
processos e operações para manter trabalho em funcionamento e para permitir que a equipe
do projeto possa entregar o valor e os resultados esperados. O trabalho do projeto inclui a
comunicação, o engajamento, o gerenciamento dos recursos, as aquisições e outros
trabalhos para manter as operações do projeto funcionando sem problemas.

3.5.2 – PRINCÍPIOS DO GERENCIAMENTO DE PROJETOS

Os princípios servem como diretrizes fundamentais para a estratégia, a tomada de
decisão e para a solução de problemas. Os princípios de gerenciamento de projetos não são
de natureza prescritiva e destinam-se a orientar o comportamento das pessoas envolvidas
nos projetos.
Os 12 Princípios de Gerenciamento de Projetos estão alinhados com os valores
identificados no Código de Ética e Conduta Profissional do PMI.

3.5.2.1 – 1º Princípio - Stewardship

“Seja como um servidor diligente, respeitoso e atencioso”.
Agir com responsabilidade para realizar as atividades com integridade, cuidado e
confiabilidade, mantendo a conformidade com as diretrizes internas e externas,
 FGVIDT

demonstrando compromisso com os impactos financeiros, sociais e ambientais dos projetos.

3.5.2.2 - 2º Princípio – Equipe

“Crie um ambiente colaborativo com seu time”.
Os projetos são entregues por equipes. As equipes de projeto trabalham dentro de
culturas organizacionais e profissionais e
diretrizes, muitas vezes estabelecendo sua própria cultura “local”.

Um ambiente de equipe de projeto colaborativo facilita:

• o alinhamento com outras culturas e diretrizes organizacionais;

• o aprendizado e o desenvolvimento individual e em equipe; e

• as contribuições ideais para entregar os resultados desejados.

3.5.2.3 - 3º Princípio – Partes Interessadas

"Engaje efetivamente com os stakeholders para entender seus interesses e
necessidades (abordagem colaborativa)".
As partes interessadas influenciam os projetos, o desempenho e os resultados. As
equipes de projeto atendem a outras partes interessadas, engajando-se com elas. O
envolvimento das partes interessadas promove proativamente a entrega de valor.

3.5.2.4 - 4º Princípio – Foco em Valor

“Avalie continuamente e ajuste o alinhamento do projeto aos objetivos de negócios e
benefícios e valor pretendidos”.
O valor percebido é o indicador final do sucesso do projeto e pode ser percebido ao
longo do projeto, no final do o projeto, ou depois que o projeto for concluído.
O valor e os benefícios que contribuem para o resultado final podem ser definidos em
termos quantitativos e/ou qualitativos. As equipes de projeto avaliam o progresso e se
adaptam para maximizar o valor esperado.

3.5.2.5 - 5º Princípio – Pensamento Holístico

“Reconheça, avalie e responda à dinâmica e circunstâncias dos ambientes interno e
externo”.
O pensamento sistêmico envolve ter uma visão holística de como o projeto e suas
partes interagem entre si e com os sistemas externos. Os sistemas estão em constante
mudança, exigindo atenção consistente às condições internas e externas. Ser responsivo às
interações do sistema permite que as equipes de projeto alcancem resultados positivos.

3.5.2.6 - 6º Princípio - Liderança

“Demonstre e adapte os comportamentos de liderança para apoiar as necessidades
individuais e da equipe”.
 FGVIDT

A liderança eficaz promove o sucesso do projeto e contribui alcançar resultados

positivos do projeto. Qualquer membro da equipe do projeto pode demonstrar
comportamentos de liderança. Líderes eficazes adaptam seu estilo à situação.
Líderes eficazes reconhecem diferenças de motivação entre membros da equipe do
projeto e demonstram o comportamento desejado em áreas de honestidade, integridade e
conduta ética.

3.5.2.7 - 7º Princípio - Tailoring

“Projete a abordagem de desenvolvimento do projeto com base no contexto do projeto,
seus objetivos, as partes interessadas, a governança e o meio ambiente usando os
processos suficientes para alcançar os resultados desejados ao maximizar valor,
gerenciamento de custos e com rapidez”.
Cada projeto é único. O sucesso do projeto é baseado na adaptação ao contexto único
do projeto para determinar os métodos mais apropriados de produzir os resultados
desejados. Adaptar a abordagem é iterativa e, portanto, é um processo contínuo realizado
ao longo do projeto.

3.5.2.8 - 8º Princípio – Qualidade

“Mantenha o foco em qualidade que produza entregas que atendam aos objetivos do
projeto e alinhe às necessidades, à utilidade e aos requisitos de aceitação estabelecidos
pelos acionistas.”
A qualidade do projeto envolve satisfazer as expectativas das partes interessadas e
atender aos requisitos do projeto e do produto. A qualidade se concentra em atender aos
critérios de aceitação das entregas. A qualidade do projeto implica garantir que os processos
do projeto sejam apropriados e tão eficazes quanto possível.

3.5.2.9 - 9º Princípio – Complexidade

“Avalie continuamente e navegue na complexidade do projeto para que as abordagens
e os planos habilitem a equipe do projeto a navegar com sucesso no ciclo de vida do projeto”.

A complexidade é o resultado do comportamento humano, das interações de sistemas,

da incerteza e da ambiguidade. A complexidade pode surgir a qualquer momento durante o
projeto e pode ser introduzida por eventos ou condições que afetam o valor, o escopo, as
comunicações, as partes interessadas, o risco e a inovação tecnológica. As equipes de
projeto podem permanecer vigilantes na identificação de elementos de complexidade e usar
uma variedade de métodos para reduzir a quantidade ou o impacto da complexidade no
projeto.

3.5.2.10 - 10º Princípio – Riscos

“Avalie continuamente a exposição ao risco, tanto as oportunidades e ameaças para
maximizar os impactos positivos e minimizar os impactos negativos para o projeto e seus
resultados”.
 FGVIDT

Os riscos podem ser positivos (oportunidades) ou negativos (ameaças) e os riscos

individuais e gerais podem afetar os projetos. Os riscos são abordados continuamente ao
longo do projeto.
As respostas aos riscos devem:

• ser apropriadas para a significância do risco:

• ter custo-benefício;

• ser realistas dentro do contexto do projeto;

• se acordados pelas partes interessadas relevantes; e

• a cargo de uma pessoa responsável.

3.5.2.11 - 11º Princípio - Adaptabilidade e Resiliência

“Construa adaptabilidade e resiliência na organização e na equipe do projeto para
ajudar a implementar mudanças”.

A adaptabilidade é a capacidade de responder às condições de mudança. A resiliência

é a capacidade de absorver impactos e se recuperar rapidamente de um revés ou falha.

O foco nos resultados, em vez dos produtos, facilita a adaptabilidade.

3.5.2.12 - 12º Princípio – Mudanças

“Prepare as pessoas impactadas para a adoção e a sustentação de novos e diferentes
comportamentos e processos necessários para a transição do estado atual para o estado
futuro pretendido, criado pelos resultados do projeto”.
As mudanças podem se originar de influências internas ou externas. Permitir a
mudança pode ser um desafio, pois nem todas as partes interessadas abraçam as
mudanças. O envolvimento das partes interessadas e as abordagens motivacionais ajudam
a adoção das mudanças.

3.5.3 - SISTEMA DE ENTREGA DE VALOR

O Sistema de Entrega de Valor é uma abordagem abrangente por meio da qual os
projetos alcançam valor comercial.

É um sistema holístico através do qual os projetos entregam valor de negócios ao

atingir os objetivos de negócios da organização.

O Sistema de Entrega de Valor enfatiza os resultados obtidos pelas entregas.

O mecanismo de entrega de valor compreende principalmente programas, operações
e portfólios para permitir o fluxo de trabalho e apoiar a tomada de decisões.
A sétima edição do PMBOK mostra como uma boa estratégia é capaz de entregar valor
ao negócio.
 FGVIDT

Isso é feito por meio da definição de estratégias organizacionais que ajudam a

identificar os objetivos de negócios, que são então transformados em iniciativas práticas,
como programas e projetos, que por sua vez produzem resultados finais que aumentam as
capacidades da organização.

O sistema que permite que isso flua de forma leve e preditiva seria o sistema de entrega
de valor a ser incorporado à organização.

O Sistema de Entrega de Valor e os princípios servirão como um guia para gerentes

de projeto, membros da equipe e partes interessadas para entregar valor à organização e a
todas as partes envolvidas.

3.5.4 – Abordagem Baseada em Processos

Todas as edições do Guia PMBOK até à 6ª Edição foram baseadas em processos,
com suas entradas e saídas, conectando-os e criando uma rede integrada que se mostra
eficaz na condução dos projetos.
A 7ª Edição do PMBOK não revogou as abordagens baseadas em processos. Muitas
organizações e profissionais de gerenciamento de projetos continuam a usar métodos
convencionais de entrega de gerenciamento de projetos. As abordagens convencionais
também permanecem relevantes no contexto da versão 7 do PMBOK.

3.6 - MÉTODO DO QUADRO LÓGICO (MQL)

O Método do Quadro Lógico teve origem no Ministério Federal da Alemanha e na
Agência Alemã de Cooperação Técnica (GTZ), em 1975 e depois, a partir de 1990 foi
aperfeiçoado para contemplar, como ferramenta de planejamento, de monitoria e de
avaliação os projetos de agências e organizações de desenvolvimento.
Seu foco reside no Planejamento de Projeto Orientado para Objetivos, por meio de uma
Matriz de Estrutura Lógica.
A Matriz de Estrutura Lógica é um instrumento que aprofunda a visão geral do projeto
e antecipa os demais passos da configuração.
Ao preenchermos a Matriz, estaremos criticando o trabalho feito anteriormente e
ordenando o que ainda resta por fazer, ou seja, a Matriz denunciará um problema mal
individualizado, um produto mal caracterizado, um objetivo mal definido.

Se for necessário, deveremos voltar sobre os passos iniciais, pois essa é uma norma
em configuração de projetos.

A Matriz de Estrutura Lógica tem recebido várias denominações – Matriz Lógica do

Projeto, Matriz de Regulação, Resumo Lógico do Projeto.

Qualquer que seja a linha de trabalho, a Matriz é utilizada como instrumento central de
 FGVIDT

configuração, e sua utilização se tornou mandatária na configuração de projetos.

3.6.1 - GRÁFICO DA MATRIZ LÓGICA

A Matriz de Estrutura Lógica ou Matriz do Quadro Lógico é um gráfico que resume as
condições gerais de um projeto, que se destina a:

- indicar as premissas e as condições externas ao projeto;

- fixar critérios e meios de verificação de recursos e metas;

- permitir uma visão imediata, não detalhada, do objeto, das intenções e das condições
do projeto.

No sentido vertical, a Matriz dá informações sobre,

- insumos – os recursos necessários à obtenção do produto;

- finalidade – o objetivo global, a política, em que o projeto se insere;

- metas – os diversos produtos intermediários, que devem ser expressos

quantitativamente;

- objetivo/produto – o propósito do projeto, aquilo que será alcançado quando o projeto

estiver concluído.
No sentido horizontal, a Matriz dá informações sobre:

- indicadores de desempenho;
- descrição sumária do projeto;

- meios de verificação – os instrumentos e os documentos de aferição dos indicadores;

- pressupostos – situações e fatores externos que, estando fora do controle e da
influência do projeto, podem alterar sua condição de viabilidade.
A Matriz de Estrutura Lógica é um instrumento de verificação geral.

A Matriz deve ser reformulada sempre que for necessário, e o único método seguro
para seu preenchimento é o de aproximações sucessivas, iniciando sempre da esquerda
para a direita e de cima para baixo.
 FGVIDT

3.6.1.1 - PREENCHIMENTO DA MATRIZ DE ESTRUTURA LÓGICA DO

PROJETO
Finalidade do Projeto
A primeira descrição feita no preenchimento da Matriz refere-se à finalidade do projeto.
Sempre que possível, procuramos relacioná-la a uma política vigente e a uma situação
de consenso.
A finalidade é aquilo a que o projeto serve.
Em uma empresa, a finalidade deve estar ligada a uma estratégia ou a um plano
estratégico.
No setor público, a finalidade deve estar ligada a uma política ou a políticas de governo.

A finalidade é necessariamente genérica, mas não abstrata.

Por exemplo, a finalidade de um projeto pode ser descrita como contribuir para a
preservação do patrimônio etnográfico da determinada cultura...
O que devemos evitar sempre é descrever finalidades vagas, como contribuir de modo
estratégico para a missão da empresa ou permitir uma melhor estruturação de determinado
setor ou contribuir para a melhoria da saúde.

Devemos ser precisos, pois o projeto será avaliado.

Objetivo

O objetivo/produto contribui para alcançar a finalidade, pois descreve os efeitos

esperados quando o projeto estiver concluído.

Trata-se de rever e precisar o que foi feito na definição do objetivo.

A finalidade é aquilo a que o projeto serve.

Além disso, a documentação utilizada no processo de fixação da árvore de objetivos

 FGVIDT

pode ser útil nessa etapa.

Metas

Metas são produtos intermediários que, combinados, devem ser suficientes para que o
objetivo/produto do projeto seja alcançado. Além disso, constituirão os indicadores de
progresso e de consecução do projeto e, por isso, devem ser mensuráveis.
As metas devem ser expressas em termos de volume, comprimento, grau, alcance,
dimensão, tamanho, largura, altura ou qualquer medida que permita efetuar cálculos e
comparações.

O ideal é que as metas obedeçam ao seguinte perfil:

- responsabilização – o responsável pelo cumprimento de cada meta deve ser
nomeado;
- previsibilidade – as metas devem ser uniformes tanto na forma em que são medidas
como na descrição da qualidade do subproduto ou subserviço a ser alcançado;
- mensurabilidade – a dificuldade de mensuração de metas nos setores de serviços –
intangíveis – pode ser superada por medidas indiretas, como nível de satisfação do usuário
e percepção dos públicos-alvo.

Recursos
Os insumos são os recursos necessários para que cada produto intermediário possa
ser alcançado.
Os insumos devem ser expressos em termos de recursos humanos, materiais,
intangíveis e financeiros.

Embora a Matriz reflita apenas uma visão genérica dos recursos a serem alocados no
projeto, ela é preparatória para a pormenorização das atividades.

Isso quer dizer que, apesar de não ser preciso especificar cada recurso nessa etapa
quanto maior for o rigor do preenchimento, mais fácil ficarão as tarefas de detalhamento de
atividades e de preparação do orçamento.
Indicadores

Os indicadores devem constituir prova de que a finalidade, o objetivo e as metas foram

alcançados.

Em termos gerais, os indicadores dão informações sobre...

- duração;

- quantidade;
- local de realização;
 FGVIDT

- grupo/instituição-alvo;
- qualidade, especificação.

Indicadores de insumos
Os indicadores de insumos são as unidades de medida e quantidades necessárias de
um determinado recurso como, por exemplo, número de homens/hora de técnicos em
conservação.

Os indicadores de objetivos, correntes em projetos concorrenciais, são:

- a satisfação do cliente/destinatário;

- o alcance de fatia de mercado/público;

- as novas demandas – mercados/públicos;

- o tempo de resposta – tempo de reação a uma demanda.

Um bom indicador deve ser...

- essencial;
- verificável objetivamente;

- imputável, diretamente, ao projeto;

- diferençável dos indicadores dos demais níveis.

Meios de Verificação
Os meios de verificação são as fontes de informação sobre os indicadores e podem
ser:
- estatísticas;
- observações;

- jornais e revistas;
- sondagens de opinião;

- entrevistas com beneficiários;

- documentos e publicações oficiais.

Os meios de verificação devem ser facilmente acessíveis e não devem onerar

muito o projeto.

Contudo, é imprescindível para a configuração do projeto que os meios estejam bem

listados.

Sobre esse ponto, os financiadores e os patrocinadores de projetos costumam ser

extremamente severos.
 FGVIDT

Tal fato ocorre porque, em muitos setores, grande parte do cumprimento das
promessas contidas nas finalidades, nos objetivos e nas metas não são passíveis de
verificação.
Explica-se que de um lado, os meios de verificação são inexistentes, como no caso de
estatísticas supostamente fornecidas por órgãos governamentais, por outro lado, os meios
de verificação encerram custos que devem ser previstos no projeto, mas nem sempre são,
como no caso da repercussão em órgãos de imprensa, cuja verificação, a cargo de empresas
especializadas, costuma ser bem dispendiosa.

A imagem a seguir apresenta o exemplo de uma Matriz do Quadro Lógico preenchida

utilizando os conceitos da metodologia.
FGVIDT

Matriz do Quadro Lógico

 FGVIDT

Unidade 04 – PLANO DE
GERENCIAMENTO DE PROJETO
Os processos de gerenciamento de projetos estabelecem ciclos de planejamento,
execução e controle. Esse ciclo pode ser repetido muitas vezes ao longo de um projeto.

Um plano de gerenciamento de projeto é o documento que descreve como o projeto

será executado, monitorado, controlado e encerrado. O plano descreve os objetivos e o
escopo do projeto e serve como um ponto de referência oficial para a equipe do projeto, a
organização e as partes interessadas.

Ele é criado durante a fase de planejamento do projeto e é uma compilação de vários

outros documentos. É mais do que apenas um cronograma ou uma lista de tarefas, embora
inclua essas coisas. O plano de gerenciamento do projeto é formalmente aprovado no início
do projeto e, em seguida, atualizado progressivamente ao longo do projeto.

4.1 – A IMPORTÂNCIA DO PLANO DE GERENCIAMENTO DE PROJETO

O planejamento do projeto é uma etapa crucial da fase iniciação do gerenciamento de
projetos. O planejamento adequado agiliza todo o projeto em uma série de etapas e garante
a disponibilidade de todos os recursos no prazo.

As restrições do projeto, como tempo, escopo e custos, são discutidas no processo de

planejamento do projeto e os planos de mitigação de riscos são desenvolvidos após a
identificação dos riscos potenciais.
Ao comparar o progresso real com o plano do projeto pode-se monitorar o desempenho
da equipe e tomar as medidas necessárias para aperfeiçoá-lo.
No planejamento do projeto é importante manter o foco em áreas específicas, como as
listadas a seguir.

4.2 – IDENTIFICAR AS PARTES INTERESSADAS

Um projeto tem várias partes interessadas – os stakeholders e nem todos estarão
envolvidos em todos os detalhes do projeto.

As principais partes interessadas no projeto são:

- o cliente;

- os usuários finais do produto/serviço;

- a empresa e seus líderes; e

- a equipe que trabalha diretamente no projeto.

Dependendo da natureza do projeto, as partes interessadas também podem ser
organizações externas ou membros individuais da comunidade que serão afetados pelo
projeto.
 FGVIDT

4.3 – DEFINIR PAPÉIS E RESPONSABILIDADES

Depois de identificar as partes interessadas é preciso determinar as principais
habilidades e competências de gerenciamento de projetos necessárias para o projeto. A
partir dessa lista, são definidas as funções e atribuição de responsabilidades às partes
interessadas individuais.
Um papel não é o mesmo que uma pessoa.

Em alguns casos, uma pessoa pode preencher várias funções, por exemplo: uma
função que adiciona algumas horas de trabalho adicionais à agenda de uma pessoa ou inclui
as tarefas no cronograma. Em outros casos, várias pessoas podem ter funções idênticas.
Exemplo: um projeto de TI pode requerer vários engenheiros de software.

Os papéis típicos a serem desempenhados em um projeto são:

- o patrocinador do projeto;
- o gerente do projeto; e
- os membros da equipe do projeto.

As diferentes funções de membro da equipe do projeto variam de acordo com o projeto.

Às vezes pode ser o caso de incluir uma função para a relação com os fornecedores e uma
função para a relação com os clientes.

4.4 – REUNIÃO INICIAL - KICKOFF

A reunião de “pontapé” para início do projeto (kickoff) é uma oportunidade de reunir
todas as partes interessadas e apresentar a visão geral do projeto para que todos tenham
conhecimento e possam apoiar o projeto. Essa reunião também é uma oportunidade para
fazer as apresentações e estabelecer boas relações de trabalho.

Nesta fase, os detalhes específicos do projeto ainda não foram determinados, por isso,
é importante apresentar nessa discussão inicial: o escopo do projeto, o orçamento previsto,
uma ideia de cronograma e as metas.
Os papéis a serem desempenhados podem ser anunciados e um plano de
comunicação é explicado. A reunião inicial define o tom para a relação de trabalho entre as
partes interessadas durante a duração de todo o projeto.

Após a reunião inicial oficial, é hora de definir três conceitos importantes: o escopo do
projeto, o orçamento (receitas/despesas) e cronograma do projeto.

4.5 - DEFINIR ESCOPO, ORÇAMENTO E CRONOGRAMA DO PROJETO

4.5.1 - ESCOPO
O escopo do projeto diz o que será/não será feito.
As solicitações do cliente e a visão discutida pela equipe são apresentadas e os
objetivos do projeto são listados.
 FGVIDT

Na Unidade 5 estudaremos o Gerenciamento do Escopo na sua forma completa.

4.5.2 - CRONOGRAMA DO PROJETO

O cronograma é um documento que detalha e descreve a linha do tempo do projeto,
as fases e o período de tempo que se espera que elas sejam concluídas.

O cronograma do projeto também deve listar os recursos organizacionais necessários

para completar cada tarefa e qualquer outra informação crítica para facilitar a gestão da
equipe.
O cronograma de projeto divide as fases do projeto em tarefas e atividades, determina
as dependências, sequencia as atividades e estima os recursos necessários e a duração de
cada tarefa.

O cronograma do projeto é um documento que deve ser abrangente e fácil de entender.

O Gerenciamento do Cronograma será estudado na Unidade 6.

4.5.3 – ORÇAMENTO
O orçamento deve levar em conta o escopo e os recursos necessários para atingir os
objetivos do projeto.
O orçamento engloba a necessidade de recursos humanos e materiais e deve
descrever qual será o custo financeiro esperado para o desenvolvimento do projeto.
O Gerenciamento dos Custos será estudado na Unidade 7.

4.6 – DEFINIR OS OBJETIVOS E METAS

Depois que a equipe entender os objetivos do projeto e as fases para atingir esses
objetivos, os objetivos gerais do projeto devem ser divididos em metas e em atividades e
tarefas. As tarefas deverão ser priorizadas de acordo com a importância e suas
dependências.
As atividades descrevem as coisas que a equipe do projeto precisará fazer para
concluir o projeto. Normalmente, as atividades de um plano de gerenciamento de projeto
incluem a medição do progresso do projeto, a delegação de tarefas, a alocação de recursos,
o acompanhamento do tempo gasto nas tarefas do projeto e a comunicação do que é feito
de forma eficaz.

Um projeto é dividido em tarefas. Estas são trabalhos menores que compõem a imagem
maior do projeto. Identificar as tarefas é essencial para elaborar seu plano de gerenciamento
de projeto.
Muitas organizações estão adotando os OKRs (Objectives and Key-results) no lugar de
apenas objetivos.

4.6.1 – OBJETIVOS E RESULTADOS-CHAVE (OKR)

Os Objetivos e Resultados-chave (OKR) combinam uma meta e uma métrica para
 FGVIDT

determinar um resultado mensurável.

Objetivos: Define-se o que precisa ser alcançado; descreve um resultado desejado.

Resultados-chave: São os resultados mensuráveis que definem, objetivamente,

quando o objetivo foi alcançado.

Os OKRs de toda a empresa são usados para definir uma meta final para toda a
organização, enquanto os OKRs em nível de equipe, departamento ou projeto descrevem
os resultados focados em que cada grupo precisará alcançar para apoiar a organização.
A prática usual, encontrada em muitas organizações, é a atribuição de objetivos
SMART na Declaração de Escopo.
A definição dos objetivos e metas faz parte do Gerenciamento do Escopo e será
estudada na Unidade 5.

4.7 – DEFINIR ENTREGAS

Uma entrega, conforme definido pelo Project Management Institute (PMI), é “qualquer
produto, resultado ou capacidade única e verificável para executar um serviço que é
produzido para completar um processo, fase ou projeto”.
Uma entrega pode ser um produto, um resultado ou uma capacidade.

As entregas do projeto são determinadas pelos objetivos do projeto e são uma parte
essencial do plano do projeto.

Exemplo: Se o objetivo do cliente for que os usuários finais gerenciem o conteúdo de

sua Intranet, por exemplo, as entregas podem ser um sistema que permita aos usuários
gerenciar o conteúdo, bem como os materiais de treinamento para que os funcionários e
usuários finais saibam usar o recém-criado sistema.

A definição das entregas é um item da Declaração de Escopo e será estudada na

Unidade 5, no Gerenciamento do Escopo.

4.8 – AVALIAR OS RISCOS

Um risco é um problema que pode ou não surgir ao longo do projeto. É importante
identificar os riscos no gerenciamento de projetos e mitigá-los ainda na fase de planejamento
do projeto, para não haver surpresas posteriormente.

As principais áreas de risco em um projeto são:

- o escopo do Projeto;

- os recursos (pessoal, financeiro e físico);

- os atrasos no cronograma do projeto; e

- as falhas de tecnologia ou de comunicação.

Não é possível controlar todos os riscos potenciais, mas pensar neles com
 FGVIDT

antecedência pode evitar falhas no projeto.

4.9 – COMUNICAR O PLANO DO PROJETO

Uma vez que o plano de gerenciamento do projeto for concluído, ele deverá ser
comunicado claramente à equipe e a todas as outras partes interessadas.

Um plano de comunicação do projeto é um documento muito importante e tem por

finalidade estabelecer canais de comunicação sólidos com todos os interessados.

Uma boa comunicação do projeto é crucial e o gerente de projeto deve destinar especial
atenção a ele para adequar o tipo de comunicação com todas as partes interessadas.

4.10 – GERENCIAMENTO DO CICLO DE VIDA DO PROJETO

O ciclo de vida do gerenciamento de projetos refere-se a todas as fases e a todas as
ações necessárias para cumprir com sucesso os objetivos e as demandas do projeto. Isso
se aplica a projetos de todos os portes.
Uma fase do projeto é uma coleção de atividades relacionadas ao gerenciamento de
projetos. No ciclo de vida, o relacionamento entre as fases, geralmente é sequencial e cada
fase do projeto culmina com a conclusão de uma ou mais entregas do projeto.
As cinco fases do gerenciamento de projetos, preconizadas pelo Instituto de
Gerenciamento de Projetos são as seguintes: Iniciação, Planejamento, Execução,
Monitoramento e Controle e Encerramento do projeto.

Cada fase do ciclo de vida do projeto tem um foco distinto, diferente dos outros
estágios.

Existe um conjunto de processos que inicia a execução desse ciclo e outro que o
encerra. Dessa forma, os processos de gerenciamento de projetos podem ser integrados de
acordo como momento em que são usados no projeto.
A seguir veremos os cinco grupos de processos, de acordo com o Instituto de
Gerenciamento de Projetos.

4.11 - GRUPOS DE PROCESSOS

4.11.1 - INICIAÇÃO
— É o processo que formaliza a existência do projeto para a organização, define seus
objetivos e seu escopo inicial, nomeia o Gerente do Projeto e autoriza a mobilização de
recursos da organização para sua realização.

Na Fase de Iniciação são realizadas as atividades inerentes ao início do projeto como:

- identificação das demandas e/ou oportunidades

- identificação dos pressupostos, premissas, restrições, efeitos e externalidades

- determinação dos objetivos e metas a serem alcançados

- estimativa de recursos necessários

 FGVIDT

- elaboração/apresentação da proposta do projeto.

O grupo de processos de iniciação é composto pelos processos que obtêm a
autorização para o início do projeto ou de sua fase, que são: Desenvolver o Termo de
Abertura do Projeto e Identificar as partes interessadas.

Desenvolver o termo de abertura do projeto (project charter) do projeto é a

autorização para o início do projeto ou de uma de suas fases, documentando as suas
necessidades e conectando o projeto aos trabalhos em andamento da organização.
Identificar as partes interessadas é a identificação de todas as pessoas ou
organizações que podem ser afetadas pelo projeto, ou que em que, em algum momento,
poderão participar do projeto e o registro das informações importantes ligadas aos seus
interesses, impacto e envolvimento no projeto. Ao realizar esse processo, a equipe do projeto
terá o correto direcionamento do engajamento das partes interessadas ou ainda grupo de
partes interessadas.
É muito comum, no início do projeto, conhecer somente as partes interessadas iniciais
e, posteriormente, ao longo do projeto, novos integrantes poderão ser acrescidos.
Termo de Abertura do Projeto (TAP)

O Termo de Abertura do Projeto pode ser um documento sucinto, emitido por um

executivo com nível e poder suficientes para autorizar a disponibilização de pessoas e
recursos para o projeto. Ele também deve outorgar autoridade limitada, mas suficiente para
o Gerente do Projeto usar os recursos da organização no desenvolvimento do projeto.
Esse documento é assinado pelo executivo emissor e deve ser acessível a todas as
partes interessadas no projeto. Em alguns casos, o termo de abertura é formalizado por meio
de um memorando ou mesmo um e-mail.

No Termo de Abertura do Projeto devem constar:

- o nome do Gerente do Projeto

- a especificação de seus deveres e

- a autoridade e quais setores da organização devem apoiá-lo.

A emissão do Termo de Abertura do Projeto é uma oportunidade para o executivo

emissor esclarecer os objetivos que a organização espera do projeto.

Eles devem ser colocados de forma simples, específica, mensurável, factível e

delimitada no tempo, e também documentar quais necessidades organizacionais ou de
negócio motivaram a criação do projeto.
O Termo de Abertura do Projeto é um documento que serve como fonte para a
elaboração da declaração preliminar de escopo do projeto.
 FGVIDT

O TAP documenta: as necessidades do negócio, as premissas, as restrições, o

entendimento das necessidades e requisitos de alto nível do cliente, o novo produto ou
serviço ou resultado que pretende satisfazer.
O Canvas PM Model, visto na Unidade 3, facilita, por meio da produção do quadro de
apresentação do projeto, a identificação dos elementos que compõem o Termo de Abertura
do Projeto.

4.11.2 - PLANEJAMENTO
São os processos que determinarão, com um melhor grau de precisão, o que deveser
feito, por meio da declaração deescopo, ecomo deveser feito, por meio de um plano de
gerenciamento de projeto. Essas definições são registradas em uma linha de base, que é
um plano contra o qual os resultados serão conferidos.
Esses processos são responsáveis pelo planejamento e gerenciamento dos projetos,
por meio do plano de gerenciamento. Também refinam o seu escopo, o seu custo e o
agendamento das suas atividades.

Durante o planejamento, a equipe do projeto deve trabalhar com todas as partes

interessadas, de forma a aproveitar o seu conhecimento específico para o plano de
gerenciamento e outros documentos.
Os processos de planejamento são:

- Plano de Gerenciamento do Projeto

- Plano de Gerenciamento do Escopo

✓ Coletar os Requisitos
✓ Definir o escopo

✓ Criar a Estrutura Analítica do Projeto (EAP)

- Planejar o Gerenciamento do Cronograma

✓ Definir as Atividades
✓ Sequenciar as atividades

✓ Estimar as durações das atividades

✓ Desenvolver o Cronograma
- Planejar o Gerenciamento dos Custos

✓ Estimar os Custos
✓ Determinar o orçamento

- Planejar o Gerenciamento dos Recursos

 FGVIDT

✓ Estimar os Recursos das Atividades

- Planejar o Gerenciamento dos Riscos

✓ Identificar os Riscos
✓ Realizar a Análise Qualitativa dos Riscos

✓ Realizar a Análise Quantitativa dos Riscos

✓ Planejar Respostas aos Riscos

- Planejar o Gerenciamento das Comunicações

- Planejar o Gerenciamento da Qualidade

- Planejar o Gerenciamento das Aquisições

- Planejar o Engajamento das Partes Interessadas

4.11.3 - EXECUÇÃO
É neste grupo de processo que ocorre a produção das entregas do projeto por meio da
integração de pessoas, organizações e recursos materiais.
Os processos de execução são os responsáveis pela execução dos trabalhos definidos
pelo plano de gerenciamento, de forma a atender os requisitos do projeto, envolvendo a
coordenação de pessoas e recursos.

Os processos de execução são:

- Orientar e Gerenciar o Trabalho do Projeto

- Gerenciar o Conhecimento do Projeto

- Gerenciar a Qualidade

- Adquirir Recursos
- Desenvolver a Equipe

✓ Gerenciar a Equipe
- Gerenciar as Comunicações

- Conduzir as Aquisições
- Gerenciar o Engajamento das Partes Interessadas

4.11.4 - MONITORAMENTO E CONTROLE

Neste grupo de processos ocorre a conferência dos resultados da execução com a
linha de base definida no planejamento. No caso de desvios, ações corretivas devem ser
tomadas.

Os processos de monitoramento e controle são os utilizados para o gerenciamento da

execução do projeto, identificando eventuais problemas no momento adequado e permitindo
 FGVIDT

a tomada de ações corretivas, quando necessário.

Os processos de monitoramento e controle são:

- Monitorar e Controlar o Trabalho do Projeto

- Realizar o Controle Integrado de Mudanças

- Validar o escopo
✓ Controlar o Escopo

- Controlar o Cronograma
- Controlar os Custos

- Controlar a Qualidade
- Controlar os Recursos

- Monitorar as Comunicações
- Monitorar os Riscos

- Controlar as Aquisições
- Monitorar o Engajamento das Partes Interessadas.

Em algumas organizações os processos de Monitoramento e Controle são empregados

conjuntamente com os processos de Execução.

4.11.5 - ENCERRAMENTO
São os processos que formalizam o encerramento do projeto, o aceite dos resultados
obtidos, o encerramento oficial de contratos e a desmobilização da equipe.
Esses grupos de processos não representam as fases do projeto. Cada grupo de
processos pode ser repetido em cada fase, se for necessário, até que os critérios de
conclusão para cada fase tenham sido cumpridos.

Os processos de encerramento são aqueles utilizados para finalizar as atividades de

um projeto ou de uma de suas fases ou contrato formalmente. Nesta etapa, verifica-se se os
processos definidos foram concluídos em todos os grupos de processos a fim de encerrar o
projeto ou uma fase, de forma apropriada, e define formalmente a finalização do projeto ou
da fase. O principal processo é: Encerrar o Projeto ou Fase.
 FGVIDT

Unidade 05 - PLANO DE
GERENCIAMENTO DO ESCOPO
5.1 - GERENCIAMENTO DO ESCOPO
Ao levarmos em consideração que o objetivo fundamental do esforço de planejamento
deve ser o de prover uma orientação consistente e realista a respeito do que deve ser
gerado pelo projeto e de como isso deve ser executado e controlado, os benefícios de
um adequado planejamento do escopo ganham contornos decisivos, já que qualquer projeto
embute um determinado nível de incerteza.
A própria definição formal de projeto nos lembra que a solução gerada será, em alguma
extensão, única, demandando, portanto, atenção singular e específica para seu
planejamento.

5.2 - IDENTIFICAR OS PRESSUPOSTOS

Os pressupostos são as condições necessárias e suficientes, externas ao projeto,
para que a finalidade, o objetivo e as metas sejam alcançados e para que os insumos
estejam disponíveis.

Os pressupostos devem ser sempre expressos em termos positivos como, por exemplo
o governo manterá a atual política referente ao apoio ao teatro itinerante.

O grau de probabilidade – estimativa – de que o fato ocorra deve fazer parte da

descrição dos pressupostos.

Os pressupostos constituem uma das bases para análise de risco do projeto.

Portanto, é preciso atenção para o caso em que o pressuposto seja impeditivo
para o projeto como um todo.
Os pressupostos, em linhas gerais, compreendem fatores como:

- tempo;
- qualidade;

- segurança;
- tecnologia;

- confiabilidade;
- recursos humanos;

- capacitação, treinamento;
- acessibilidade, transparência;
 FGVIDT

- compatibilidade de componentes;
- ambiente e condições ambientais;

- dinheiro, créditos e ganhos financeiros;

- informações, dados em bruto, bancos de dados;

- cultura, geralmente a aceitação cultural do produto/serviço gerado pelo projeto;

- manutenção, preservação e outros fatores de conservação de bens e do meio
ambiente;
- legalidade, principalmente no que se refere a autorizações, permissões e
credenciamentos.
Exemplos de pressupostos:

Disponibilidade de recursos humanos: Todos os principais membros da equipe do

projeto estão disponíveis e possuem as habilidades e conhecimentos necessários para
trabalhar no projeto.
Disponibilidade de orçamento: O orçamento determinado é preciso e cobre todas
as despesas do projeto.
Precisão de agendamento: Os prazos e marcos definidos são alcançáveis e o
projeto pode ser concluído no prazo.
Desempenho de empreiteiros, fornecedores e vendedores: Todos os
equipamentos e bens estão disponíveis quando forem necessários.
Apoio da alta administração: haverá o apoio e a adesão da Direção da
Organização e do patrocinador do projeto, que o apoiará quando surgirem problemas.

5.3 - IDENTIFICAR AS RESTRIÇÕES

As restrições são fatores que limitarão as opções do projeto como, por exemplo, um
orçamento pré-definido, cláusulas contratuais, legislação...

As principais restrições são: custos, escopo, qualidade, riscos, recursos e tempo.

5.3.1 – RESTRIÇÃO CUSTO

Restrição Custo é o orçamento aprovado para o projeto e inclui todas as despesas
necessárias para entregar o projeto. É responsabilidade dos Gerentes de Projeto encontrar
o equilíbrio para não faltar ou não sobrar recursos. Orçamentos realizados sem critérios ou
mal planejados contribuem para o fracasso de projetos. O custo, em projetos, é uma restrição
limitante.

5.3.2 - RESTRIÇÃO ESCOPO

Restrição Escopo é todo o trabalho envolvido na entrega dos resultados do projeto e
os processos usados para produzi-los. É a razão de ser e o propósito de todo projeto.
 FGVIDT

5.3.3 - RESTRIÇÃO QUALIDADE

Restrição Qualidade é uma combinação dos padrões e critérios aos quais os produtos
ou serviços do projeto devem ser entregues para que tenham um desempenho eficaz,
fornecer as funcionalidades esperadas, os benefícios e o valor esperado ao final. Esses
critérios e padrões devem resolver o problema identificado no início do projeto.

5.3.4 - RESTRIÇÃO RISCO

O risco é definido por potenciais eventos externos que terão um impacto negativo no
projeto, caso venham a ocorrer. O risco é uma combinação da probabilidade de determinado
evento ocorrer e o impacto no projeto se este evento venha realmente a ocorrer.

5.3.5 - RESTRIÇÃO RECURSOS

Os recursos são necessários para realizar as tarefas do projeto. Podem ser pessoais
ou materiais, como equipamentos. Também podem ser instalações, fundos ou qualquer
outra coisa necessária para a conclusão de uma atividade de projeto (geralmente que não
seja mão-de-obra).

5.3.6 - RESTRIÇÃO TEMPO

O tempo é definido como a duração estimada em dias, meses ou anos para concluir o
projeto. O tempo é uma restrição que, frequentemente, acompanha e limita o
desenvolvimento de projetos. Isso se reflete em prazos perdidos e entregas incompletas.

5.3.7 - TRÍPLICE RESTRIÇÃO

As principais restrições concorrentes em um projeto são: o tempo, o escopo e o custo.

A tríplice restrição, representada por um triângulo, define as relações entre o

escopo/trabalho a ser realizado, o tempo/definido em um cronograma e os custos/recursos
disponíveis. Manter o equilíbrio entre os lados é difícil porque os projetos são propensos a
mudanças.

O conceito de tríplice restrição determina que se houver alteração em qualquer lado do

triângulo, isso terá efeitos nos outros lados do triângulo e na qualidade do projeto.

Por exemplo, se o patrocinador de um projeto quiser adicionar funcionalidades não

previstas no escopo original, provavelmente poderá ser necessário mais recursos (dinheiro)
para finalizar o projeto.
De forma semelhante, se o orçamento do projeto tiver cortes, pode ser necessário
reduzir a qualidade do escopo. E se não houver os recursos apropriados para trabalhar nas
tarefas do projeto, pode ser necessário estender os prazos do cronograma, porque os
recursos existentes talvez não sejam suficientes ou não haja tempo para terminar o trabalho.
As restrições são todas interdependentes.
 FGVIDT

Tríplice Restrição em Projetos

5.4 - PREMISSAS
Identificar as Premissas. As premissas são fatores quando sua ocorrência é
considerada necessária para fins do projeto como, por exemplo, a disponibilidade de um
determinado recurso, uma autorização de instalação, outputs de outros projetos.

5.4.1 – EFEITOS E EXTERNALIDADES

Identificar os efeitos e externalidades.

O exame dos efeitos e das externalidades tem como propósito determinar:

- os riscos que ameaçam o projeto e a forma de diminuí-los;

- os custos indiretos, internos e externos, auferidos e gerados pelo projeto;

- os benefícios indiretos, internos e externos, auferidos e gerados pelo projeto.

Efeitos são ocorrências positivas e negativas geradas pelo projeto. Dentre os efeitos
gerais, temos os da ligação que relaciona o projeto com outros produtos/serviços e com
outros projetos.
Esses efeitos são considerados parte dos custos e dos benefícios secundários, isto é,
não ligados à taxa de retorno dos projetos comerciais ou à utilidade dos projetos com fins
sociais.

5.4.2 - EFEITOS PARA FRENTE

Os efeitos para frente são aqueles que ocorrem após a realização do projeto e que
criam situações novas, isto é, não preexistentes.
Por exemplo, em face de carências localizadas em um projeto, pode ser necessário
treinar pessoas.
Mais tarde, após a conclusão do projeto, tais pessoas podem ser aproveitadas em
outros projetos e organizações.
 FGVIDT

Outro exemplo é o da indústria de laticínios, que, uma vez instalada, tende a estimular
a produção de leite, por criar um mercado estável.

Os efeitos de ligação para frente estão referidos ao destino do produto/serviço do

projeto.

Temos também efeitos para frente negativos. Por exemplo, a realização de um projeto
intensivo em tecnologia pode ocasionar desvios estruturais indesejáveis na evolução de uma
região.

5.4.3 - EFEITOS PARA TRÁS

Os efeitos para trás são os que modificam situações preexistentes ao projeto.
Por exemplo, quando a realização de um projeto traz melhorias nas redes de
distribuição sem que seja seu objetivo.
Em se tratando de efeitos para trás negativos, os casos mais discutidos na atualidade
são as agressões ao meio ambiente provocados por alguns tipos de projetos.
Efeitos de ligação para trás estão referidos aos insumos e aos recursos do projeto, isto
é, ao impacto causado por sua absorção.

5.5 - EXTERNALIDADES
As externalidades são ocorrências positivas ou negativas, auferidas ou geradas de
forma indireta pelo projeto.

As externalidades diferem dos efeitos na medida em que estão referidas a fatos e a

ocorrências fora da possibilidade de controle e influência do projeto.

Em geral, as externalidades auferidas ou geradas são imprevisíveis.

Um exemplo de externalidade auferida é o aparecimento de uma nova tecnologia que
acelere um projeto – positiva –, ou torne desnecessária sua execução – negativa.
Um exemplo de externalidade gerada é a mudança na estrutura de poder em uma
região, como no caso da ascensão ou da queda de um grupo político, em razão do número
de pessoas de outras regiões que são trazidas a trabalhar em um dado projeto.

Para todo projeto, é importante tentar prever externalidades não só econômicas, mas
também políticas, institucionais, organizacionais, sociais, tecnológicas e culturais.

Geralmente, a previsão de efeitos e externalidades é feita mediante a reflexão a partir

de listagens simples.

Por exemplo, o exame de externalidades no campo cultural deve considerar impactos

sobre o projeto e gerados pelo projeto nos valores, nas crenças, nos mitos, nos rituais, nas
normas, nas expectativas, nas tradições e no imaginário.
 FGVIDT

5.6 - COLETAR OS REQUISITOS

Os requisitos incluem as necessidades quantificadas e documentadas e as
expectativas das partes identificadas na avaliação das partes interessadas.
Os requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes
para ser medidos, devendo ser investigáveis, não ambíguos (mensuráveis e passíveis de
testes), completos, consistentes e aceitáveis para as principais partes interessadas.

Em gerenciamento de projetos, há basicamente dois tipos de requisitos:

- requisitos do projeto — de negócios, de gerenciamento do projeto, de entrega etc.;

- requisitos do produto — técnicos, de segurança, de desempenho etc.

O levantamento de dados é fundamental para identificar as necessidades que servirão
de base para mapear os requisitos do projeto. O sucesso do projeto é diretamente
influenciado pela atenção na captura e gerenciamento dos requisitos do projeto e do produto.
Os requisitos incluem as necessidades quantificadas e documentadas e as
expectativas do patrocinador, cliente e outras partes interessadas.

O escopo do produto deve buscar idenficar as principais características e funções do

produto ou serviço.

O escopo do projeto deve detalhar todo o trabalho a ser realizado para entregar o
produto ou serviço.

No escopo do projeto definiremos os pressupostos do projeto: as premissas e as

restrições.

Uma ferramenta interessante para auxiliar a coleta de requisitos é a Matriz de

Rastreabilidade de Requisitos.
 FGVIDT

A matriz pode ser adaptada, contemplando as informações mais pertinentes, como

identificação do requisito, prioridade, código do elemento da EAP onde o requisito está
associado, nome do requisito, descrição do requisito, tipo do requisito, solicitante do
requisito, status e a data.

A imagem a seguir exemplifica uma Matriz de Rastreabilidade de Requisitos

preenchida.

5.7 - DEFINIR O ESCOPO

É o processo de criação de uma descrição detalhada do projeto e do produto do projeto,
que serve de base para suas futuras decisões.
Essa descrição deverá conter os elementos essenciais do projeto:

- descrição, limites, objetivos, entregas, responsáveis, custos, prazos, atividades,

restrições, premissas, etc.

Sua principal finalidade é dar foco na condução do projeto, facilitando o gerenciamento.

A tabela a seguir apresenta, sucintamente, as principais informações que devem
constar em uma Declaração de Escopo.

DECLARAÇÃO DE ESCOPO

Descrição Descrever o trabalho que será ser realizado.

Situação atual e Descrever a situação atual (que pretende resolver) e as razões que
Justificativa motivaram a realização do projeto.

Objetivos: - Específico: Quanto mais específico melhor.

SMART - Mensurável: Às vezes, o melhor critério é qualitativo, mas use
 FGVIDT

descrições quantitativas sempre que possível.

- Alcançável: É surpreendentemente fácil se comprometer com
algo que você não tem experiência para concluir.
- Relevante: O escopo deve se concentrar em cumprir as metas do
cliente/proprietário e evitar tarefas que não agregam valor.
- Tempo limite: Um projeto é, por definição, temporário e, portanto,
tem um limite de tempo.

Entregas Apresentar as entregas que serão produzidas.

Critérios de Apresentar a especificação dos parâmetros que serão levados em

Aceitação consideração na hora de aceitar cada entrega.

Inclusões ou Definir e descrever o que deverá estar incluído ou não. Este tópico
Exclusões faz a revisão dos limites do projeto. Muitos projetos têm itens que são
incertos.

Restrições Apresentar as restrições específicas associadas com o escopo que

limitam as opções da equipe do projeto. Se houver limites físicos que
podem se tornar riscos, estes deverão ser definidos posteriormente.

Premissas Apresentar os fatores considerados verdadeiros sem prova para fins

de planejamento. Todos os projetos assumiram certas condições
como parte de sua existência.

5.8 - CRIAR A ESTRUTURA ANALÍTICA DO

PROJETO (EAP)
A Estrutura Analítica do Projeto (EAP), tradução do inglês de WBS (Work Breakdown
Structure) é uma decomposição hierárquica das entregas e do trabalho do projeto em
componentes menores e de gerenciamento mais fácil. Ela organiza e define o escopo total
do projeto e deve orientar as entregas do trabalho a serem executadas, posteriormente, pela
equipe para atingir os objetivos do projeto e criar as entregas requisitadas.
Cada nível descendente da EAP representa uma definição, gradualmente mais
detalhada, da definição do trabalho do projeto.
Por meio de estrutura semelhante a um organograma, a EAP representa o que deverá
ser entregue pelo projeto. Ela permite detalhar quais as entregas que devem ser geradas
em função dos objetivos do projeto. A organização das entregas por meio de uma EAP vem
sendo fortemente utilizada nos projetos de sucesso em todo o mundo, já que permite o
esclarecimento à equipe do projeto, fornecedores, clientes, patrocinadores e demais
 FGVIDT

interessados sobre o que se espera em termos de resultados do projeto e,

consequentemente, do que será monitorado e controlado.

Essa subdivisão do trabalho pode ser realizada até o nível em que se deseja controlar,
como os pacotes de trabalho (work package). Essa subdivisão, normalmente, é feita de
acordo com o grau de controle necessário para gerenciar o projeto.

5.8.1 - CRITÉRIOS PARA DECOMPOSIÇÃO DA EAP

Alguns critérios para decomposição da EAP sugeridos são:
Decompor em em fases, caso a cronologia dos eventos e das entregas seja relevante.
 FGVIDT

Decompor em entregas principais, caso seja importante caracterizá-las.

Decompor em pacotes de trabalho, se quiser maior detalhamento.

A EAP deverá ser revisada sempre que for preciso para que sua aprovação contemple
de forma mais precisa possível o que se pretende alcançar no projeto.
 FGVIDT

Unidade 06 - PLANO DO GERENCIAMENTO

DO CRONOGRAMA
6.1 - GERENCIAMENTO DO CRONOGRAMA
O gerenciamento do cronograma é o processo de criação de um plano de
gerenciamento do tempo do projeto e contempla os processos que garantem que o projeto
seja concluído no tempo correto.
Ele consiste da definição das atividades, do sequenciamento de atividades, das
estimativas de duração de atividades e do desenvolvimento do cronograma.
A elaboração da lista de atividades a serem desenvolvidas pelo projeto deve conter
todas as atividades.
É necessário que elas sejam detalhadas antes da inserção na planilha do software.

É preciso definir, com a maior precisão possível, qual tarefa deve ser concluída em
cada atividade.

Para facilitar os passos seguintes, é importante que as atividades sejam inseridas na

sequência lógica do projeto, com a especificação das atividades predecessoras.

6.1.1 - DEFINIR AS ATIVIDADES

Definir as atividades é o processo de identificação e documentação das ações
específicas a serem realizadas para produzir as entregas do projeto.
A atividade é a unidade básica do projeto.

Cada atividade é uma ação discreta ou um congregado homogêneo de ações que estão
referidas à geração ou ao apoio à geração de uma fração do produto/serviço.

Na literatura técnica sobre projetos, o termo atividade aparece, algumas vezes, como
uma divisão de tarefas, ou seja, a unidade principal é denominada tarefa e a secundária,
atividade.
No entanto, o termo tarefa costuma aparecer como divisão ou componente da
atividade, sendo o termo atividade a unidade básica do projeto.
É desejável que a atividade possa ser descrita em detalhes, de maneira a termos uma
correta percepção da tarefa, sem interpretações duvidosas.
Devemos ter em mente uma estimativa da duração ideal da tarefa e a quantidade de
recursos a serem disponibilizados em cada uma das atividades do projeto.
Esse ponto é muito importante para que não haja maiores dificuldades adiante.
 FGVIDT

6.1.2 - SEQUENCIAR AS ATIVIDADES

Sequenciar as atividades é o processo de identificação e documentação dos
relacionamentos entre as atividades do projeto.
Por isso, o passo mais importante para o detalhamento do projeto é a definição das
atividades.
Nessa etapa, queremos chegar a uma listagem de todas as ações a serem
desenvolvidas em cada uma das fases ou dos subprojetos.
Para definirmos as atividades, é útil considerarmos os seguintes fatores:

- completude – uma atividade deve representar, pelo menos, uma ação completa;
- descrição – uma atividade deve poder ser descrita sucintamente;

- limites – os limites devem ser claros, tanto em termos de duração como de custos;
 FGVIDT

- simplicidade – a atividade deve conter uma ação básica e, além disso, devemos
estudar a conveniência de decompor a atividade em duas ou mais atividades sempre que
não pudermos defini-la utilizando um único verbo.
O procedimento usual nessa etapa é listar, livremente, as atividades que pareçam
necessárias ao projeto.
O uso de técnicas como o brainstorming, pode ser útil. É recomendável tentar dispor
as atividades na ordem em que devem acontecer. Em etapas posteriores, corrigiremos e
reordenaremos a listagem.

Nessa etapa, o importante é procurar não deixar de relacionar nenhuma atividade,

mesmo que a listagem pareça excessiva ou muito detalhada.

As atividades podem ser sequenciadas linearmente ou podem se sobrepor. Isso ocorre

porque existem atividades que podem ser realizadas em paralelo a outras, configurando-se
em redes de relações.
Projetos simples, com poucas atividades e fases, dispensam a construção e o cálculo
de redes.
Nesse caso, podemos passar, diretamente, à elaboração do cronograma constante no
passo seguinte.
Para projetos de envergadura maior, que excedam quinze atividades, são
imprescindíveis a visualização da sequência para a economia interna do projeto, a
elaboração de cronograma e o cálculo orçamentário.
Para projetos com trinta ou mais atividades ou para projetos em ambiente
organizacional digitalizado, é recomendável a utilização de softwares especializados.
Mesmo nesses casos é recomendável a elaboração de um rascunho que oriente a
alimentação dos quesitos requeridos pelos programas.

6.1.3 - ESTIMAR AS DURAÇÕES DAS ATIVIDADES

Estimar as durações das atividades é o processo de estimativa do número de
períodos de trabalho que serão necessários para terminar atividades específicas com os
recursos estimados.
Para estimar a duração de uma atividade, podemos obter informações; em memórias
de projetos realizados anteriormente; em manuais técnicos ou de profissionais
especializados – por exemplo, o tempo de maturação de uma cultura ou o tempo necessário
para erguer uma parede de tijolos; pela estimativa, mediante comparação com atividades
similares.

Na impossibilidade do uso dessas informações, os instrumentos de análise de decisão

podem reduzir o risco envolvido ao predizermos o tempo necessário à realização de uma
 FGVIDT

atividade.
Alguns softwares aceitam e calculam margens de erro na estimativa da duração
de atividades.
Como as atividades do projeto envolvem trabalho, a estimativa de sua duração tende
a ser imprecisa.
A fórmula mais utilizada por profissionais de modelagem para a estimativa de duração
é a de três pontos ou técnica PERT:

Onde:

Tp = a duração – tempo – ponderada para a atividade.

a = a estimativa de duração mais curta – otimista – para a atividade.

b = a estimativa de duração mais longa – pessimista – para a atividade.

m = a estimativa mais provável para duração da atividade.

Note que m não é uma média entre a e b, mas a média das estimativas.
A distribuição de frequência tende a ser otimista ou pessimista conforme o tipo de

atividade.
São fontes que auxiliam estimar a duração das atividades:

- informações de projetos realizados na organização anteriormente;

- informações dos manuais técnicos ou de profissionais especializados (por exemplo,
experiência na realização de atividades feitas em outras ocasiões);

- comparação com atividades similares.

As atividades que envolvem trabalho em equipe ou que dependem de fornecimentos
tendem a ser estimadas com maior folga, enquanto as que envolvem uso intensivo de
equipamento ou que são realizadas por uma só pessoa tendem a ser estimadas de forma
mais otimista no que se refere à duração.
A maioria dos softwares utilizada para construção do cronograma emprega unidades
de tempo fixas, como hora, dia ou semana...
Por exemplo, um padrão de dia considera oito horas úteis no dia.

6.1.4 - DESENVOLVER O CRONOGRAMA

Desenvolver o cronograma é o processo de análise das sequências das atividades,
suas durações, recursos necessários e restrições do cronograma visando criar o modelo do
 FGVIDT

cronograma do projeto.
O cronograma, ou seja, as datas reais de realização das atividades, consiste em
um item obrigatório na modelagem de qualquer projeto.
Normalmente, a duração do projeto é calculada considerando-se uma data zero de
início das atividades e, posteriormente, estabelecida uma data real para a data de início.
Os softwares fazem essa conversão sem maiores dificuldades, mas é preciso
especificarmos o tipo de calendário que estamos utilizando.
O cronograma do projeto é, em geral, apresentado sob a forma do Gráfico de Gantt.

As informações do cronograma obtidas com o Gráfico de Gantt são:

- barras com as atividades listadas no eixo vertical (ou horizontal)

- as datas apresentadas no eixo horizontal (ou vertical)

- as durações das atividades aparecem como barras horizontais, de acordo com as
datas de início e término.
 FGVIDT

6.1.4.1 - PASSOS PARA A ELABORAÇÃO DO CRONOGRAMA

Para a elaboração de um cronograma simples, sem a utilização de uma técnica de
redes, são necessários os seguintes passos:
Listagem das atividades do projeto a partir da EAP ou do Dicionário da EAP.

Listagem das atividades predecessoras: Ordenar as atividades na ordem prevista para

sua realização. Na terminologia adotada para a sequência, toda atividade, com exceção da
atividade que dá inicio ao projeto, tem uma ou mais atividades que lhe precedem. Da mesma
forma, toda atividade, exceto a última atividade do projeto, é predecessora de uma ou mais
atividades.
Delinear gráfico: Assinalar no gráfico, sob a forma de barras horizontais, a duração de
cada atividade.
Assinalar com um asterisco ou outro sinal diferencial, as atividades sem duração, como
a celebração de contratos e a apresentação de relatórios.
 FGVIDT

6.2 - DIAGRAMAS DE REDE DO CRONOGRAMA

DO PROJETO
As técnicas de redes têm o objetivo de reduzir a duração do projeto, racionalizando a
sequência das atividades e dos eventos.
A redução da duração do projeto é feita mediante o cálculo dos tempos – a duração
das atividades –, considerando-se as superposições – atividades simultâneas – e o melhor
aproveitamento dos recursos.
As técnicas de redes dão ainda informações sobre os gargalos e as atividades-chave
do projeto, além de auxiliarem o trabalho de coordenação de ações.
Um Diagrama de Rede de Atividades também é chamado de Diagrama de Setas
(porque a exibição gráfica contém setas) ou Diagrama PERT (Técnica de Avaliação de
Avaliação do Programa) e é usado para identificar sequências de eventos de tempo que são
essenciais para os objetivos.

6.2.1 Análise do Caminho Crítico

A Análise do Caminho Crítico ajuda as equipes a compreender as sequências de
eventos específicos que direcionam os requisitos de tempo para a realização dos objetivos.

Os diagramas de rede de atividades também são muito úteis quando um projeto tem
várias atividades que precisam de gerenciamento simultâneo.

Um diagrama de rede de atividades ajuda a descobrir a sequência mais eficiente de

eventos necessários para concluir qualquer projeto. Ele permite criar um cronograma de
projeto realista, mostrando graficamente:
- a quantidade total de tempo necessária para concluir o projeto;

- a sequência em que as tarefas devem ser realizadas;

- quais tarefas podem ser realizadas ao mesmo tempo;

- quais são as tarefas críticas que precisam de maior atenção.

As principais definições de rede em um diagrama de redes são:

Atividade crítica – uma atividade que não tenha folga e que, sofrendo um atraso,
compromete todo o projeto.

Atividade fantasma ou de ligação – dummy activity – indica a dependência entre

eventos sem que haja uma atividade real entre eles.

Atividade – conjunto de ações realizadas por pessoas, constituindo a unidade básica

do projeto. Cada atividade deve ter uma data de princípio e uma data de término conhecida.

Caminho crítico – critical path – é a sequência de atividades que determina a maior

duração, a que liga as atividades críticas.
 FGVIDT

Data mais cedo – é a data para dar início a uma atividade, sem que seja alterada sua
relação de dependência...

Data mais tarde – é a data para dar início a uma atividade sem que se altere a data
final do projeto.

Evento – início ou conclusão de uma tarefa. O evento inicial e o evento final marcam,
respectivamente, o início e o término do projeto...

Folga dependente – é a margem de que se dispõe, a partir da data mais tarde de uma
atividade, para que ela seja executada sem alterar a data mais tarde da atividade seguinte.

Folga livre – é o atraso máximo de uma atividade sem alterar a data de início das
atividades seguintes...

Folga – é a margem de tempo disponível quando se subtrai a duração da diferença

entre a data mais tarde e a mais cedo da atividade...
Marcos – milestones – são pontos da rede que indicam ocorrências, como o momento
em que o projeto chega à metade ou quando se apresenta um relatório. Podem ser
entendidos como atividades de tempo igual a zero.
Exemplo de identificação de um caminho crítico:

Uma equipe decompôs o escopo de um projeto em atividades e as sequenciou,

considerando as relações de dependências e suas durações estimadas em horas. A imagem
do diagrama de redes exemplifica os diversos caminhos das atividades, do início ao fim.

Da imagem do diagrama de rede identificam-se 4 caminhos:

- A/C/F/I/J/K
- A/D/F/I/J/K
 FGVIDT

- A/E/G/H/I/J/K
- B/E/G/H/I/J/K.

O caminho crítico é aquele sem folgas, com a maior duração do projeto, que liga as
atividades críticas, que caso atrasem levarão a um atraso no projeto como um todo.

No caso, o caminho crítico é o caminho A/E/G/H/I/J/K e a sua duração = 6 + 4 + 1 + 3

+ 3 + 4 + 1 = 22 horas.

6.2.2 - Vantagens dos Diagramas de Rede

As principais vantagens dos Diagramas de Rede são:

- mostra com clareza as relações de dependência entre as atividades, as fases do

projeto e o projeto como um todo, bem como a coerência técnica do projeto;

- identifica as relações de precedência e sequências de atividades críticas

(caminho crítico), além de permitir uma fácil visualização do caminho crítico;

- disponibiliza as datas “primeira data de início”,“primeira data de término”, “última

data de início” e “última data de término”, bem como as folgas livre e total;

- possibilita a compreensão da lógica interna do projeto;

- possibilita a determinação da duração do projeto;

- serve de guia para a verificação das atividades e para a execução econtrole do

projeto;

- facilita a organização e a atribuição de trabalho e induz a um planejamento lógico.

FGVIDT
 FGVIDT

Unidade 07 – PLANO DE
GERENCIAMENTO DOS CUSTOS
7.1 - GERENCIAMENTO DOS CUSTOS
O gerenciamento de custos do projeto abrange os processo de estimar os custos e
determinar o orçamento do projeto.

Esses processos devem garantir que o projeto seja completado e finalizado dentro do
orçamento aprovado, além de definir quem, quando e como será feita a gestão dos custos.

O orçamento determinado será a estimativa de custos no início do projeto, somada à

uma margem de contingências.

7.1.1 - ESTIMAR OS CUSTOS

Estimar os custos é o processo responsável pelo desenvolvimento de uma estimativa
aproximada dos custos do projeto. A precisão da estimativa depende da técnica de cálculo
e do momento em que será realizada.

7.1.1.1 - TÉCNICAS DE CÁLCULO DE CUSTOS

Estimativa por Analogia (top-down): adota-se estimativa de projetos anteriores
análogos. Essa estimativa é muito utilizada quando a organização tem por costume repetir
projetos ou projetos que entregam resultados/produtos similares.
Estimativa Paramétrica: esta técnica adota parâmetros (custo, orçamento e duração)
de atividades do projeto, que são quantificados e multiplicados por seu custo unitário. Essa
técnica é utilizada quando os dados de custos disponíveis são confiáveis e se enquadram
em parâmetros que podem ser utilizados em projetos atuais como futuros.Tem como
vantagem ser mais precisa do que as demais técnicas. Por exemplo, se um pedreiro assenta
10m2 de piso por dia, conclui-se que ele poderá assentar 100m2 em 10 dias.
Estimativa por Composição de Preços (bottom-up): esta técnica detalha os itens de
execução, somando e agregando todos os custos até chegar à estimativa global.
É considerada uma técnica mais confiável, porque baseia-se na atribuição dos custos
das atividades definidas e detalhadas do projeto, considerando todas as atividades
conhecidas, de baixo para cima, desde o pacote de trabalho até englobar o projeto como um
todo. Sua desvantagem é o longo tempo demandado para estimar os custos de todas as
atividades.
 FGVIDT

(PAES e VILGA, 2016)

Estimativa de 3 pontos: esta técnica considera o cálculo da média ponderada de

estimativas otimista, provável e pessimista e é utilizada quando não se dispõe de estimativas
mais próximas. É um conceito que tem origem na Técnica de Revisão e Avaliação de
Programa (PERT).
A técnica considera os seguintes cenários:

- cenário de custo otimista (tudo poderá dará certo) - CO;

- cenário de custo pessimista (tudo poderá dar errado) - CP;
- cenário de custo mais provável - CM.
O custo esperado (CE) é calculado por meio da distribuição beta ou triangular:

CE = (CO + 4CM + CP)/6 (Beta)

CE = (CO + CM + CP)/3 (Triangular)

Sendo:
● CO = Custo Otimista

● CM = Custo Mais Provável

● CP = Custo Pessimista
 FGVIDT

7.1.2 - DETERMINAR O ORÇAMENTO

Determinar o orçamento é o processo responsável pela agregação dos custos
estimados das atividades individuais, estabelecendo uma linha de base dos mesmos.

Devem ser considerados todos os custos estimados em cada atividade

específica (pessoal, material, equipamentos) e de cada pacote de trabalho.

7. 2 - OUTROS CONCEITOS DE CUSTOS

7.2.1 - TCO - TOTAL COST OF OWNERSHIP - CUSTO DE PROPRIEDADE
O TCO é considerado uma estimativa financeira utilizada para calcular os custos diretos
e indir.etos associados à compra, manutenção e propriedade de algum bem ao longo do
tempo.

7.2.2 - CUSTOS DO PROJETO

São considerados todos os custos relacionados ao projeto em si e não ao produto final,
depois deste ter sido entregue. Envolve os custos de se iniciar, planejar, executar controlar
e encerrar o projeto.

7.2.3 - CUSTOS DE OPERAÇÃO

São os custos da operação contínua, ao longo do ciclo de vida do serviço ou produto
gerado por meio de um projeto.

7.2.4 - CUSTO DAS ALTERNATIVAS (TRADE-OFF)

Considera os custos que deixaremos de ganhar ao optar por uma alternativa em
detrimento de outra.

7.2.5 - CUSTOS AFUNDADOS

Considera os custos do que já foi investido no projeto, o que foi gasto e não há como
recuperar e não deve ser utilizado para decidir se o projeto deve continuar ou não.
 FGVIDT

7.2.6 - ROUGH ORDER OF MAGNITUDE (ROM)

Considera os custos identificados durante o processo de iniciação. A estimativa faz
uma análise de cima para baixo, estabelecendo uma variação aceitável do orçamento, que
pode ser de -25% até +75%.

7.2.7 - TOP DOWN

Considera as contas de controle e do projeto como um todo, não estimando atividades
nem pacotes de trabalho ou, se considerar, deverá estimar, de forma superficial.

7.2.8 - BOTTOM UP
Considera estimar os custos de baixo para cima, iniciando nas atividades, os pacotes
de trabalho até chegar nas contas de controle e no projeto como um todo. Essa estimativa
estabelece uma variação entre -5% e +10%.

7.2.9 - DEPRECIAÇÃO E OBSOLESCÊNCIA

Considera as despesas e a desvalorização dos bens que podem chegar do valor inicial
de aquisição até zero ao longo de um período determinado. Pode ser calculado como custo
dentro de projetos.
Indica quanto do ativo fixo estará sujeito à depreciação, à obsolescência ou ao
esgotamento. A diminuição de valor é denominada depreciação.

7.2.9.1 - DEPRECIAÇÃO FÍSICA

É decorrente de deterioração física – como, por exemplo, uma máquina que é
comprada e se desgasta ao longo da vida do projeto...

7.2.9.2 - DEPRECIAÇÃO CONTÁBIL

Esta depreciação considera quando um índice padrão é aceito pelo mercado – ou é de
mercado – como, por exemplo, quando um bem, mesmo sem uso, deve ser revendido e
perde valor devido a mudanças tecnológicas ou de gosto dos consumidores.

A obsolescência é a perda de valor de um bem renovável, decorrente do progresso

da técnica, de novas tecnologias.

O esgotamento é a perda de utilidade e do valor de um bem não renovável, como uma

mina, por exemplo.

Todo bem ou serviço tem uma vida útil, isto é, uma utilidade e, portanto, um valor que
se reduz por depreciação, obsolescência ou esgotamento. Essa perda é a que devemos
indicar.
O cálculo da depreciação – desvalorização – dos ativos renováveis utilizados no projeto
deve ser acrescido ao custo do projeto.
Por exemplo, uma máquina que é comprada ou cedida e que é utilizada durante o
projeto desvaloriza-se substancialmente.
Essa desvalorização é calculada com base na experiência de mercado, tal como é feito
 FGVIDT

no caso de automóveis e outros bens de consumo, que se desvalorizam em pouco tempo

quando novos e lentamente quando depois de usados.

Contudo, para parte dos bens, não havendo um mercado tão transparente como o de
automóveis, a desvalorização por uso deve ser calculada contabilmente.

Para alguns desses bens, de uso mais comum, existem tabelas de depreciação. Para
outros bens, a depreciação deve ser estimada.

7.2.9.3 - DEPRECIAÇÃO LINEAR

A depreciação linear é a forma de cálculo de depreciação em projetos mais utilizada.

A depreciação é dada extraindo-se, da duração do projeto, a fração do investimento no

ativo dividida pelos anos esperados de vida desse ativo.

Para um projeto de seis meses, o custo de depreciação de uma máquina será de duas
e meia unidades monetárias, ou seja, depressão linear = duração de projeto em anos.
 FGVIDT

Unidade 08 – PLANO DE
GERENCIAMENTO DOS RECURSOS
8.1 ESTIMAR OS RECURSOS DAS ATIVIDADES
É o processo de estimar os recursos necessários para executar as atividades previstas
no cronograma do projeto.

Os recursos que devem ser estimados são as necessidades em pessoas,

equipamentos e recursos físicos.

Uma maneira lógica e simplificada de contemplar a estimativa mais precisa dos

recursos é pela confecção de uma Estrutura Analítica dos Recursos (EAR).

Essa EAR, semelhante à EAP é uma estrutura hierárquica que contempla os recursos
identificados de forma organizada, por categorias e tipo de recursos, por relações como
subordinação e agrupamentos.

8.1.1 - ESTIMATIVA DE RECURSOS HUMANOS

A gestão dos recursos humanos em um projeto é particularmente delicada
devido à natureza temporária das relações de trabalho.

Por esse motivo, devemos ter em conta os aspectos psicológicos individuais e os

relativos ao trabalho em grupo na planificação dos recursos humanos que trabalharão no
projeto, além das operações comuns aos demais recursos.
Os passos para a provisão de recursos humanos são:
- identificação;
- quantidade;

- alocação;
- descrição;

- classificação;
- especificação;

- descrição de tarefas;
- listagem inicial.

8.1.1.1 - IDENTIFICAÇÃO DOS RECURSOS HUMANOS

A identificação se refere à tarefa de listar cada uma das pessoas necessárias à
execução de cada atividade, assinalando a atividade em que deverá trabalhar e o número
 FGVIDT

de horas, dias, ou outra unidade de periodização utilizada na rede e no cronograma.

Cada pessoa, mesmo profissionais que desempenharão funções idênticas, deve ser
nomeada individualmente, com exceção das pessoas que trabalharão sempre em grupo,
como no caso de grupos-tarefa.

8.1.1.2 - QUANTIDADE DOS RECURSOS HUMANOS

Quanto à quantidade, é importante verificar se as atividades não são simultâneas
e se estão superpostas.
No caso de superposição das atividades, o número de profissionais deverá ser
equivalente ao número de atividades superpostas.

8.1.1.3 - ALOCAÇÃO DOS RECURSOS HUMANOS

A alocação diz respeito a ordenar a utilização do profissional segundo a
sequência das atividades do projeto.
Esse procedimento poderá indicar a necessidade de modificações na sequência das
atividades.
Recursos humanos essenciais para o projeto ou de custo muito elevado podem levar
à recomendação de alterações substanciais na configuração do projeto.
Os softwares disponíveis realizam essas operações a partir da entrada nas atividades
dos recursos.
Os softwares fornecem distribuições reais e ideais, sob a forma de histogramas, e
reordenam, automaticamente, a rede do projeto.

8.1.1.4 - DESCRIÇÃO SUCINTA DOS RECURSOS HUMANOS

As tarefas de cada pessoa ou grupo de tarefa devem ser descritas, sucintamente, a
partir das necessidades de cada atividade.

8.1.1.5 - CLASSIFICAÇÃO DOS RECURSOS HUMANOS

A classificação diz respeito a separar os grupos de recursos humanos a serem
alocados no projeto de acordo com as relações de trabalho correspondentes.
A classificação é feita da seguinte forma:

- serviços contratados – que correspondem à mão de obra não vinculada ao projeto;

- mão de obra direta – cujo trabalho efetivamente será aplicado como tarefa necessária
à finalização de uma ou mais atividades;
- pessoal cedido – especificando a pauta de relações com outras organizações que
cedam pessoal ou na qual o projeto está inserido;
- mão de obra indireta – cujo trabalho consiste na administração do projeto e no
 FGVIDT

provimento das condições para que a mão de obra direta possa realizar seu trabalho.

8.1.1.6 - ESPECIFICAÇÃO DOS RECURSOS HUMANOS

A especificação diz respeito a detalhar, por atividade, a contribuição e o desempenho
esperado das pessoas que trabalharão no projeto.

8.1.1.7 - DESCRIÇÃO DE TAREFAS DOS RECURSOS HUMANOS

A descrição de tarefas para projetos difere, essencialmente, da descrição de
tarefas para trabalho continuado.
Embora o objetivo seja o mesmo – informar as responsabilidades, as habilidades, os
conhecimentos e as características esperadas dos colaboradores –, a tarefa é facilitada na
medida em que a descrição é feita a partir das atividades.

8.1.1.8 - LISTAGEM INICIAL DOS RECURSOS HUMANOS

A descrição é realizada listando-se as pessoas a serem vinculadas ao projeto por título
ou por encargo.
Em seguida, são detalhadas as tarefas, a duração, o momento e o custo de cada
intervenção.
Para que o recrutamento do pessoal possa ser realizado com eficiência, devem constar
as seguintes informações no projeto:
- disponibilidade;

- tipo de formação;
- experiência prévia requerida;

- tipo de colaboração esperada;

- remuneração, tanto no que se refere ao montante como à modalidade.

8.1.1.9 - MATRIZ RACI

A matriz RACI é uma ferramenta que apresenta os papéis e as responsabilidades de
execução, aprovação ou de consulta dos integrantes da equipe dentro do projeto.
 FGVIDT

Legenda:
R – Responsável – Aquele que executa uma atividade ou processo.
A – Aprova – Aquele que responde pela atividade ou processo, também é cobrado
pelo andamento da atividade ou processo.
C – Consultado – Aquelas pessoas que precisam ser consultadas – todos que podem
ajudar o andamento do projeto.
I – Informado – Aqueles que precisam ser informados sobre algo do projeto ou o
andamento do projeto.

8.2 - ESTIMATIVA DE EQUIPAMENTOS E

RECURSOS FÍSICOS
A gestão de ativos tangíveis é uma das tarefas mais complexas a serem enfrentadas
pelos gerentes de projetos.

Se possível, deve-se buscar eliminar o custo da imobilização de ativos, como o de

aquisição de material de uso permanente.

Ao estimar os recursos materiais, deve-se prever esquemas de empréstimo, de

aluguéis, de leasing e todas as formas de evitar os custos, tanto de aquisição como de
desmobilização de quaisquer ativos.
Um segundo elemento de grande importância no suprimento dos recursos é sua
relação com o ciclo de vida do projeto - os custos de obtenção de insumos e recursos podem
ser reduzidos por aquisições em lotes, por exemplo e, de outro lado, porque os níveis de
inovação e obsolescência tecnológica podem ser controlados de maneira mais efetiva
quando o ciclo de vida é programado.

8.2.1 - DESCRIÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS

 FGVIDT

A descrição se refere ao trabalho de descrever, sucintamente, os serviços, as

instalações, os equipamentos e os materiais por atividades.

Cada um dos bens a ser utilizado – instalações, equipamentos, materiais – deve ser
especificado.

Essa descrição deve ser feita de acordo com os padrões e a nomenclatura técnica
apropriada a cada bem.

No caso de obras civis e de equipamentos, pode ser necessária a contratação de

profissional especializado para a elaboração dos memoriais descritivos, documentos de
relação de materiais e de equipamentos de acordo com especificações e modalidades de
uso.

Como no caso dos recursos humanos, a descrição das atividades é a fonte básica de
obtenção dessas informações.
Para cada bem, devemos assinalar o número de horas ou dias de utilização. Cada bem
deve ser descrito de maneira individual.

8.2.2 - CONFLITO E SUPERPOSIÇÃO DOS EQUIPAMENTOS E

RECURSOS FÍSICOS
O conflito e a superposição relacionam-se ao verificarmos se não há conflito ou
superposição na utilização dos recursos, caso em que devemos multiplicar o número de
bens ou alterar a rede e o cronograma do projeto.

8.2.3 - SEQUENCIAÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS

A sequenciação diz respeito a ordenar a utilização dos bens segundo a sequência
de atividades do projeto.

Tal como com relação aos recursos humanos, os softwares dedicados a projetos
realizam os cálculos de alocação e de alteração da rede, bem como fornecem histogramas
de distribuição da utilização dos recursos.

8.2.4 - DISPÊNDIO DOS EQUIPAMENTOS E RECURSOS FÍSICOS

O dispêndio diz respeito a relacionar a estimativa de dispêndio.
A sequenciação diz respeito a ordenar a utilização dos bens segundo a sequência de
atividades do projeto.

8.2.5 - MODALIDADES DE AQUISIÇÃO DOS EQUIPAMENTOS E

RECURSOS FÍSICOS
As modalidades de aquisição relacionam-se ao indicar as opções por aquisição,
aluguel ou leasing.
O ponto principal é a análise comparativa entre as várias opções, incluindo a opção
pela produção do bem como passo ou subprojeto.
Tanto a geração de informações como a manufatura de equipamentos, sobretudo
 FGVIDT

ferramental, pode ser mais econômica do que a compra.

Para certos tipos de projetos, sobretudo aqueles nos quais são usados
equipamentos dispendiosos, utiliza-se um sistema de arrendamento, conhecido como
leasing.

O leasing é um arranjo entre o detentor de um equipamento ou bem e um arrendatário

para que o último possa usá-lo.

Durante o período de leasing, o arrendatário faz pagamentos regulares, como se fosse

um aluguel.

Esses pagamentos são estruturados pelo dono do bem ou equipamento, de forma a

cobrir os custos financeiros, os de aquisição e uma margem de lucro.

No fim do período, o bem ou equipamento é vendido pela diferença ao arrendatário

devolvido – leasing operacional –, ou arrendado outra vez.
O sistema de leasing pode ser recomendável quando a renda a ser paga é próxima a
de um aluguel ou quando o bem ou serviço é caro em relação ao orçamento do projeto e há
vantagens em termos de taxação e impostos.
Contudo, os preços de leasing costumam ser bastante vantajosos, pois o proprietário
do bem ou equipamento pode arrendá-lo várias vezes a vários projetos.

8.2.6 - FORNECEDORES DOS EQUIPAMENTOS E RECURSOS FÍSICOS

Tratar de fornecedores nos remete ao ato de indicar a origem provável dos recursos a
serem utilizados durante o projeto.

Uma parte significativa desses bens pode ser fornecida diretamente pela organização
a qual se filia o projeto.

Contudo, mesmo nesses casos, a origem e a disponibilidade dos bens devem ser
assinaladas.

Na configuração do projeto, devem constar:

- os critérios de avaliação;

- uma listagem de fornecedores potenciais;

- uma avaliação prévia dos potenciais fornecedores.

8.2.7 - RECUPERAÇÃO DOS EQUIPAMENTOS E RECURSOS FÍSICOS

A recuperação relaciona-se ao ato de estimar a depreciação e o valor venal dos bens
adquiridos para o projeto.
Sempre que for possível, devemos assinalar as possibilidades concretas de
reaver o investimento para que os retornos possam ser abatidos do custo final do
projeto.
 FGVIDT

8.2.8 - RESPONSABILIDADE SOBRE OS EQUIPAMENTOS E

RECURSOS FÍSICOS
A responsabilidade diz respeito a indicar os responsáveis pela assinatura e pelo
acompanhamento dos contratos referentes aos bens tangíveis.

Essas informações alimentarão a Matriz de Responsabilidades, um dos instrumentos

mais comuns no controle de projetos.

8.2.9 - TIPOS DE CONTRATO DOS EQUIPAMENTOS E RECURSOS

FÍSICOS
Os tipos de contrato utilizados em projetos apresentam grande variedade. Por esse
motivo, é importante a especificação dos padrões a serem adotados na etapa de
configuração.
Os contratos referentes a bens tangíveis deverão conter:

- as datas de entrega;
- a descrição dos bens;

- as cláusulas de multa;
- as restrições e ressalvas;

- os indicadores de performance;
- os preços e as formas de pagamento;

- a descrição dos serviços associados à aquisição dos bens.

Quanto às restrições e ressalvas, é preciso incluir as restrições orçamentárias, os
preços máximos suportados pelo projeto e as ressalvas relacionadas à qualidade e aos
impedimentos legais.

As organizações às quais o projeto está vinculado costumam fornecer contratos

padronizados, que podem ser adaptados às necessidades do projeto. O
assessoramento jurídico também pode ser obtido dessa forma.
Uma atenção especial deve ser dada às condições legais dos fornecedores e às
subcontratações.
No caso de fornecedores pertencentes à organização em que o projeto é desenvolvido,
devemos procurar sempre a formalização dos compromissos de fornecimento e das sansões
correspondentes em caso de falha.

8.3 - ESTRUTURA ANALÍTICA DE RECURSOS

(EAR)
De início, devemos inserir todos os recursos que serão utilizados nas atividades do
 FGVIDT

projeto na planilha de recursos.

Dessa forma, o trabalho posterior de alocação de recursos em cada uma das
atividades é facilitado.
Na planilha, é possível separar os recursos por grupos.

Na planilha, há também lacunas específicas para a inserção da quantidade total de

recursos a ser disponibilizado para o projeto e o custo de cada recurso.

Os softwares enfatizam a gestão de projetos e, por essa razão, apresentam uma série
de mecanismos que possibilitam a gestão de multiprojetos para os quais estão
especificamente destinados.
A Estrutura Analítica de Recursos facilita a visualização, de forma gráfica, dos
recursos por grupos.
 FGVIDT

Unidade 09 – PLANO DE
GERENCIAMENTO DOS RISCOS
9.1 - GERENCIAMENTO DOS RISCOS
O objetivo do gerenciamento de riscos deve ser maximizar a chance e impactos
positivos, ao mesmo tempo em que se deve mitigar a chance de ocorrência dos impactos
negativos.
Os riscos são ocorrências negativas passíveis de incidirem sobre o projeto. Os riscos
são dados pelo conjunto de efeitos e de externalidades negativas.
As falhas na concepção do projeto também podem representar riscos para o projeto,
por exemplo:
- erros e omissões nas especificações de recursos;

- definições de responsabilidades truncadas ou pouco claras;

- erros e omissões na especificação de efeitos e externalidades;

- admitir pouca margem de erro no cronograma ou no orçamento.

Os projetos que envolvem a produção ou a geração de serviços inéditos, inovadores
ou revolucionários envolvem mais riscos do que outros.
Os riscos do projeto podem ser calculados e minimizados mediante a:

- coleta de dados de mercado e informações comerciais;

- coleta de informações sobre a história recente do setor, da área, do mercado e dos
públicos;
- descrição sistemática e tão exaustiva quanto possível dos efeitos e das
externalidades positivas e negativas.
As taxas de risco associadas ao projeto são máximas na fase de lançamento e
declinam até o término das atividades. O lançamento assinala o momento da conversão, isto
é, o momento e que a maior parte dos recursos financeiros é efetivamente alocada e o
compromisso com o projeto torna-se irreversível.
A taxa é maior porque a exposição dos financiadores é alta e os resultados do projeto
ainda estão por aparecer.
As formas de atenuação de risco examinadas no passo referente à sequenciação e à
adoção de esquemas, como o da periodização por abortagem, podem atenuar,
substancialmente, a taxa máxima de risco.
 FGVIDT

Ciclo de vida Receita x Riscos

9.1.1 - IDENTIFICAR OS RISCOS

Os riscos precisam ser identificados conforme a sua natureza:
- financeiros;

- operacionais;
- institucionais e legais;

- administrativos e de marketing.

9.1.1.2 - RISCOS OPERACIONAIS E RISCOS ADMINISTRATIVOS E DE

MARKETING
Os riscos operacionais envolvem:

- recursos;
- transporte;

- comunicações;
- esperas e atrasos;

- eventos não previsíveis;

- custos acima do orçamento.

Os riscos administrativos e de marketing envolvem:

- competidores;

- obsolescência;
 FGVIDT

- custos operacionais;
- flutuações no mercado.

9.1.1.3 - RISCOS FINANCEIROS E RISCOS INSTITUCIONAIS E LEGAIS

Os riscos financeiros envolvem:
- mudanças em tarifas;

- flutuações nas taxas de juros;

- flutuações na taxa de câmbio;
- flutuações nos custos de insumos;

- mudanças nas exigências de crédito;

- flutuações nos preços do produto/serviço.

Os riscos institucionais e legais envolvem:

- expropriações;

- instabilidade política;
- mudanças na legislação;

- dissociação, quando um financiador desiste de financiar sua parte;

- prejuízos de terceiros, como o risco de provocar desastre ambiental.

9.2 - REALIZAR A ANÁLISE QUALITATIVA DOS

RISCOS
Os riscos devem ser dispostos de acordo com a magnitude do impacto e a
probabilidade de ocorrência.
Uma matriz de análise é útil para calcular e para informar sobre as respostas às
situações de risco.
A Análise Qualitativa de Riscos prioriza os riscos de projeto identificados usando uma
escala de classificação predefinida. Os riscos serão pontuados com base em sua
probabilidade ou severidade de ocorrer e o impacto nos objetivos do projeto, caso ocorram.

A probabilidade é comumente classificada em uma escala de zero a um (por exemplo,

0,3 equivale a 30% de probabilidade de ocorrência do evento de risco).

A escala de impacto é definida organizacionalmente (por exemplo, uma escala de um

a sete, com sete sendo o maior impacto nos objetivos do projeto - como orçamento,
cronograma ou qualidade).
Uma análise de risco qualitativa também incluirá a categorização apropriada dos riscos,
seja com base na fonte ou com base no efeito.
 FGVIDT

Exemplo de Análise Qualitativa de Riscos

Para qualificar Probabilidades:

5 – Alta: chance superior a 50%

3 – Média: chance entre 10 e 50%

1 – Baixa: chance inferior a 10%

Para qualificar Impactos:

7 – Alto: conflito e negociação entre stakeholders; prejudica a imagem e reputação do

gerenciador e da organização; provoca mudanças drásticas.

4 – Médio: envolve outros stakeholders; alçada superior para a decisão; provoca

mudança de metas.

1 – Baixo: passa desapercebido; alçada do gerenciador; provoca mudança de planos

mas não de metas.

O cálculo da Severidade será obtido por meio da multiplicação da Probabilidade X a

Magnitude do Impacto.

9.3 - REALIZAR A ANÁLISE QUANTITATIVA DOS

RISCOS
A Análise Quantitativa de Riscos é uma análise adicional dos riscos de prioridade mais
alta durante a qual uma classificação numérica ou quantitativa é atribuída para desenvolver
uma análise probabilística do projeto.

A Análise Quantitativa quantifica os resultados possíveis para o projeto e avalia a

probabilidade de atingir os objetivos específicos do projeto. Ela fornece uma abordagem
 FGVIDT

quantitativa para a tomada de decisões quando há incerteza e cria metas realistas e

alcançáveis de custo, cronograma ou escopo.

Para realizar uma análise quantitativa de riscos, é necessário possuir dados de alta
qualidade, um modelo de projeto bem desenvolvido e uma lista priorizada de riscos do
projeto (geralmente de realizar uma análise de risco qualitativa).

9.4 - PLANEJAR RESPOSTAS AOS RISCOS

A forma de tratamento dos riscos do projeto na fase de configuração dá-se pela
montagem de estratégias de resposta, tais como: a inclusão de formas de securitização do
projeto; a flexibilização dos elementos de configuração do projeto; a criação de planos de
contingência para os maiores riscos.

Para alguns riscos, é factível a cobertura tradicional dada pelas apólices de seguros,
em termos de custos/benefícios. Em outros casos, a segurança vem de contratos de
contingência, como a de preços mínimos para o setor agrícola, ou da dispersão do risco
entre patrocinadores, fornecedores, clientes.

A análise de cenários, muitas vezes, indica a probabilidade de ocorrência de situações

de risco para o projeto.

Embora nada possa ser feito para livrar o projeto de riscos, podemos reduzi-los ou
desviar o curso do projeto dessas situações por meio da configuração de alguns
instrumentos preventivos.
Dentre as práticas e os instrumentos utilizados com melhor resultado, temos...

- seguro;
- absorção;

- duplicidade;
- transferência;

- compartilhamento;
- emergência programada.

9.4.1 - SEGURO

O seguro, forma mais óbvia de prevenção contra incertezas.

No entanto, há um grupo de itens para os quais o seguro pode ser conveniente.

Em linhas gerais, os prêmios são caros por causa da pouca tradição de concorrência
e do despreparo de corretores, atuários e especialistas da área de seguros em lidar com
riscos menos comuns, como os que incorrem em projetos.
 FGVIDT

Ao contrário, os prêmios para riscos convencionais, como os contra incêndio e furtos,

são suportáveis.

9.4.2 - ABSORÇÃO
A absorção consiste em considerar a situação de risco como ocorrência factual.

Essa prática é útil somente para situações em que o risco envolvido acarreta custos e
perda de tempo reduzidos.

9.4.3 - DUPLICIDADE
A duplicidade consiste em duplicar os recursos, as atividades e as tarefas que
possam ser encontradas em situação de risco.
Essa duplicidade pode incluir tanto os sobressalentes, as peças de reposição quanto a
conformação de duas fontes de informação ou de recursos.
Ao contrário do que possa parecer, essa é uma prática que, se adotada em termos
técnicos, acarreta custos marginais nulos ou reduzidos.
É frequente que sistemas concorrenciais internos ao projeto, face ao estímulo da
competição, gerem reduções de tempo e de custos.

9.4.4 - TRANSFERÊNCIA
A transferência consiste em passar o risco para os fornecedores, os parceiros, os
financiadores.

A transferência de risco implica custos, equivalente ao do prêmio de um seguro.

O exemplo mais comum de transferência de risco são os contratos a preços fixos, em
que o fornecedor garante o preço.
Logicamente, o custo do recurso aumenta na medida em que os fornecedores
embutem o risco como pro rata em seus preços.
Contudo, essa ainda é uma prática conveniente para mercados instáveis, para
recursos escassos.

9.4.5 - COMPARTILHAMENTO
O compartilhamento consiste em dividir os riscos com parceiros, fornecedores.
Um exemplo de compartilhamento de riscos ocorre quando prêmios de seguros ou
custos de absorção são divididos entre a instituição matriz do projeto e o próprio projeto.
Essa forma é um dos motivadores do incremento recente de projetos realizados em
parceria por duas ou mais instituições.

9.4.6 - EMERGÊNCIA PROGRAMADA

A emergência programada consiste em mapear recursos, atividades ou canais que
possam ser acionados no caso de falhas operacionais ou de ocorrências não previsíveis.
 FGVIDT

Trata-se do mesmo princípio que nos leva a manter por perto os telefones dos
bombeiros, das ambulâncias.

9.5 PLANO DE CONTINGÊNCIA

Na maioria dos casos, um plano de contingência deve ser elaborado para responder a
um evento negativo ou riscos que podem surgir durante os projetos.
O plano de contingência é uma estratégia proativa, diferente de um plano de
gerenciamento de crise, que é mais uma reação a algo que aconteceu.
Um plano de contingência a riscos identificados deve ser elaborado para permitir
responder adequadamente aos riscos, que ocorreram e o plano de resposta não foi capaz
de mitigá-lo.

Um plano de contingência é um plano e, como qualquer plano existem etapas a serem

seguidas para garantir que seja eficiente.

9.5.1 - ELABORAÇÃO DE UM PLANO DE CONTINGÊNCIA

Identificar e priorizar os recursos: listar os recursos cruciais do projeto, como
equipes, material, equipamentos, instalações, etc., em seguida, priorizar a lista do risco mais
importante para o menos importante.

Mapear os riscos críticos: identificar as vulnerabilidades, reunindo-se com equipes,

executivos e todos os outros envolvidos para obter uma imagem completa de quais eventos
podem comprometer o projeto. Se for o caso, deve-se contratar um consultor externo para
mapear os riscos considerados críticos.

Compartilhar o plano: depois de escrever o plano de contingência e ele for aprovado,

a próxima etapa é garantir que todos na equipe do projeto tenham uma cópia. Um plano de
contingência, não importa o quão completo seja, não será eficaz se não for comunicado
adequadamente.

Revisitar o plano: um plano de contingência deve ser revisado para refletir as

mudanças no projeto.
 FGVIDT

Unidade 10 – PLANO DE
GERENCIAMENTO DA QUALIDADE
O Plano de Gerenciamento da Qualidade é responsável pelo processo de identificação
dos requisitos e ou padrões de qualidade do projeto e suas entregas, além da documentação
de como o projeto demonstrará conformidade com os requisitos e ou padrões de qualidade
O gerenciamento da qualidade do projeto engloba os processos e atividades que são
usados para descobrir e alcançar a qualidade das entregas de um projeto. No entanto,
qualidade pode ser uma palavra ambígua.

Qualidade é o que o cliente ou as partes interessadas precisam dos resultados do

projeto. Ao manter a definição vinculada ao cliente ou às partes interessadas, a gestão da
qualidade pode ter um foco mais restrito, o que significa que é mais provável atingir seus
objetivos.

10.1 - CONCEITOS DE GERENCIAMENTO DA

QUALIDADE DO PROJETO
Os gerentes de projeto supervisionam a implementação de um plano de gerenciamento
da qualidade do projeto. A ideia principal é entregar um produto ou serviço com as
especificações do cliente ou partes interessadas.

10.1.1 - SATISFAÇÃO DO CLIENTE

Sem a satisfação do cliente, não pode haver qualidade. Mesmo que uma entrega
atenda a todos os aspectos do que o cliente ou parte interessada exigiu, mas foi feito onde
o próprio processo não foi satisfatório, então há um problema.
A entrega deve atender aos requisitos acordados ou então o projeto falhou porque o
produto do projeto e a gestão do projeto não atendeu às expectativas do cliente ou das partes
interessadas.

Implementar o controle de qualidade significa gerenciar processos e pessoas. É

importante reunir com os clientes ou partes interessadas, regularmente, para mantê-los a
par do progresso do projeto e obter deles o feedback, certificando-se de ser totalmente
transparente com eles para evitar problemas que surjam mais tarde.

A qualidade é alcançada quando um produto ou serviço cumpre completamente os

requisitos do cliente.

10.1.2 - CUSTO DA QUALIDADE

A qualidade não vem de graça, ela tem custos. O Custo da Qualidade (COQ) é o
dinheiro gasto lidando com problemas durante o projeto e depois do projeto, para consertar
 FGVIDT

quaisquer falhas.
Os custos de qualidade são divididos em duas categorias: custo de conformidade e
custo de não conformidade.
O custo da conformidade pode ser considerado um custo preventivo. Esses custos
estão principalmente relacionados ao treinamento, ao processo de documentação, aos
equipamentos necessários e ao tempo necessário para que a qualidade seja bem feita.
Outros custos relacionados a isso podem incluir testes, perda de testes destrutivos e
inspeções.

O custo da não conformidade se refere aos custos de falha interna. Estes consistem
em ter que retrabalhar algo ou até mesmo descartá-lo inteiramente. Outros custos podem vir
de responsabilidades, trabalho de garantia e negócios perdidos.

10.1.3 - MELHORIA CONTÍNUA

Este conceito corresponde a um esforço contínuo para abordar as melhorias das
entregas ao longo do tempo. Seja por meio de pequenas mudanças incrementais ou
grandes, a oportunidade de identificar e lidar com mudanças está sempre presente.
Aplicar este conceito também significa monitorar e documentar constantemente
quaisquer problemas que surjam, para que as lições aprendidas venham a ajudar a gerenciar
projetos futuros. Dessa forma, um projeto feito de forma mais eficiente, provavelmente não
repetirá erros.

10.2 - ETAPAS DO GERENCIAMENTO DE

PROJETOS DE QUALIDADE
Depois de ter uma ideia dos diferentes conceitos, a próxima etapa é implementar um
plano de gerenciamento da qualidade do projeto.

10.2.1 - QUALIDADE DO PLANO

O primeiro passo é identificar os requisitos de qualidade das entregas e como o projeto
precisa ser gerenciado. Deve-se definir como este processo será documentado e como
essas informações serão fornecidas. Por exemplo, as informações de reuniões regulares ou
por e-mails, ou vídeo-conferências...

O plano incluirá esses requisitos de comunicação, bem como as métricas para medir a
qualidade durante o gerenciamento do projeto. Isso deve incluir uma lista de verificação de
qualidade para coletar e organizar as metas estipuladas para atingir durante o projeto.

10.2.2 - GARANTIA DA QUALIDADE

Garantir a qualidade é garantir que as atividades planejadas e implementadas atendam
aos requisitos de qualidade de um produto ou serviço.

Esta etapa visa garantir que os processos estejam de fato trabalhando para que as
entregas do projeto atendam aos requisitos de qualidade. Duas ferramentas que auxiliam
 FGVIDT

esse processo são a lista de verificação de processo e uma auditoria de projeto.

10.2.3 - CONTROLE DE QUALIDADE

Todo processo precisa de controles para se certificar de que as regras estão sendo
seguidas e que a qualidade esperada está sendo cumprida. Algumas maneiras de garantir
que a qualidade exigida das entregas seja alcançada é por meio de análises e testes por
pares. É essencial verificar a qualidade das entregas durante o processo de gerenciamento
do projeto, a fim de ajustar as entregas, caso não estejam atendendo aos padrões que foram
definidos. Isso pode ser feito no final do projeto, mas não é tão eficiente refazer em vez de
reajustar.

10.2.4 - FERRAMENTAS DE CONTROLE DA QUALIDADE

As principais ferramentas utilizadas no controle de qualidade são:
- Fluxograma de processos;

- Diagrama de Causa e Efeito (Diagrama de Espinha de Peixe);

- Folhas ou Listas de Verificação;

- Diagrama de Pareto;
- Diagrama de Dispersão;

- Histograma; e
- Carta de Controle.
 FGVIDT

Unidade 11 - PLANO DE
GERENCIAMENTO DAS COMUNICAÇÕES
Planejar o gerenciamento das comunicações é o processo para desenvolver uma
abordagem e plano adequado para atividades de comunicação do projeto baseado nas
necessidades de informação de cada parte interessada ou grupo, de ativos organizacionais
disponíveis e nas necessidades do projeto.
O benefício deste processo específico de gerenciamento de projetos é que ele ajuda a
identificar e documentar os planos, abordagens ou estratégias na comunicação eficaz com
as partes interessadas.

Para criar o Planejamento de Gerenciamento das Comunicações, são necessárias

as entradas necessárias, como o plano de gerenciamento do projeto, ativos de processos
organizacionais e fatores ambientais da empresa. O Gerente do Projeto também precisa
obter o registro das partes interessadas para saber quem são as partes interessadas.

É importante observar que este processo é contínuo e pode ser acionado pela
comparação do cronograma real e planejado, custo e qualidade. Por último, é crucial que o
Gerente do Projeto avalie as informações para garantir que a mensagem certa seja entregue
às partes interessadas.

11.1 - GERENCIAMENTO DAS COMUNICAÇÕES

O objetivo do Plano de Gerenciamento das Comunicações é definir os requisitos de
comunicação do projeto e como as informações serão distribuídas.
O Plano define o seguinte:

• Quais informações serão comunicadas - para incluir o nível de detalhe e formato.

• Como as informações serão comunicadas - em reuniões, e-mail, telefone, portal da
web, etc.
• Quando as informações serão distribuídas - a frequência das comunicações do projeto
formais e informais.
• Quem é o responsável por comunicar as informações do projeto.

• Requisitos de comunicação para todas as partes interessadas do projeto.

• Quais são os recursos que o projeto aloca para comunicação.

• Como qualquer informação sensível ou confidencial é comunicada e quem deve

autorizar isso.
• Como as mudanças na comunicação ou no processo de comunicação são
 FGVIDT

gerenciadas.
• Qual é o fluxo das comunicações do projeto.

• Quais são as restrições, internas ou externas que afetam as comunicações do projeto

• Quais são os modelos, formatos ou documentos padrão que o projeto deve usar para
se comunicar.
• Qual é o processo de escalonamento para resolver quaisquer conflitos ou problemas
baseados na comunicação.

11.2. - ESTRUTURA DO PLANO DE

GERENCIAMENTO DAS COMUNICAÇÕES
11.2.1 - ABORDAGEM DO GERENCIAMENTO DAS COMUNICAÇÕES
Aproximadamente 80% do tempo de um Gerente do Projeto é gasto em comunicação.
O Gerente do Projeto passa a maior parte do seu tempo medindo e relatando o desempenho
do projeto, escrevendo e lendo e-mails, conduzindo reuniões, escrevendo o plano do projeto,
reunindo-se com membros da equipe, supervisionando o trabalho sendo executado e muitas
outras atividades relacionadas aos seus projetos.
O Gerente do Projeto assumirá um papel proativo para garantir comunicações eficazes
do projeto. Os requisitos de comunicação devem ser documentados na Matriz de
Comunicações. A Matriz de Comunicações servirá de guia para saber quais informações
comunicar, quem deve comunicar, quando comunicar e a quem comunicar.
Como acontece com a maioria dos planos de projeto, atualizações ou mudanças
podem ser necessárias conforme o projeto avança ou as mudanças são aprovadas.
Mudanças ou atualizações podem ser necessárias devido a mudanças no pessoal, escopo,
orçamento ou outros motivos. Além disso, podem ser necessárias atualizações conforme o
projeto amadurece e requisitos adicionais são necessários.

O Gerente do Projeto é responsável por gerenciar todas as mudanças propostas e

aprovadas no plano de gerenciamento de comunicações. Assim que a mudança for
aprovada, o Gerente do Projeto atualizará o plano e a documentação de suporte e distribuirá
as atualizações para a equipe do projeto e todas as partes interessadas.

11.2.2 - RESTRIÇÕES DO GERENCIAMENTO DAS COMUNICAÇÕES

Todos os projetos estão sujeitos a limitações e restrições, pois devem estar dentro do
escopo e cumprir os requisitos de orçamento, programação e recursos.
O planejamento e a documentação do projeto não são exceção a esta regra. Também
pode haver requisitos legislativos, regulamentares, de tecnologia ou de política
organizacional que devem ser seguidos como parte do gerenciamento de comunicações.

Essas restrições devem ser claramente compreendidas e comunicadas a todas as

 FGVIDT

partes interessadas. Embora o gerenciamento das comunicações seja indiscutivelmente um

dos aspectos mais importantes do gerenciamento de projetos, ele deve ser feito de maneira
eficaz e dentro das restrições de orçamento, tempo e recursos alocados.
Todas as atividades de comunicação do projeto ocorrerão dentro do orçamento,
cronograma e alocações de recursos aprovados do projeto. O gerente do projeto é
responsável por garantir que as atividades de comunicação sejam realizadas pela equipe do
projeto e sem recursos externos, o que resultará em exceder o orçamento autorizado. As
atividades de comunicação ocorrerão de acordo com as frequências detalhadas na Matriz
de Comunicação, a fim de garantir que o projeto cumpra as restrições de cronograma.
Qualquer desvio desses cronogramas pode resultar em custos excessivos ou atrasos no
cronograma e deve ser aprovado pelo patrocinador do projeto.

11.2.3 - REQUISITOS DE COMUNICAÇÃO DAS PARTES INTERESSADAS

A maioria dos projetos consiste em uma ampla gama de partes interessadas, todas as
quais podem ter interesses e influências diferentes no projeto. Dessa forma, é importante
que as equipes de projeto determinem os requisitos de comunicação dessas partes
interessadas para comunicar as informações do projeto de maneira mais eficaz.

Existem vários métodos para determinar os requisitos de comunicação das partes

interessadas. No entanto, é fundamental que sejam totalmente compreendidos para
gerenciar com eficácia seus interesses, expectativas e influência e garantir um projeto bem-
sucedido.

Como parte da identificação de todas as partes interessadas do projeto, o gerente do

projeto se comunicará com cada uma delas para determinar sua frequência e método de
comunicação preferidos.
Este feedback será mantido pelo Gerente do Projeto no Registro de Partes
Interessadas do projeto. As comunicações padrão do projeto ocorrerão de acordo com a
Matriz de Comunicação; no entanto, dependendo dos requisitos de comunicação das partes
interessadas identificados, a comunicação individual é aceitável e está dentro das restrições
descritas para este projeto.
Além de identificar as preferências de comunicação, os requisitos de comunicação das
partes interessadas devem identificar os canais de comunicação do projeto e garantir que
as partes interessadas tenham acesso a esses canais. Se as informações do projeto forem
comunicadas por meios seguros ou por recursos internos da empresa, todas as partes
interessadas, internas e externas, devem ter o acesso necessário para receber as
comunicações do projeto.
Assim que todas as partes interessadas forem identificadas e os requisitos de
comunicação forem estabelecidos, a equipe do projeto manterá essas informações no
Registro das Partes Interessadas do projeto e usará isso, juntamente com a matriz de
 FGVIDT

comunicação do projeto como base para todas as comunicações.

11.3 - PRINCIPAIS PAPÉIS NO GERENCIAMENTO

DAS COMUNICAÇÕES
11.3.1 - PATROCINADOR DO PROJETO
O patrocinador do projeto é quem autorizou o projeto ao assinar o Termo de Abertura
do Projeto. Essa pessoa é a responsável pelo financiamento do projeto e, em última
instância, pelo seu sucesso. Como o patrocinador do projeto está no nível executivo, as
comunicações devem ser apresentadas em formato de resumo, a menos que o patrocinador
do projeto solicite comunicações mais detalhadas.

11.3.2 - GERENTE DE PROGRAMA

O Gerente do Programa supervisiona o projeto no nível do portfólio (se houver) e
possui a maioria dos recursos atribuídos ao projeto. O Gerente do Programa é o responsável
pelos custos gerais do programa e pela lucratividade, pois eles exigem comunicações mais
detalhadas do que o patrocinador do projeto.

11.3.3 - PRINCIPAIS INTERESSADOS

Normalmente, as partes interessadas incluem todos os indivíduos e organizações que
são afetados pelo projeto. Um projetopode ter um subconjunto de partes interessadas como
principais interessados. Essas são as partes interessadas com as quais precisamos nos
comunicar e não estão incluídas nas outras funções. Os principais interessados incluem a
gerência executiva com interesse no projeto e os principais usuários identificados para
participação no projeto.

11.3.4 - CLIENTES
Inicialmente, é preciso verificar se o cliente estará envolvido na revisão de protótipos,
aprovação de projetos e estágios de implementação e aceitação do projeto final gerado pelo
projeto.

Deverá definir como o cliente aceitará a entrega final do projeto, se ele será informado
do status do projeto, incluindo os impactos potenciais no cronograma para a entrega final ou
no próprio produto.

11.3.5 - GERENTE DO PROJETO

O Gerente do Projeto tem responsabilidade geral pela execução do projeto. É ele quem
irá gerenciar os recursos do dia a dia, fornecer a orientação do projeto e monitorar e relatar
as métricas do projeto, conforme definido no Plano de Gerenciamento do Projeto.
Como é a pessoa responsável pela execução do projeto, o Gerente do Projeto é o
comunicador principal do projeto, distribuindo informações de acordo com o Plano de
Gerenciamento das Comunicações.

11.3.6 - EQUIPE DO PROJETO

 FGVIDT

A equipe do projeto é composta por todas as pessoas que têm uma função
desempenhando um trabalho no projeto. A equipe do projeto precisa ter um entendimento
claro do trabalho a ser concluído e da estrutura na qual o projeto deve ser executado. Como
a equipe do projeto é responsável por concluir o trabalho para o projeto, ela desempenhou
um papel fundamental na criação do plano do projeto, incluindo a definição de seu
cronograma e pacotes de trabalho.

A equipe do projeto requer um nível detalhado de comunicação, que é obtido por meio
de interações do dia a dia com o Gerente do Projeto e outros membros da equipe, juntamente
com reuniões semanais da equipe.

11.3.7 - COMITÊ DE DIREÇÃO

O Comitê de Direção (se for o caso) inclui os gestores que representam os
departamentos que compõem a organização e deve fornecer a supervisão estratégica para
mudanças que impactam a organização como um todo.
O objetivo do Comitê de Direção é garantir que as mudanças dentro da organização
sejam efetuadas de forma a beneficiar a organização como um todo. O Comitê de Direção
exige comunicação sobre assuntos que irão alterar o escopo do projeto e seus resultados.

11.3.8 - LÍDER TÉCNICO

O Líder Técnico é uma pessoa da Equipe do Projeto que é designada como
responsável por garantir que todos os aspectos técnicos do projeto sejam tratados e que o
projeto seja implementado de maneira tecnicamente sólida.

O Líder Técnico é o responsável por todos os projetos técnicos, supervisionando a

implementação dos projetos e desenvolvendo a documentação prevista.

O Líder Técnico requer comunicação próxima com o Gerente do Projeto e a equipe do

projeto.

A tabela a seguir apresenta as informações de contato de todas as pessoas

identificadas no Plano de Gerenciamento das Comunicações.

Os endereços de e-mail e números de telefone da tabela serão usados para se

comunicar com as pessoas.
 FGVIDT

Papel Nome Título Organização/ Email Telefone

Departmento
Patrocinador Alexandre Diretor de TI a.lira@abcde.com (55)21 4555-
do Projeto Lira Tecnologia 1212

Gerente do Bráulio Gerente Escritório de b.messias@abcde.com (55)21 4555-

Programa Messias Projetos 1313

Gerente do Antonio José Gerente do Escritório de a.silva@abcde.com (55) 21

Projeto Silva Projeto Projetos 4555-1414

Partes Ver Ver Ver Ver Ver

interessadas Registro de Registro de Registro de Registro de Partes Registro de
Partes Partes Partes Interessadas Partes
do projeto Interessadas Interessadas Interessadas Interessadas

Cliente Altair Manager Incorporadora a.ananka@ipalma.com.br (55)11 2555-

Ananka Palma 8121

Equipe do
Projeto

Líder
Técnico

11.4 - MÉTODOS E TECNOLOGIAS DE

COMUNICAÇÃO
Muitas vezes, os métodos e tecnologias usados para se comunicar são tão
importantes quanto as informações que estão sendo comunicadas.
Um grande projeto com muitos stakeholders, todos com diferentes capacidades
tecnológicas. Alguns podem ter acesso a recursos compartilhados, enquanto outros não.
Alguns podem ter acesso à videoconferência e outros só têm recursos de telefone e
e-mail.
Para serem eficazes, as informações do projeto devem ser comunicadas a todos os
envolvidos por algum método usando a tecnologia disponível.
A determinação dos métodos de comunicação e quais tecnologias estão disponíveis
deve fazer parte da determinação dos requisitos de comunicação das partes interessadas.
 FGVIDT

11.5 - DIRETRIZES PARA AS REUNIÕES

11.5.1 - AGENDA DA REUNIÃO
A agenda do dia da reunião deverá ser distribuída 5 dias úteis antes da reunião. A
agenda deve identificar o apresentador para cada tópico junto com um limite de tempo para
aquele tópico. O primeiro item da agenda deve ser uma revisão dos itens de ação da reunião
anterior.

11.5.2 - ATAS DE REUNIÃO

As atas das reuniões deverão ser distribuídas dentro de 2 dias úteis após a reunião. As
atas da reunião incluirão o status de todos os itens da agenda junto com os novos itens de
ação e a lista do estacionamento.

11.6 - PADRÕES DE COMUNICAÇÃO

A padronização é uma forma comprovada de simplificar as complexidades das
comunicações de gerenciamento de projetos. Muitas organizações desenvolvem e usam
modelos ou formatos padrão para as várias ferramentas de comunicação usadas em todos
os projetos.

Os modelos e formatos padrão podem ser aplicados a certos tipos de reuniões de

projeto ou tipos específicos de comunicação (ou seja, e-mails, relatórios de status, etc.).

Usando a padronização, as organizações podem ajudar a garantir que suas equipes

de projeto e partes interessadas tenham um entendimento completo do que é esperado e
alcancem comunicações consistentes e eficazes.
Além dos modelos ou formatos padrão as organizações podem padronizar a
nomenclatura de arquivos ou convenções de compartilhamento.

Uma organização pode usar ferramentas de portal, rede ou armazenamento em nuvem

como uma plataforma padrão para compartilhar informações e se comunicar. Além disso, a
organização pode ter convenções de nomenclatura de arquivo padrão para seus dados
armazenados em suas unidades de compartilhamento interno.

Muitas dessas ferramentas e novas tecnologias são usadas nos projetos de hoje com
membros da equipe e partes interessadas, às vezes espalhadas por amplas áreas
geográficas. A padronização fornece um nível de simplicidade para as plataformas de
comunicação de uma organização e melhora a eficácia e eficiência.

11.7 PROCESSO DE ESCALA DE COMUNICAÇÃO

Conforme surgem problemas ou complicações com relação às comunicações do
projeto, pode ser necessário escalar o problema se uma resolução não puder ser alcançada
dentro da equipe do projeto.
 FGVIDT

As partes interessadas do projeto podem ter muitos interesses conflitantes diferentes

em um determinado projeto. Embora as escalações sejam uma parte normal do
gerenciamento de projetos, deve haver um processo documentado que defina como essas
escalações ocorrerão.

A comunicação eficiente e oportuna é a chave para a conclusão bem-sucedida do

projeto. Como tal, é imperativo que quaisquer disputas, conflitos ou discrepâncias em relação
às comunicações do projeto sejam resolvidos de forma a manter o cronograma do projeto,
garantindo que as comunicações corretas sejam distribuídas e evitando quaisquer
dificuldades contínuas.
Prioridade Definição Autoridade Tempo para solução
Decisora
Impacto principal no projeto ou nas operações Vice- Dentro de 4 hours
Prioridade 1 comerciais. Se não for resolvido rapidamente, presidente ou
haverá um impacto adverso significativo na superior
receita ou no cronograma.
Impacto médio no projeto ou nas operações Em um dia útil
Prioridade 2 comerciais que pode resultar em algum impacto Patrocinador
adverso na receita ou no cronograma. do projeto
Pequeno impacto que pode causar algumas
Prioridade 3 pequenas dificuldades de programação com o Gerente do
Em dois dias úteis
projeto, mas nenhum impacto nas operações de Projeto
negócios ou receita.
Impacto insignificante no projeto, mas pode haver Gerente do O trabalho do Gerente
uma solução melhor. Projeto do Projeto continua e
Prioridade 4 todas as
recomendações são
enviadas por meio do
processo de controle de
mudança do projeto

11.8 - MATRIZ DE COMUNICAÇÕES

A tabela a seguir identifica os requisitos de comunicação em um Plano de
Gerenciamento de Comunicações.
 FGVIDT

Tipo de Objetivo da Meio Frequência Audiência Proprietário Entregas Formato

Comunicação Comunicação
Reunião de Apresentar a equipe Presencial Uma vez Patrocinador Gerente do Agenda Cópia
lançamento do do projeto e o do projeto Projeto eletrônica
projeto projeto. Revisar os Equipe do Atas de arquivada
objetivos do projeto Projeto Reunião no site do
e a abordagem de Acionistas projeto (ou
gerenciamento. nuvem)
Reuniões da Equipe Revisar o status do Presencial Semanal- Equipe do Gerente do Agenda Cópia
do Projeto projeto com a Vídeo- mente Projeto Projeto eletrônica
equipe. conferência Atas de arquivada
Telefone Reunião no site do
projeto (ou
Cronogram nuvem)
a do
projeto
Reuniões de Presencial Quando Equipe Líder técnico Agenda Cópia
Projeto Técnico Discutir e necessário Técnica do eletrônica
desenvolver Projeto Atas de arquivada
soluções de design Reunião no site do
técnico para o projeto (ou
projeto. nuvem)
Reuniões mensais Relatório sobre o Presencial Mensalmente Equipe do Gerente do Atualizaçõ Cópia
de status do projeto status do projeto Vídeo- Projeto Projeto es eletrônica
para a gerência. conferência arquivada
Telefone Cronogram no site do
a do projeto (ou
projeto nuvem)
Relatórios de status Relatar o status do Email Mensalmente Patrocinador Gerente do Relatório Cópia
do projeto projeto, incluindo do projeto Projeto do status eletrônica
atividades, Equipe do do projeto arquivada
progresso, custos e Projeto Cronogram no site do
problemas. Partes a do projeto (ou
interessadas projeto nuvem)
 FGVIDT

Unidade 12 - PLANO DE
GERENCIAMENTO DAS AQUISIÇÕES
Ao longo do ciclo de vida de um projeto, é provável que haja muitos pontos em que ele
se cruzará com os fornecedores. Este processo precisa ser gerenciado. Para gerenciar
esses relacionamentos e manter o fluxo desses bens e serviços em movimento sem
interrupção, é necessário um plano de gerenciamento de aquisições.
Planejar o gerenciamento das aquisições é o processo de documentar as decisões de
compras do projeto, especificando a abordagem e identificando fornecedores em potencial.
O ato de aquisição, sua gestão e planejamento estão profundamente enraizados na
metodologia de gestão de projetos.

12.1 ETAPAS DO PLANO DE GERENCIAMENTO

DE AQUISIÇÕES
O Gerente do Projeto é o membro da equipe do projeto responsável por supervisionar
o plano de gerenciamento de aquisições, mas não é um trabalho de uma pessoa. Uma vez
que as aquisições serão de todo o projeto, é importante que todos estejam envolvidos com
o processo. Todos devem ter algum envolvimento na aprovação e até no gerenciamento de
contratos.

12.1.1 - DEFINIR OS TERMOS

Definir os termos de aquisição significa listar o que é necessário adquirir em detalhes:
quantos, qual tamanho, por quanto tempo, etc.

Isto permitirá saber qual serviço será fornecido para o projeto e por que isso é
importante.

Em seguida, deve-se adicionar as datas de uso para cada uma dessas aquisições e
quem na equipe do projeto está autorizado a fazer essas compras.

12.1.2 - ESBOÇO DO TIPO DE ACORDO

O contrato é o meio como todos concordam com os termos de serviço. Existem
diferentes tipos de contratos. O tipo de acordo deve ser decidido e como será administrado.

12.1.3 - IDENTIFICAR E MITIGAR RISCOS

Os riscos são inerentes a todas as partes do processo de um projeto e, portanto,
permanecem latentes na aquisição até que se manifestem.

Deve-se identificar quais podem ser esses riscos relacionados às aquisições e listá-los.
Depois de efetuar a lista completa, cada item deve apresentar uma proposta de solução.
 FGVIDT

É interessante atribuir a um membro da equipe a tarefa de mitigar esses riscos, para

que eles tenham a responsabilidade de encerrá-los. Um modelo de registro de risco pode
ajudar.

12.1.4 - DEFINIR CUSTOS

Quais são os custos envolvidos com as aquisições do projeto? Uma vez que isso tenha
sido descoberto, é provável que uma solicitação de proposta seja emitida, com as
necessidades delineadas e solicitando propostas de fornecedores.
Essas solicitações devem ser minuciosas e contemplar tudo o que for necessário. Os
fornecedores retornarão com as cotações de produtos ou serviços.

12.1.5 - IDENTIFICAR AS RESTRIÇÕES

É importante tentar identificar quaisquer restrições do projeto antes de iniciá-lo, para
evitar ser surpreendido por limitações imprevistas durante a execução.

Uma vez que essa lista esteja completa, ela pode ser examinada ao longo das fases
do projeto.

As restrições relacionadas às aquisições incluem custo, escopo, recursos limitados e

especificações técnicas.

12.1.6 - OBTER A APROVAÇÃO DOS CONTRATOS

É relevante rever os lances e efetuar uma análise dos serviços e custos. Em seguida,
listar quem são os tomadores de decisão no grupo do projeto e encaminhar as propostas
para eles para revisão (uma matriz RACI pode ajudar a identificar os tomadores de decisão).

Este processo garante que todos os que precisam supervisionar a aprovação do

contrato estejam envolvidos e possam fornecer informações.

12.1.7 - CRIAR CRITÉRIOS DE DECISÃO

Mesmo que o fluxo de trabalho esteja delineado, será preciso ter um critério para decidir
com quais ofertas devem indicar celebrar o contrato. Cada pessoa que analisar as ofertas
deverá ter esses critérios em mãos paradecidir da melhor forma.

12.1.8 - CRIAR UM PLANO DE GERENCIAMENTO DE FORNECEDORES

Depois que os contratos forem assinados, o plano de gerenciamento de aquisições
segue para um plano de gerenciamento de fornecedores.
Os termos do contrato devem ser cumpridos. E, para garantir que isso aconteça, um
plano de gerenciamento envolvendo os fornecedores ajudará a garantir que os bens e
serviços sejam entregues conforme especificado e dentro do prazo.

É interesante adicionar métricas de desempenho para avaliar a qualidade do

atendimento de cada fornecedor, para registrar como foram as relações no próximo projeto
e saber se vale a pena contratar novamente aquele fornecedor.
 FGVIDT

12.2 - LICITAÇÕES E CONTRATOS

Depois de identificar a lista de quais recursos externos serão necessários, a equipe
pode começar o trabalho para adquiri-los. Isso é chamado de processo de licitação, onde os
fornecedores fazem propostas para as propostas.

Após receber as ofertas ou propostas dos fornecedores, eles devem ser estudados
para determinar qual é o mais adequado para o projeto.

Quando for firmado um acordo contratual com os fornecedores, esses contratos

deverão ser gerenciados como todos os outros aspectos do projeto.

É crucial para o bom andamentodo projeto que esses fornecedores estejam realizando
exatamente o que foi contratado para fazer, no prazo e dentro do orçamento alocado.
 FGVIDT

Unidade 13 - PLANO DE ENGAJAMENTO

DAS PARTES INTERESSADAS
Planejar o engajamento das partes interessadas é o processo de desenvolvimento de
abordagens para envolver as partes interessadas do projeto, com base em suas
necessidades, expectativas, interesses e potencial impacto ao projeto.

Todo projeto tem partes interessadas. No entanto, o número e o envolvimento das

partes interessadas variam muito entre os diferentes tipos de projetos.

Um pequeno projeto de desenvolvimento de software enxuto, por exemplo, pode ter

apenas algumas partes interessadas. Por outro lado, um megaprojeto, por exemplo
construção de infraestrutura, pode envolver um grande número de partes interessadas
individuais e grupos de partes interessadas.

Independentemente do tamanho do projeto, gerenciar o relacionamento de um projeto

com as partes interessadas é crucial para garantir o sucesso do projeto. Isso é
especialmente verdadeiro para partes interessadas influentes e interessadas.
Um Plano de Engajamento das Partes Interessadas é uma estratégia formal para se
comunicar com as partes interessadas do projeto para obter seu apoio ao projeto.
Ele especifica a frequência e o tipo de comunicação, mídia, as pessoas de contato e
os locais dos eventos de comunicação.
Ele deve ser criado no início do projeto e atualizado frequentemente conforme a
necessidade de comunicação das partes interessadas.

13.1 - PARTES DE UM PLANO DE

ENVOLVIMENTO DAS PARTES INTERESSADAS
Um bom plano de engajamento das partes interessadas contempla diversas etapas.

13.1.1 - LISTAR AS PARTES INTERESSADAS

A primeira etapa em qualquer plano de engajamento das partes interessadas é listar
as partes interessadas para evitar que uma parte interessada secundária não seja
comunicada de forma adequada.

As principais partes interessadas são:

Os executivos são partes interessadas da organização principal, incluindo o
patrocinador do projeto.
Os clientes que pagam pelo produto ou serviço (as entregas) que o projeto produz.
 FGVIDT

A equipe do projeto que produz esses produtos e serviços.

Os gerentes técnicos que fornecem consultoria especializada e recursos para o
projeto.
Os credores e investidores que financiam o projeto.

Os fornecedores que fornecem produtos e serviços externos.

Os governos que produzem regulamentos aos quais o projeto deve obedecer e emitem
autorizações e aprovações.
Os comitês e conselhos locais que aprovam as entregas do projeto.

Os sindicatos que negociam por melhores condições de trabalho e pagam a equipe

do projeto.

13.1.2 - CLASSIFICAR AS PARTES INTERESSADAS

Como uma etapa inicial na análise das partes interessadas, classificar as partes
interessadas em grupos definidos pode ajudar nas próximas etapas mais detalhadas.
As partes interessadas podem ser classificadas em apoiantes ou oponentes, de acordo
com o grau de poder, influência, impacto, interesse ou susceptibilidade. Por exemplo, um
investidor do projeto é um apoiador e uma ONG ambiental que se opõe é um oponente.

As expectativas das principais partes interessadas podem ser gerenciadas a partir da

identificação dos graus de poder, influência, impacto ou susceptibilidade.

Uma matriz de aplicação desses modelos de classificação sobre as expectativas das

partes interessadas pode ajudar a equipe do projeto a compreender e priorizar os esforços
para verificar se está atendendo às necessidades e desejos delas, se o que está sendo feito
contribui para entregar as expectativas esperadas e se o que estiver sendo feito
apresenta/induz à obtenção dos benefícios que serão gerados ao projeto aos interessados.
Modelos de classificação:

- Grau de Influência x Impacto;

- Grau de Interesse x Poder x Susceptibilidade;

- Grau de Influência x Interesse.

Existem duas variáveis principais que definem as partes interessadas e como elas
influenciam o projeto.

Poder (Influência) é a capacidade da parte interessada de alterar ou interromper o

projeto.

Cada parte interessada tem uma capacidade única de interromper e ou alterar o

projeto. Que habilidade é essa? De onde vem e como pode ser controlado? Às vezes, o
 FGVIDT

poder das partes interessadas sobre o projeto pode ser removida, mas isso tem um custo,
tanto financeiro, quanto na satisfação das partes interessadas (eles podem ficar muito
insatisfeitas e influenciar outras partes interessadas).
Interesse é a capacidade de envolvimento das partes interessadas no projeto. É o
tamanho da sobreposição entre as necessidades das partes interessadas e do projeto.
É aqui que a "aposta" da parte interessada é definida. Como seus interesses se
sobrepõem ao projeto? Quais são seus objetivos de negócios e como seu projeto interfere
neles? Por que essa parte interessada está interessada no projeto? Não pode haver
envolvimento significativo das partes interessadas sem entender os pontos de vista uns dos
outros.

Por esse motivo, a técnica de análise de partes interessadas mais comum é uma matriz
de poder (influência)-interesse.
Este gráfico pode parecer muito simples à primeira vista, mas fornece um volume de
informações sobre uma parte interessada e como gerenciá-la.

Alto Fornecedores
Diretores Patrocinadores
Órgãos do Governo

Grau de
Poder

Clientes
Colaboradores Equipe e Membros do
Baixo Projeto

Baixo Grau de Interesse Alto

Cada um dos quatro quadrantes onde cada parte interessada se encontra tem
diferentes características de gestão.
Aqueles com baixo poder e baixo interesse devem ser monitorados para garantir
que não sejam capazes de interromper ou alterar o projeto.
Aqueles com alto poder e baixo interesse devem ser mantidos satisfeitos para
garantir que uma parte interessada secundária não inviabilize o projeto.
 FGVIDT

Aqueles com baixo poder e alto interesse devem ser mantidos informados para
garantir que estejam do lado.

Aqueles com alto poder e alto interesse devem ser gerenciados ativamente, pois
têm uma grande influência no projeto.

Por exemplo, uma agência de aprovação regulatória do governo pode ter um poder
muito alto, mas um interesse muito baixo no projeto. Eles devem ser mantidos satisfeitos ou
podem recusar as licenças. Da mesma forma, um manifestante ambiental pode ter muito
baixo poder, mas alto interesse. Devem ser mantidos informados para não mobilizarem
resistências excessivas.
A matriz de poder-interesse contém simplesmente um ponto que mostra onde a parte
interessada se encontra no gráfico. Uma matriz de análise de partes interessadas mais
ampla pode expandir as definições de de onde vem esse poder, como o exercem e qual é
seu interesse no projeto.

13.1.3 - ABORDAGEM DE ENGAJAMENTO

A estratégia para engajar as partes interessadas deve ser descrita em detalhes. Os
tipos e frequência de comunicação, por exemplo, e-mails semanais, telefonemas mensais
ou reuniões presenciais semanais. O conteúdo dessas comunicações, por exemplo, uma
atualização semanal que contém o andamento do projeto, informações de design e planos
abertos.
INTERVENIENTES DESCRIÇÃO EXPECTATIVAS E NOME
INTERESSES
Patrocinadores Pessoas ou grupos Interesses Silvio Santos
que patrocinam o econômicos,
projeto cumprimento dos
prazos, do custo e
da qualidade.
Retorno sobre o
Investimento (ROI).
Diretores Pessoas que Interesses João da Silva
compõem a direção econômicos,
da empresa qualidade e número
de clientes.
Clientes Clientes que Qualidade, Rebeca Cristina
usufruirão das Infraestrutura e
entregas do projeto Tecnologia
Colaboradores Funcionários da Salários e Todos os
empresa benefícios colaboradores da
empresa
 FGVIDT

Membros da Integrantes da Salários e Gabriela

Equipe do Projeto equipe que benefícios e projeto Nascimento, Renê
desenvolve o bem-sucedido Xavier, Lara
projeto. Constante, Rose
Angélica
Órgãos do Entidades Obediência às Governo Estadual,
Governo responsáveis por normas e Governo Municipal
acompanhar e legislações e
fiscalizar a recolhimento de
legislação vigente. impostos.
Fornecedores Pessoas e Pagamento dos Empresas
empresas que foram contratos nos
contratadas para prazos.
oferecer serviços ao
projeto.

13.1.4 - APOIO DAS PARTES INTERESSADAS VERSUS RESISTÊNCIA

Na maioria dos projetos, as partes interessadas atuam em equipes diferentes. Elas têm
valores e interesses diferentes. Esses interesses conflitantes exigem que os gerentes de
projeto não apenas entendam as necessidades e os objetivos das partes interessadas, mas
também possuam fortes habilidades de resolução de conflitos, habilidades de negociação e
habilidades de comunicação.

As partes interessadas que apóiam o projeto não ocupam muito tempo do Gerente do
Projeto porque não atrapalham. Os gerentes de projeto gerenciam efetivamente as partes
interessadas que se opõem e não apóiam o projeto.
Existem cinco níveis de suporte em que cada parte interessada se enquadra:

Inconsciente
A parte interessada não tem conhecimento do projeto e de suas possíveis
consequências para ele.
Resistente

A parte interessada está ciente do projeto, mas se opõe a ele.

Neutro

A parte interessada não apóia nem se opõe ao projeto.

De apoio

A parte interessada é a favor do projeto e deseja que ele seja bem-sucedido.

Engajada

A parte interessada está ativamente engajada no sucesso do projeto e disposta a

prestar assistência à equipe de gerenciamento do projeto.
 FGVIDT

Esses níveis de suporte de cada parte interessada podem ser mapeados e

acompanhados por meio de uma matriz de avaliação do engajamento das partes
interessadas.
Esta matriz mostra onde cada parte interessada está em termos de suporte ao projeto,
versus onde a equipe de gerenciamento de projeto gostaria que eles estivessem.

INTERVENIENTES Inconsciente Resistente Neutro De apoio Engajada

Parte Interessada A D
Parte Interessada A D
Parte Interessada A D
Parte Interessada A D

A letra “A” é usada para denotar onde a parte interessada está atualmente, e a letra
“D” é usada para denotar onde seria o local desejado.
 FGVIDT

Unidade 14 – MONITORAR E
CONTROLAR O TRABALHO DO PROJETO
O monitoramento e controle do gerenciamento de projetos começam assim que um
projeto começa.

Monitorar e controlar o trabalho do projeto é o processo de acompanhar, revisar e

regular o progresso para cumprir os objetivos de desempenho e envolve as tarefas de
gestão, como rastrear, revisar e relatar o andamento de um projeto.
Além disso, este processo está principalmente preocupado com:

- Medir o desempenho planejado versus o desempenho real.

- Avaliar o desempenho do projeto continuamente para identificar quaisquer ações
preventivas ou corretivas necessárias.
- Manter informações precisas e oportunas com base nas saídas do projeto e na
documentação associada.
- Fornecer informações para acompanhamento dos relatórios de status, medição de
progresso e previsões.
- Avaliar se os planos de resposta aos riscos apropriados estão sendo executados.

- Manter uma base de informações precisa e oportuna sobre as saídas do projeto e sua
documentação associada até a conclusão do projeto.

- Fornecer informações sobre as previsões para atualizar o custo atual e as informações

do cronograma atual.

- Monitorar a implementação das mudanças aprovadas à medida que elas ocorrerem

ou adequações ao cronograma.

- Manter as partes interessadas atualizadas sobre o progresso do projeto e o

desempenho da equipe por meio de relatórios e documentação.
- Avaliar regularmente o progresso relacionado ao escopo, as metas de benchmark, o
cronograma e orçamento.
Todas essas ações ajudam a garantir que não haja surpresas desagradáveis à medida
que o projeto se desenvolve.

14.1 - EXECUTAR O CONTROLE INTEGRADO DE

MUDANÇAS
 FGVIDT

Mesmo os projetos bem planejados exigirão mudanças de tempos em tempos.

Quanto maior o projeto, mais mudanças geralmente irão ocorrer.

Acompanhar as mudanças à luz do cronograma e das considerações

orçamentárias é uma tarefa importante que não deve ser relegada.

A documentação relacionada aos pedidos de mudança e de custos é uma

parte essencial do trabalho de qualquer Gerente do Projeto.

O custo das mudanças é menor no começo do projeto, assim como a interação com as
partes interessadas é maior.

A implementação de mudanças será muito mais cara se for implementada no final do

projeto.

14.2 - VERIFICAR ESCOPO

Na medida em que o projeto avançar em cada fase, é importante verificar e
assegurar se a documentação estpa relacionada às partes concluídas do projeto.

Verificar os outros grupos de processo para ter certeza de que os objetivos

foram atingidos, refletindo as mudanças e acompanhar o projeto em direção à
conclusão.

14.3 - CONTROLAR O ESCOPO

Se houver ajustes no orçamento, no cronograma ou no produto final desejado,
é importante verificar novamente a documentação relacionada ao escopo e mitigar
quaisquer desafios não resolvidos.

Também deve-se manter uma comunicação eficaz com as partes interessadas

para atualizar a todos os envolvidos no sucesso do projeto.

14.4 - CONTROLAR O CRONOGRAMA

Todo projeto tem uma linha de base de cronograma.
Conforme o projeto avança, ajustes são frequentemente necessários para lidar
com circunstâncias imprevistas.
O monitoramento adequado do projeto pode diminuir as chances de problemas
de cronograma se tornarem grandes contratempos.
 FGVIDT

14.5 - CONTROLAR OS CUSTOS

Muitos fatores podem afetar o custo ao longo do cronograma do projeto. Manter
o controle de quaisquer alterações no orçamento é importante para que a
comunicação sobre o controle de custos seja clara e precisa.

14.6 - REALIZAR O CONTROLE DE

QUALIDADE
Quantificar e relatar os problemas de controle de qualidade são necessários -
e contínuos - para apoiar a precisão e a capacidade de resposta do projeto.
Com base nas descobertas do monitoramento podem ser feitos ajustes de
processos.

14.7 - RELATÓRIO DE DESEMPENHO

Coletar e relatar os dados de desempenho é importante para acompanhar a
previsão adequada em relação ao cronograma e às fases e manter as partes
interessadas cientes do progresso do projeto.

14.8 - MONITORAR E CONTROLAR OS

RISCOS
Rastrear e responder aos riscos documentados e avaliar as respostas aos
riscos faz parte da garantia de que o projeto avance com eficácia em cada fase do
cronograma.

14.9 - ADMINISTRAR AS AQUISIÇÕES

As necessidades da equipe mudarão ao longo do projeto, itens adicionais
podem ser necessários, enquanto outros itens e serviços nem tanto.

Manter o controle de todos os documentos que registram quaisquer alterações

nos contratos é vital para entregar o projeto dentro do orçamento, ou o mais próximo
possível.
 FGVIDT

Unidade 15 - REALIZAR O CONTROLE

INTEGRADO DE MUDANÇAS
É o processo responsável pelo controle dos fatores geradores de mudança no projeto,
de forma que qualquer mudança seja realizada para melhorar o projeto.
Realizar o controle integrado de mudanças é um processo importante executado na
área de conhecimento do gerenciamento de integração e no grupo de processos de
monitoramento e controle.

O motivo pelo qual é chamado de “integrado” é que este é o processo em que o impacto
de qualquer mudança é avaliado em relação ao projeto. Uma coisa importante a notar é que,
se ocorrer uma mudança em uma parte do projeto, ela precisa ser avaliada em todo o projeto.
Em um projeto, sempre haverá solicitações de mudança. Essas mudanças serão
avaliadas pelo Conselho de Controle de Mudanças. Posteriormente, se as solicitações de
mudança forem aprovadas, elas serão implementadas.

As mudanças em um projeto são aceitas, rejeitadas ou tratadas no processo de

controle Realizar Mudanças Integradas.

Desde o envio de uma solicitação de mudança até sua implementação e encerramento,

o processo de controle integrado de mudanças garante o gerenciamento de mudanças bem-
sucedido em um projeto.
Um exemplo:

Vejamos um exemplo para realizar o processo de controle integrado de

mudanças. Uma mudança em uma das restrições do projeto deve ser avaliada
quanto aos impactos em todas as outras restrições.
Vamos considerar que você está gerenciando um projeto de software. E
vamos supor que o banco de dados do projeto armazene os membros como a
identificação da conta (ID), nome e sobrenome.

Se uma solicitação de alteração solicitar a alteração dos pedidos de nome e

sobrenome no banco de dados, isso pode ser uma alteração muito pequena da
perspectiva do trabalho do banco de dados. Mas se houver muitas outras partes no
software que dependem dessa ordem de nome e sobrenome, elas serão afetadas,
portanto, podem ser necessárias alterações nessas partes também.
O processo de controle integrado de mudanças visa avaliar os impactos de
uma mudança de ponta a ponta.
 FGVIDT

15.1 - IMPLEMENTAÇÃO DE UM CONTROLE

INTEGRADO DE MUDANÇAS
Para avaliar os impactos de uma mudança, é necessário ter um plano de
gerenciamento de projeto realista e um escopo do projeto adequado.
Porque apenas um plano de gerenciamento de projeto completo e escopo podem incluir
as interdependências de atividades ou componentes de um projeto. Com a ajuda desses
planos completos e escopo, o impacto de uma mudança pode ser avaliado adequadamente
em outras partes do projeto, no controle Realizar Mudanças Integradas.

15.1.1 - PREVENIR A CAUSA-RAIZ DA NECESSIDADE DE MUDANÇAS

Geralmente, o Gerente do Projeto deve prevenir a causa raiz da necessidade de
mudanças, porque mudanças frequentes causam atualizações e revisões frequentes no
plano e isso requer retrabalho.
As metas e datas do projeto geralmente mudam com a implementação de uma
solicitação de mudança no projeto. Se os objetivos do projeto e as datas-alvo mudam com
muita frequência, isso também pode causar desmotivação na equipe do projeto.
Espera-se que as empresas tenham procedimentos estabelecidos neste processo para
gerenciar e controlar as mudanças. A avaliação de uma mudança e implementação em um
projeto é um procedimento complexo.

Avaliar uma mudança, analisar os impactos e as etapas para aprovar uma mudança,
ou implementar uma mudança aprovada devem ser documentados por processos, políticas
e procedimentos.
Se houver muitas mudanças em um projeto, será impossível coordenar o trabalho.

Muitas solicitações de mudança significam que o planejamento não foi feito

corretamente ou os requisitos não puderam ser reunidos e tratados de forma
adequada.
Isso ocorre porque as solicitações de mudança vêm dos clientes ou se há uma variação
no projeto. Se houver muitas solicitações de mudança em um projeto, a avaliação e o
planejamento dos requisitos devem ser examinados.

15.1.2 - OBTER OS REQUISITOS FINAIS O MAIS RÁPIDO POSSÍVEL

Obter os requisitos finais o mais rápido possível é um fator muito crítico para o sucesso
de um projeto, porque os requisitos são as bases do escopo do projeto. E uma vez que o
escopo do projeto é determinado, o processo de planejamento do projeto é iniciado.

Portanto, a coleta de requisitos incompleta ou inadequada causará um planejamento

incompleto e fraco, respectivamente. E o resultado serão várias solicitações de mudança
durante a execução do projeto.
 FGVIDT

15.1.3 - IDENTIFICAR CORRETAMENTE OS RISCOS DO PROJETO

Os riscos são as principais causas das variações em um projeto. Cada risco pode ser
identificado durante o processo de planejamento e uma estratégia de resposta para cada
risco deve ser abordada.

Dessa forma, uma vez que um risco ocorra, a forma de acomodar os impactos dos
riscos estará pronta e isso irá reduzir o nível de variações em um projeto.

15.1.4 - PLANEJAR RESERVAS ADICIONAIS DE TEMPO E CUSTOS

Com muita frequência, os resultados reais de tempo e custos não são os mesmos
planejados. Por isso, planejar reservas adicionais de tempo e custos no orçamento, e no
cronograma, pode evitar, em caso dos riscos existirem, que eles causem custos adicionais
e atrasos nos projetos.
Portanto, tão logo o planejamento do projeto esteja concluído, o Gerente do Projeto
também deve planejar reservas de tempo e custo para os impactos dos riscos.
Um exemplo:

Se determinado projeto tem a duração prevista de 1 ano e possui um orçamento de R$

1 milhão de reais, a reserva de tempo para isso pode ser de 2 meses adicionais e a reserva
de orçamento pode ser de R$ 100 mil reais.
Essas reservas de custo e tempo devem ser incluídas no plano final do projeto.

15.2 - PROCESSOS PARA REALIZAR O

CONTROLE INTEGRADO DE MUDANÇAS
Ao gerenciar, coordenar e implementar mudanças, esses quatro processos
devem ser seguidos para concluir uma mudança com sucesso.

15.2.1 - SOLICITAÇÕES DE MUDANÇAS

O Gerente do Projeto deve ter um processo e modelos em vigor para a criação de
solicitações de mudança. O envio de uma solicitação de mudança pode exigir que um
determinado conjunto de informações seja fornecido.
Por exemplo:

- nome da pessoa que fez solicitação de mudança

- motivo da mudança

- impactos da mudança
- histórico

- fluxo de aprovação, etc.

Essas informações devem ajudar a um melhor desempenho do processo de controle
 FGVIDT

integrado de mudanças, pois serão necessárias para cada solicitação de mudança.

A existência de um modelo de solicitação de mudanças facilitará o envio e o andamento
das alterações em um projeto.

15.2.2 - APROVAÇÃO DE MUDANÇAS

O Gerente do Projeto deve ter certeza de ter funções e responsabilidades claras para
a aprovação de mudanças no projeto.

As mudanças devem ser avaliadas pelo Conselho de Controle de Mudanças, mas

pode haver diferentes níveis de aprovação.

Em cada nível, a aprovação de diferentes partes interessadas pode ser necessária para
executar o processo de controle integrado de mudanças.

Por exemplo, a análise de primeiro nível e a aprovação podem ser fornecidas pelos
engenheiros, a aprovação de segundo nível pode ser dada pelos gerentes seniores, a
aprovação de terceiro e a última aprovação pode ser exigida do patrocinador do projeto.
Esses responsáveis devem ser esclarecidos quanto às autoriozações para gerenciar
as alterações e efetuar as mudanças sem problemas em um projeto.

15.2.3 - AVALIAR A NECESSIDADE DO PROJETO OU DO NEGÓCIO

Se houver um significativo e excessivo número de solicitação de mudanças, o projeto
ou o negócio devem ser revistos.

Muitas solicitações de mudança ocorrerão se a análise de requisitos e o plano de

gerenciamento de requisitos ou o planejamento do projeto não tiverem sido feitos
corretamente.
A necessidade do negócio é o que impulsiona a condução e a existência do projeto.

Caso haja muitas solicitações de mudança em um projeto, a necessidade do negócio

que causou o início do projeto deve ser reavaliada.

Após a avaliação da necessidade do negócio, pode-se considerar encerrar um projeto

que tenha alterações excessivas e iniciar um novo com um conjunto mais completo de
requisitos.
Muitas mudanças em um projeto farão com que ele perca o controle, desmotivação dos
membros da equipe devido à mudança frequente de objetivos e problemas na medição de
desempenho.

Se houver muitas solicitações de mudança em um projeto, encerrar o projeto atual e

reiniciar um novo projeto que terá requisitos concretos e completos será mais razoável de
acordo com os princípios do Controle Integrado de Mudanças.
 FGVIDT

15.2.4 - INCLUIR SOMENTE AS MUDANÇAS APROVADAS

O Gerente do Projeto deve permitir que apenas as mudanças aprovadas sejam
adicionadas às linhas de base do projeto.
Pode haver várias solicitações de mudança em um projeto, mas após a avaliação do
Conselho de Controle de Mudanças, muitas delas podem ser rejeitadas.
Apenas as mudanças aprovadas devem ser implementadas em um projeto. Além
disso, apenas as mudanças aprovadas devem ser refletidas nos planos do projeto,
documentos do projeto e linhas de base do projeto.

Vimos o processo de execução do controle integrado de mudanças em detalhes. Em

suma, Realizar o Processo de Controle Integrado de Mudanças visa evitar o fracasso do
projeto devido às solicitações de mudança mal gerenciadas.
Se houver um forte processo de execução do controle integrado de mudanças no
projeto, este não será afetado pelas variações ou mudanças durante o seu ciclo de vida.
 FGVIDT

UNIDADE 16 - ENCERRAR O PROJETO

OU FASE
O encerramento do projeto é a última fase do ciclo de vida do projeto e é tão
importante quanto os outros processos, pois se um projeto for encerrado de forma adequada,
os conhecimentos obtidos a partir desse projeto, em particular, serão utilizados nos projetos
futuros da organização.
Esta fase envolve o fechamento de seus projetos e a apresentação de relatórios sobre
o nível de sucesso ao proprietário do projeto.

16.1 - FLUXO DE ENTREGAS

O Gerente do Projeto e sua equipe produziram entregas de acordo com os requisitos,
a equipe de teste para as validou, corrigiu todos os problemas encontrados e solicitações de
mudança levantadas, revalidou as entregas e, finalmente, pediu ao cliente para verificá-las.
Não se pode fechar um projeto ou fase até que o cliente tenha aprovado formalmente
as entregas. Um projeto só pode ser fechado se o cliente aprovar o produto final do projeto.

16.2 - VERIFICAÇÃO DE DOCUMENTOS

Nessa atividade o Gerente do Projeto e sua equipe examinam todos os documentos do
projeto, certificam-se de que não há itens em aberto, verificam se todos os itens de trabalho
acordados foram entregues e assinados oficialmente e todos os critérios de saída foram
atendidos e as obrigações foram cumpridas.

A documentação é entregue para as empresas.

16.3 - DEMAIS RECURSOS

Após encerrar a entrega de documentos aos clientes o Gerente do Projeto pode liberar
pessoal e equipamentos, cancelar contratos com os fornecedores e informando as partes
interessadas sobre o fechamento.

16.4 RELATÓRIO DE LIÇÕES APRENDIDAS

Ao término do projeto, o Gerente de Projetos registrará, em um documento, os acertos
e erros identificados/cometidos para que a organização tenha, em projetos futuros, a
possibilidade de utilizar os recursos ou lições que deram certo e evitar repetir as falhas
cometidas.
O relatório pode apresentar, sucintamente:
- os objetivos do projeto;

- a avaliação do que foi Planejado versus o que foi efetivamente Realizado;

 FGVIDT

- a avaliação se os objetivos foram atingidos;

- a avaliação se o projeto foi entregue dentro do prazo e dentro dos custos (orçamento);

- a avaliação se o projeto atendeu ao escopo;

- os pontos fortes e os pontos fracos identificados; e

- sugestões para projetos futuros que tenham similaridade.

16.5 - FECHAMENTO
A primeira etapa na implementação de um projeto ou fase de encerramento é criar o
Relatório de Encerramento do Projeto, que será então aprovado ou rejeitado pelo
patrocinador. O relatório determinará se realmente há necessidade de fechar o projeto.
Portanto, uma aprovação oficial do cliente deve ser obtida neste processo. Pode ser
uma assinatura, uma aprovação por escrito, um e-mail informando a aceitação, etc. Assim
que a aprovação for obtida, os documentos do projeto são coletados, arquivados e o projeto
finalizado.
 FGVIDT

BIBLIOGRAFIA BÁSICA
ANGELO, Aldacir da Silva PRINCE2: o método de Gerenciamento de Projetos. Rio de
Janeiro: Brasport, 2016

BAKER, R., CLEMENTS, J., GIDO, J. Gestão de projetos. 7ª Ed. São Paulo, SP : Cengage,
2018. 472 p.

CRUZ, Fábio. Scrum e Guia PMBOK unidos no Gerenciamento de Projetos. Rio de

Janeiro: Brasport, 2013

MASSARI, Vitor L. Gerenciamento Ágil de Projetos: uma visão preparatória para a

certificação ágil do PMI (PMI-ACP). Rio de Janeiro: Brasport, 2014

PAES, Evandro Silva; VILGA, Vaine Fermozeli. Gestão de Projetos. Londrina: Editora e
Distribuidora Educacional S/A. 2016.

PMI. Guia do Conhecimento em Gerenciamento de Projetos. Guia PMBOK 6ª Edição.

EUA: Project Management Institute, 2017.
SILVA, Edson. Scrum e TFS: Uma abordagem prática. Usando o Team Foudantion
Server com Métodos Ágeis. Rio de Janeiro: Brasport, 2017
SOTILE, Mauro Afonso [et al.] Gerenciamento do Escopo em Projetos. 2ª Edição - Rio
deJaneiro: Editora FGV, 2010.
VALLE, André Bittencourt, PEREIRA, Carlos Alberto, SOARES, José, FINOCCHIO, Lincoln
de Souza Firmino. Fundamentos do Gerenciamento de Projetos. 2ª Edição - Rio
deJaneiro: Editora FGV, 2010.

VARGAS, Ricardo V. Gerenciamento de Projetos: Estabelecendo Diferenciais

Competitivos. 9ª Edição. Rio de Janeiro: Brasport, 2018

_______ Manual Prático do Plano de Projeto: Utilizando o PMBOK Guide. 6ª Edição. Rio
de Janeiro: Brasport, 2018

VERAS, Manoel. Gerenciamento de Projetos. Project Model Canvas (PMC). Rio de

Janeiro: Brasport, 2014
 FGVIDT

BIBLIOGRAFIA COMPLEMENTAR
CARVALHO, Fábio Câmara Araujo. Gestão de Projetos. São Paulo: Pearson Education do
Brasil, 2012.

___. Gestão de Projetos. São Paulo: Pearson Education do Brasil, 2015.

GIACOMONI, James (Org), PAGNASSUT, José Luiz (Org). Planejamento e Orçamento
Governamental. Brasília: ENAP,2006.
NYEGRAY, João Alfredo Lopes. Projetos Internacionais: ESTRATÉGIAS PARA A
EXPANSÃO EMPRESARIAL. Curitiba: Editora INTERSABERES, 2016
POSSI, Marcus (Coord) Gerenciamento de Projetos guia do profissional: volume 3:
fundamentos técnicos. Rio de Janeiro: Brasport, 2006
RODRIGUES, Eli. 21 Erros Clássicos da Gestão de Projetos. Rio de Janeiro: Brasport,
2014
VARGAS, Ricardo V, ROCHA, Allan C, Microsoft Project 2016: Standard, Professional &
Pro for Office 365 eBook Kindle. 1ª Edição. Rio de Janeiro: Brasport, 2017