Projeto Gestão de Portfólio PDPJ Livro 2 de 3 em 18-03-21

Centro de Formação e
Aperfeiçoamento de
Servidores do Poder Judiciário
GESTÃO DE PORTFÓLIO, PROGRAMAS E PROJETOS

DE IMPLANTAÇÕES DA PLATAFORMA DIGITAL
DO PODER JUDICIÁRIO BRASILEIRO – PDPJ-BR
FUNDAMENTOS, PLANEJAMENTO E IMPLEMENTAÇÕES DE PROJETOS
2. CONTEÚDO DO CURSO
CONTEUDISTA: PROF. FLÁVIO FEITOSA COSTA MSC. PMP
CONSELHO NACIONAL DE JUSTIÇA
Presidente
Ministro Luiz Fux
Corregedora Nacional de Justiça

Maria Thereza Rocha de Assis Moura
Conselheiros
Ministro Emmanoel Pereira
Luiz Fernando Tomasi Keppen
Mário Augusto Figueiredo de Lacerda Guerreiro
Rubens de Mendonça Canuto Neto
Candice Lavocat Galvão Jobim
Tânia Regina Silva Reckziegel
Flávia Moreira Guimarães Pessoa
Ivana Farina Navarrete Pena
André Luis Guimarães Godinho
Marcos Vinícius Jardim Rodrigues
Maria Tereza Uille Gomes
Henrique de Almeida Ávila
Secretário-Geral
Valter Shuenquener de Araujo
Secretário Especial de Programas,

Pesquisas e Gestão Estratégica
Marcus Livio Gomes
Diretor-Geral
Johaness Eck
Organização
Centro de Formação e Aperfeiçoamento
de Servidores do Poder Judiciário
EXPEDIENTE
SECRETARIA DE COMUNICAÇÃO SOCIAL
Secretário de Comunicação Social

Juliana Neiva
Diagramação
Eduardo Trindade
Revisão
Carmem Menezes
2021
CONSELHO NACIONAL DE JUSTIÇA
SAF SUL Quadra 2 Lotes 5/6 - CEP: 70070-600
Endereço eletrônico: www.cnj.jus.br
Aperfeiçoamento de
GESTÃO DE PORTFÓLIO, PROGRAMAS E PROJETOS

DE IMPLANTAÇÕES DA PLATAFORMA DIGITAL
DO PODER JUDICIÁRIO BRASILEIRO – PDPJ-BR
FUNDAMENTOS, PLANEJAMENTO E IMPLEMENTAÇÕES DE PROJETOS
2. CONTEÚDO DO CURSO
CONTEUDISTA: PROF. FLÁVIO FEITOSA COSTA MSC. PMP
Brasília – 2021
Este documento contém o conteúdo do curso. Iniciando pela intro-
dução e seguindo com os conteúdos de cada Unidade de Interação
e Aprendizagem (UIA).
A introdução contém uma breve explanação do curso, introduzindo e contextualizando
o aluno sobre os principais assuntos abordados, bem como as competências que serão
desenvolvidas nas unidades de ensino.
Cada Unidade de Interação e Aprendizagem (UIA) contém:
• Nome das UIAs, e seu conteúdo escrito, que estão de acordo com a ementa do curso.
• Em cada UIA, são apresentados, links relacionados ao conteúdo apresentado

naquela UIA: para cada link há uma breve descrição do que está sendo abordado;
tais descrições e links estão destacados em verde.
• As citações autor-data utilizadas ao longo do conteúdo, estão destacados em azul.
• Os termos contidos no glossário, estão destacados em amarelo.
• E os links para as leituras complementares, estão destacados em rosa.

Sumário
INTRODUÇÃO DO CURSO 9
UIA 1 | CONTEXTO DOS PROCESSOS, GERENCIAMENTO DE ESCOPO E DA INTEGRAÇÃO DOS PROJETOS 13
UIA 2 | GERENCIAMENTO DO TEMPO E DO CUSTO DOS PROJETOS 41
UIA 3 | GERENCIAMENTO DA QUALIDADE, COMUNICAÇÃO E RECURSOS HUMANOS DOS PROJETOS 57
UIA 4 | GERENCIAMENTO DAS AQUISIÇÕES E RISCOS DOS PROJETOS 73
UIA 5 | EXECUÇÃO, MONITORAMENTO E CONTROLE DE PROJETOS PDPJ-Br 91
UIA 6 | ENCERRAMENTO DE PROJETOS PJe 111
UIA 7 | GERENCIAMENTO DE PROGRAMAS E PORTFÓLIO PDPJ-Br 123
UIA 8 | ESCRITÓRIOS DE GERENCIAMENTO DE PROJETO (PMO) 133
ANEXOS 149
Introdução do Curso
O curso está dividido em oito UIAs, que compreendem primeiramente uma contextualização dos processos
do gerenciamento de projetos, e posteriormente, o seu aprofundamento, tendo em vista as práticas de pla-
nejamento, execução, monitoramento e encerramento dos projetos, tendo como cenário de estudo de caso a
Plataforma Digital do Poder Judiciário Brasileiro – PDPJ-Br, instituída pela Resolução CNJ nº 335 de 2020. Ou seja,
abordando todo o ciclo de vida de um projeto da PDPJ.
A Plataforma Digital do Poder Judiciário Brasileiro – PDPJ-Br tem como principal escopo incentivar o desenvol-
vimento colaborativo entre os tribunais, preservando os sistemas públicos em produção, mas consolidando
pragmaticamente a política para a gestão e expansão do Processo Judicial Eletrônico – PJe.
O principal objetivo é modernizar a plataforma do Processo Judicial Eletrônico e transformá-la em um sistema

multisserviço que permita aos tribunais fazer adequações conforme suas necessidades e que garanta, ao mesmo
tempo, a unificação do trâmite processual no país.
A plataforma permitirá o oferecimento de multisserviços e com possibilidade de ser adaptada conforme necessi-
dades e demandas específicas, sem dúvida uma das principais demandas dos Tribunais.
Desta forma, será reconhecido que, além do PJe, há outros sistemas públicos e gratuitos, atualmente em produ-
ção em vários tribunais; e que os custos de migração para uma plataforma única não seriam compensatórios.
Opta-se, portanto, por autorizar sua disponibilização na PDPJ, com o aval do CNJ, mas com o condicionante de que
os futuros desenvolvimentos sejam realizados de forma colaborativa, impedindo a duplicação de iniciativas para
atender às mesmas demandas, mediante tecnologia e metodologia fixadas pelo CNJ.
Ao incentivar e fomentar o desenvolvimento colaborativo, os sistemas públicos hoje existentes, em suas versões
originárias, serão tratados todos como “legados” e serão progressivamente “desidratados” ou “modularizados” para
a criação de “micros serviços” de forma que em médio prazo naturalmente convirjam para uma mesma solução.
O funcionamento deste modelo depende fundamentalmente de dois fatores: agregação dos tribunais e gover-
nança. E aqui encontramos outro norte da normatização proposta.
Pretende-se com isso consolidar no Judiciário brasileiro a política para a gestão de processo judicial eletrônico e
integrando todos os tribunais do país e finalizando de uma vez por todas com os conflitos entre qual é o melhor
sistema, mas, mantendo o sistema PJe como sistema de Processo Eletrônico patrocinado pelo CNJ e principal motor
da nova política.
Assim, essa nova política busca o alinhamento de todos os Tribunais do Brasil com a política de sistema de pro-
cessos eletrônicos públicos e não onerosos. Fortalecendo a interoperabilidade entre sistemas diversos e criando o
ambiente para que os tribunais migrem voluntariamente para um sistema único em médio e longo prazo.
Destaca-se como pontos principais:
1) definição que não se deve permitir, em momento a ser futuramente definido, contratação de siste-
mas privados, mantendo-se a tradição da não dependência tecnológica, sedimentada de longa data
neste Conselho;
2) reconhecer que os sistemas públicos, ou seja, desenvolvidos internamente pelos tribunais, são todos
válidos e não estão em total desconformidade à política pública de consolidação da Plataforma Digital
do Poder Judiciário, com a premissa que os novos desenvolvimentos serão realizados no modelo da
nova Plataforma;
3) a plataforma tecnológica de processo judicial foi definida como uma política pública;
4) a possibilidade de utilização de nuvem inclusive provida por pessoa jurídica de direito privado, mesmo na
modalidade de integrador de nuvem (broker).
Em se tratando do conteúdo do curso. Na primeira UIA, trataremos do ciclo de vida dos projetos e principalmente
da visão geral dos seus processos, dos seus grupos e as interações entre eles. Promovendo uma visão global
desde a iniciação até o encerramento.
Ainda na primeira UIA, já abordaremos os processos de Gerenciamento de Escopo e da Integração, como a coleta
de requisitos, definição de escopo, verificação e controle do escopo. Será destacado o uso de Estrutura Analítica de
Projeto (WBS), dada a sua importância. Além das técnicas de planejamento de escopo, abordaremos os principais
instrumentos de integração, tal como o termo de abertura do projeto e o plano geral, deixando clara a interlocução
entre os planos individuais que compõe um planejamento de projeto, além do seu processo de encerramento.
Na segunda UIA, continuaremos a explorar os processos de gerenciamento, mas, com foco no Gerenciamento do
Tempo e no Gerenciamento dos Custos. Serão vistas técnicas e ferramentas para a definição, estimativa (PERT,
CPM e Delphi), sequenciamento, desenvolvimento e controle de cronogramas, além de métodos de estimativas,
compressão de duração e análise de caminho crítico e corrente crítica.
No Gerenciamento dos Custos serão apresentados os processos de estimativa de custos e orçamentação de custos.
Já na terceira UIA, faremos uma exploração de mais processo de planejamento, abordando o Gerenciamento da
Comunicação, da Qualidade e dos Recursos Humanos.
Na quarta UIA, trataremos dos últimos processos vinculados ao Gerenciamento de Aquisições, e o Gerencia-
mento de Riscos, que propositalmente fica por último, por ter como pré-requisitos de análise, a realização dos
processos anteriormente abordados, para que seja feita a identificação dos riscos e como planejar resposta a
eles, evitando-os ou enfrentando-os.
GESTÃO DE PORTFÓLIO, PROGRAMAS E PROJETOS DE IMPLANTAÇÕES DA PLATAFORMA DIGITAL DO PODER JUDICIÁRIO BRASILEIRO – PDPJ-BR
10 FUNDAMENTOS, PLANEJAMENTO E IMPLEMENTAÇÕES DE PROJETOS
Na quinta UIA, faremos uma abordagem conceitual da Gestão do Valor Agregado (Earned Value Management
– EVM); descrição de seus elementos básicos e suas correlações; Análise e previsão do desempenho do EVM;
guia para o uso das melhores práticas do uso do EVM.
Na sexta UIA, abordaremos o último grupo de processos do ciclo de vida dos projetos, que é o de encerramento.
Já na sétima UIA, continuaremos a explorar a visão macro da organização, Planejamento Estratégico, passando
pela Gestão do Portfólio, Gerenciamento do Programa, e de Múltiplos Projetos; Framework de Gerenciamento de
Programas; Ciclo de Vida de um Programa; Processos de Gerenciamento de Programas; Relacionando Projetos,
Programas e Portfólio Gerenciamento de Benefícios; Monitoramento e controle de Portfólio; Análise e revisão
periódica do Portfólio.
E por último, na oitava UIA, faremos a abordagem conceitual com diversas definições e sua consolidação do PMO;
histórico da evolução dos PMO; tipos e suas funções; comparativo entre os níveis de maturidade em Gerência
de Projeto e os tipos de PMO; papéis e responsabilidades em um PMO; fatores que motivam, que podem gerar
fracasso e sucesso para implementação de um PMO; como implementar um PMO e uma proposta de medição
de seu sucesso; o perfil dos PMOs nas organizações brasileiras. 
2. CONTEÚDO DO CURSO 11
UIA 1 | CONTEXTO DOS PROCESSOS,
GERENCIAMENTO DE ESCOPO E
DA INTEGRAÇÃO DOS PROJETOS
Contexto da PDPJ-Br
A PDPJ-Br faz parte de um programa denominado Justiça 4.0, que tem por objetivo aprimorar as soluções
tecnológicas utilizadas pelo Poder Judiciário e, assim, qualificar o atendimento prestado à sociedade, dando
respostas judiciais tempestivas e efetivas.
O Justiça 4.0 compreende um pacote de projetos, como a plataforma Sinapses de desenvolvimento e cooperação
em inteligência artificial e a Plataforma Digital do Poder Judiciário. E ainda tem ações voltadas à higienização e
qualificação das bases de dados, fortalecendo a Base Nacional de Dados do Poder Judiciário (DataJud).
A realidade atual do ecossistema de processo eletrônico no Poder Judiciário Brasileiro é baseada em sistemas de
tramitação processual isolados – ilhas de soluções.
Neste contexto, a PDPJ é:
• Política pública para governança do Processo Judicial Eletrônico;
• Mantém o Processo Judicial Eletrônico como sistema prioritário do CNJ;
• Repositório central (marketplace) para uso de todos os sistemas judiciais eletrônicos do Poder Judiciário.
E tem por objetivos:

• Conversão dos sistemas processuais para “legados”
• “Desidratação” dos monólitos
• Desenvolvimento de micros serviços
• Hospedagem centralizada
• Desenvolvimento colaborativo
• Governança pelo CNJ
• Atualizações automáticas
• Maior estabilidade e tolerância a falhas
As suas premissas são:
Seus requisitos de sistemas são:
I - padrões de desenvolvimento, documentação e operação de software;
II - padrões de comunicação e interoperabilidade entre sistemas e aplicações;
III - arquitetura de desenvolvimento e de infraestrutura;
IV - padrão de autenticação;
V - permissão para o desenvolvimento compartilhado;
VI - definição dos padrões mínimos de interface, com aplicação dos conceitos de usabilidade, acessibilidade
e experiência do usuário (user experience);
VII - disciplina da plataforma única para os modelos de I.A;
VIII - delimitação dos critérios e serviços para computação em nuvem;
IX - instituição do desenvolvimento.
Seus requisitos de dados e documentos:
I - padrões das tabelas unificadas;
II - possibilidade de bases centralizadas ou descentralizadas, sempre uniformes;
III - padrões de dados mínimos para o atendimento da Lei nº 13.709/2018;
IV - padrões de documentos digitais;
V - padrões de assinaturas digitais.
A gestão da PDPJ é baseada em:
Já em relação aos sistemas atuais, teremos:
• PJe será mantido e aprimorado capitaneando a nova Plataforma;
• Centralização de bases de dados, documentos e aplicações por meio de “nuvem nacional”, inclusive PJe;
• Rastreamento proporcional de custos da nuvem nacional.
As formas de participação e colaboração são:
• Quem pode colaborar?

> O processo de disponibilização de soluções à plataforma é comunitário e descentralizado, podendo
dele participar quaisquer Tribunais brasileiros, órgãos públicos externos e, conforme regulamentação
de portaria da presidência do CNJ, particulares.
• Como habilitar a instituição como colaboradora?

> A instituição deve manifestar ao CNJ seu interesse em colaborar com o desenvolvimento da plataforma.
A habilitação como instituição colaboradora se dará por meio de assinatura de Termo de Cooperação
Técnica entre as duas partes, conforme estabelecido pela Gerência Executiva da PDPJ-Br.
Quais as formas de colaboração?
• Fornecer pessoal técnico para participar de desenvolvimento de serviços da plataforma;
• Formar equipe interna para desenvolver serviços para a plataforma;
• Juntar-se a outra instituição habilitada para desenvolver soluções para a plataforma;
• Formar equipes de homologação de serviços;
• Formar equipes especializadas em regras de negócio;
Qual o papel do CNJ no desenvolvimento dos projetos?
• Promovendo capacitações e eventos que promovam a integração e nivelamento de conhecimento

da comunidade;
• Provendo pessoal com atuação consultiva nos projetos que estejam sendo desenvolvidos para a PDPJ;
• Fornecendo ferramentas de colaboração para gestão e sustentação do desenvolvimento da plataforma

(controle de demandas, repositório de código e comunicação);
• Gerenciando o processo de designação de equipes e acompanhamento geral do projeto;
• Divulgando as ações e iniciativas em execução no contexto da PDPJ.
Como entregar um serviço?
• A primeira entrega de cada projeto é determinada pela finalização do MVP acordado na reunião de
kickoff. Tanto a primeira entrega do projeto (MVP), quanto as entregas parciais subsequentes, devem
ser apresentadas para a comunidade. Após a apresentação a entrega entrará em fase de homo-
logação, onde será criado ambiente semelhante ao de produção, já em infraestrutura de nuvem.
A solução deverá ser homologada pela comunidade. Sendo aprovada em homologação seguirá para
a disponibilização do ambiente em produção.
Quem é responsável pela sustentação dos serviços da plataforma?
• Após a primeira entrega de cada projeto em produção, o serviço disponibilizado passa a ser sustentado
pela equipe do projeto. Defeitos, bugs ou necessidades de melhoria serão tratados prioritariamente, mas
não exclusivamente, pelo time que criou o serviço.
Contexto dos Processos de Gerenciamento de Projetos

Nesta seção você irá visualizar as informações gerais sobre os processos de gerenciamento de projetos, principal-
mente o seu Ciclo de Vida e suas interações, de acordo com o Guia (PMBOK, 2017), aplicáveis a qualquer projeto.
1.1. CICLO DE VIDA

Para Mulcahy (2009), gerenciar um projeto envolve termos e processos técnicos, por meio da aplicação de conhe-
cimentos e ferramentas, respeitando um ciclo de vida, que na prática, é realizada pela aplicação e integração
de 42 processos agrupados logicamente, abrangendo os cinco grupos de processos “Iniciação”, “Planejamento”,
“Execução”, “Monitoramento e Controle” e “Encerramento”.
1.1.1. Ciclo de Vida de um Produto

O ciclo de vida de um produto dura desde sua concepção até sua retirada do mercado, desta forma o ciclo de vida
do produto pode ter vários projetos, como se pode perceber na Figura 1.
FIGURA 1 – PROJETOS NO CICLO DE VIDA DE UM PRODUTO
Fonte: Alinhado ao PMBOK, 2017
1.1.2. Ciclo de Vida de um Projeto

O ciclo de vida de um projeto é uma coleção de fases, geralmente sequenciais, com nomes e números específicos
vinculados ao processo produtivo de uma área de aplicação que definem o início e o encerramento do projeto.
Os projetos são divididos em fases e todos os projetos, grandes ou pequenos, têm uma estrutura de ciclo de vida
semelhante. Suas fases consistem em segmentos de trabalho que permitem gerenciamento, planejamento e
controle mais fáceis, segundo Heldman (2009).
FIGURA 2 – CAMINHOS DO GERENCIAMENTO DO PROJETO
Cabe ressaltar que dependendo do tamanho do projeto o grupo de processos de gerenciamento de projetos pode ocor-
rer apenas uma vez (projetos pequenos) ou várias vezes (projetos grandes), as Figuras 3 e 4 ilustram esta ocorrência.
FIGURA 3 – ESFORÇO DO GERENCIAMENTO DE PROJETOS EM PROJETOS PEQUENOS
FIGURA 4 – ESFORÇO DO GERENCIAMENTO DE PROJETOS EM PROJETOS GRANDES
A dinâmica dos projetos, por grau de esforço em relação ao tempo, nos grupos de processos de gerenciamento de
projetos, você poderá visualizar na Figura 5.
FIGURA 5 – INÍCIO E FIM DE CADA GRUPO DE PROCESSOS NO CICLO DE VIDA DO PROJETO
O nível de influência das partes interessadas, riscos e as incertezas são maiores no início do projeto e vão dimi-
nuindo no decorrer do projeto. Já o custo com as mudanças, à medida que o projeto é desenvolvido eles causam
maior impacto nos custos do mesmo. A Figura 6 apresenta, graficamente, a influência de ambos.
FIGURA 6 – INFLUÊNCIA DAS PARTES INTERESSADAS E CUSTO DE MUDANÇAS DURANTE O ANDAMENTO DO PROJETO
1.1.3. Lições Aprendidas

As lições aprendidas são um histórico do projeto, ela documenta o que deu errado no projeto e o que deu certo.
As Lições aprendidas são registradas nos ativos de processos organizacionais da empresa e pode ser alimentada
desde o início do projeto e são encerradas durante o encerramento do projeto.
Para Mulcahy (2009) as lições aprendidas devem abranger três áreas os aspectos técnicos do projeto, o gerencia-
mento do projeto (como foi a criação da EAP, planejamento dos riscos, garantia da qualidade, etc.) e também o
desempenho do gerenciamento do gerente de projetos (liderança, comunicação...).
Saiba mais sobre a importância da gestão do conhecimento nos projetos, que tem como base as lições apren-
didas dos projetos, por meio desse artigo.
http://vanzolini.org.br/blog/2014/06/o-processo-de-licoes-aprendidas-em-projeto-o-maior-dos-desafios-
-de-uma-organizacao/
1.2. PROCESSOS DE GERENCIAMENTO DE PROJETOS

Os processos de gerenciamento de projetos descrevem o que é necessário fazer para que o projeto seja gerenciado.
Você não deve confundir fases e ciclos de vida do projeto, Heldman (2009), com os grupos de processos de
gerenciamento de projetos, pois fases e ciclos descrevem como será concluído o trabalho associado ao produto
do projeto e os grupos de processos organizam e descrevem como serão conduzidas as atividades para que os
requisitos do projeto sejam atingidos.
1.2.1. Iniciação
São os grupos de processos de iniciação que formalizam um novo projeto ou fase, autorizando oficialmente o
projeto e fornece as informações necessárias ao gerente de projetos, segundo Heldman (2009). Ocorre a definição
do escopo preliminar ou não detalhado do projeto, são levantados os riscos primários, premissas e restrições,
identificação dos stakeholders, elaboração e aprovação do termo de abertura do projeto.
1.2.2. Planejamento
Durante o planejamento do projeto, e enquanto o trabalho está sendo feito é possível economizar recursos, tempo
e dinheiro.
Neste grupo de processos, são definidos e coletadas as premissas, restrições e requisitos, os quais determinam
se os objetivos do projeto declarados no termo de abertura do projeto podem ser alcançados, identifica a equipe,
papéis e responsabilidades no projeto, criação da EAP, plano de gerenciamento de mudanças, identificação de
riscos e estratégias de respostas, obtenção do plano e reunião de início do projeto.
1.2.3. Execução
A execução deve ser direcionada basicamente para a realização do trabalho definido no plano de gerenciamento
do projeto, com foco em pessoas. São implementadas as mudanças, as ações e soluções alternativas aprovadas
e melhoria do desempenho da equipe.
1.2.4. Monitoramento e Controle

O monitoramento e controle para Dismore; Cavalieri (2010), é utilizado para monitorar o progresso do trabalho exe-
cutado e identificar os problemas e variações dentro de um grupo de processos bem como o projeto como um todo.
1.2.5. Encerramento
O encerramento ocorre, quando todas as entregas previstas para o projeto são realizadas e aprovadas e todos os
documentos de encerramento estiverem concluídos.
A Figura 7 apresenta o mapa de processos de gerenciamento de projetos conforme consta no Guia PMBOK.
FIGURA 7 – PROCESSOS DE GERENCIAMENTO DE PROJETOS
Como referência, o guia de processos e artefatos da Metodologia de Gerenciamento de Projetos (MGP) de Tecnologia
da Informação do CNJ é o seguinte:
FIGURA 8 – PROCESSOS DE GERENCIAMENTO DE PROJETOS DA MGP TI DO CNJ
Assista ao vídeo sobre uma abordagem interessante de aplicação interna dos processos de gerenciamento
de projetos. https://www.youtube.com/watch?v=6LB_QF4LXLI
Gerenciamento da Integração
O gerenciamento da integração aborda o trabalho de alto nível que um gerente de projetos deve realizar. Ele possui
os processos necessários para coordenar adequadamente os vários elementos do projeto, tornando-se a principal
área de conhecimento, percebido na Figura 9.
FIGURA 9 – ÁREAS DE CONHECIMENTO DE GERENCIAMENTO DE PROJETOS
Segundo Dismore; Cavalieri (2010), é como montar um quebra cabeça, cada peça deve ser colocada no seu devido
lugar, de manei coerente e consistente, a fim de se obter um resultado final esperado e cada peça contribui subs-
tancialmente para o todo.
Para Mulcahy (2009) a integração é a busca do equilíbrio de todos os processos nas áreas de conhecimento (escopo,
tempo, custos, qualidade, Rh, comunicações, riscos e aquisições), pois eles não ocorrem independentemente um
do outro.
O Gerenciamento da Integração é a única área de conhecimento que possui processos em todos os grupos de
processos de gerenciamento de projetos. O gerente de projetos está sempre integrando todas as áreas de conhe-
cimento, veja na Figura 10 os processos dessa área do conhecimento.
FIGURA 10 – GRUPOS DE PROCESSOS DE GERENCIAMENTO DA INTEGRAÇÃO
2.1. DESENVOLVER O TERMO DE ABERTURA DO PROJETO

É o processo de desenvolvimento de um documento (Termo de Abertura – Figura 11) que formaliza e autoriza um
projeto ou fase de um projeto e levanta a documentação dos requisitos iniciais que satisfaçam as necessidades
e expectativas das partes interessadas.
Para Heldman (2009), é o reconhecimento por escrito da existência do projeto, documentando o nome do gerente
do projeto e concedendo a essa pessoa autoridade para atribuir recursos organizacionais ao projeto.
FIGURA 11 – PROCESSO DESENVOLVER O TERMO DE ABERTURA DO PROJETO
O Termo de Abertura do Projeto é um documento oficial emitido pela alta direção da organização que empossa o
gerente do projeto, autoriza e comunica formalmente o início do projeto na própria organização.
Um Termo de Abertura de um grande projeto ou fase deve ter, segundo Mulcahy (2009), as seguintes informações:
Título do projeto (o que é o projeto);
Por exemplo: Implantação de Piloto do PJe no Tribunal de Justiça.
Gerente de projetos é designado e nível de autoridade é definido (Quem tem autoridade para liderar o projeto?
Essa pessoa pode determinar, gerenciar e aprovar mudanças no orçamento, cronograma, pessoal, etc.?);
Justificativa (Por que este projeto está sendo realizado? Qual critério social ou de outro tipo podemos usar para
justificar este projeto);
Por exemplo:
Dentre as iniciativas de transformação digital no âmbito do Judiciário Brasileiro, destaca-se o sistema de processo
judicial eletrônico (PJe). O PJe é uma plataforma digital desenvolvida pelo CNJ em parceria com diversos Tribunais
e conta com a participação consultiva do Conselho Nacional do Ministério Público, Ordem dos Advogados do
Brasil, Advocacia Pública e Defensorias Públicas. O PJe caracteriza-se pela proposição da prática de atos jurídicos
e acompanhamento do trâmite processual de forma padronizada, mas considerando características inerentes
a cada ramo da Justiça. Objetiva a conversão de esforços para a adoção de solução padronizada e gratuita
aos Tribunais, atenta à racionalização aos ganhos de produtividade nas atividades do judiciário e também aos
gastos com elaboração ou aquisição de softwares, permitindo o emprego de recursos financeiros e de pessoal
em atividades dirigidas à finalidade do Judiciário.
Os sistemas de tramitação processual são úteis a todo o sistema de justiça, e não apenas ao Poder Judiciário.
São diversas as partes interessadas: advogados privados que usam o sistema para defender seus clientes;
membros do ministério público que oferecem denúncias contra suspeitos de crimes; advogados públicos na
defesa do Estado; as partes dos processos no acompanhamento de ações de seu interesse; corregedorias na
obtenção de informações para a avaliação do desempenho de órgãos judiciais; delegacias de polícia na requi-
sição de mandados judiciais urgentes.
Neste sentido o PJe enquanto política e também como plataforma digital que oferece soluções para os tribunais,
para as instituições públicas e para os operadores do Direito atravessarem as transformações sociais em andamento.
Recursos pré-designados (Quantos ou quais recursos serão disponibilizados?);
Partes interessadas (Quem afetará ou será afetado pelo projeto, qual influência no projeto, de acordo com os
dados conhecidos até o momento?);
Por exemplo:
Conselho Nacional de Justiça, Rede de Governança do PJe, tribunais parceiros, Ordem dos Advogados do Brasil,
Ministério Público, Advocacia-Geral da União, Defensoria Pública e sociedade em geral.
Requisitos das parte interessadas já conhecidos (Requisitos relacionados ao projeto e ao escopo do produto);
Por exemplo:
• Melhoria da estatística;
• Redução do custo de tecnologia;
• Aquisição de conhecimento do sistema PJe;
• Oportunidade de padronizar;
• Impulsionar a transformação digital;
• Aproveitamento de módulos desenvolvidos por outros tribunais;
• Métricas de produtividade;
• Integração com outros tribunais;
• Uniformização do acesso à Justiça;
• Alinhamento e facilitação na transmissão de dados do TJ para o CNJ;
• Homogeneização dos sistemas processuais no estado, no sentido de facilitar o acesso pelos operadores
externos do direito;
• Adequação aos normativos do CNJ (res. 185, Justiça em Números, Modernização Estadual);
• Redução da quantidade de servidores;
• Aproveitamento de módulos desenvolvidos por outros tribunais.
Descrição do produto/entregas (Quais entregas específicas de produtos são desejadas e qual será o resultado
final do projeto?);
Por exemplo:
Entrega Início Término Unidade Responsável
1.1 Criação de instâncias de governança Nov. 19 Nov. 19 Presidência

e de gestão do PJe no TJ, e Grupos
de Trabalho de Implantação
1.2 Disponibilização do Ambiente de Nov. 19 Dez. 19 CNJ

Homologação e Produção
1.3 Capacitação técnica configuração, fluxos Dez. 19 Dez. 19 CNJ
1.4 Ajustar Fluxos BPM (mapeamento) Nov. 19 Jan. 20 Grupo de Trabalho
1.5 Disponibilização do Ambiente de Jan. 20 Jan. 20 CNJ

Homologação e Produção
1.6 Configuração do Fluxo no PJE Jan. 20 Fev. 20 STI
1.7 Imersão técnica no PJE(CNJ) para Jan. 20 Fev. 20 CNJ, STI

implementação dos gaps(impeditivos)
e Ajustes de Fluxos
1.8 Teste do Ambiente de Homologação e Produção Fev. 20 Fev. 20 Grupo de Trabalho
1.9 Alinhamento com atores externos (OAB, Jan. 20 Fev. 20 Presidência e Grupo
MP, PGE e PGM, Defensoria Pública, etc.) de Trabalho
1.10 Configuração do sistema Jan. 20 Fev. 20 CNJ, Grupo de Trabalho
1.11 Integração com o legado Jan. 20 Mar. 20 STI
1.12 Capacitação dos multiplicadores Mar. 20 Mar. 20 Grupo de Trabalho
1.13 Capacitação interna e externa Mar. 20 Abr. 20 Grupo de Trabalho
1.14 Estabelecimento de um Acordo Abr. 20 Abr. 20 CNJ, STI

de Nível Operacional (ANO)
1.15 Ato normativo Implantação Abr. 20 Abr. 20 Presidência
1.16 Go-live Mai. 20 Grupo de Trabalho, STI
1.17 Operação Assistida Mai. 20 Jul. 20 CNJ, Grupo de

Trabalho, STI
1.18 Report de Lições aprendidas e Mai. 20 Ago. 20 CNJ, Grupo de

transição para fase de expansão Trabalho, STI
Objetivos mensuráveis do projeto (Como o projeto se encaixa nas metas estratégicas do Tribunal? Quais obje-
tivos do projeto sustentam essas metas? Os objetivos precisam ser mensuráveis e dependem da prioridade
definidas nas restrições do projeto);
Por exemplo:
• Contribuir para o reconhecimento do Judiciário perante a sociedade como “instrumento efetivo de justiça,
equidade e paz social.”
• Agregar valor aos atributos sociais ofertados para a sociedade, com especial atenção à Credibilidade,
Celeridade, Modernidade, Acessibilidade e Transparência.
• Concorrer para a superação do macro desafios de Efetividade, Celeridade e Produtividade na prestação

judicial, bem como a Instituição da governança judiciária e a Melhoria da infraestrutura de tecnologia
da informação.
Requisitos de aprovação do projeto (Quais itens precisam ser aprovados para o projeto e quem vai aprová-los?
O que indica o sucesso?);
Riscos de alto nível do projeto (Possíveis ameaças e oportunidades para o projeto);
Por exemplo:
• Resistência dos atores internos e externos;
• Surgimento de novos gaps entre as ferramentas e áreas afins;
• Indisponibilidade do serviço de internet;
Patrocinadores que autorizam o projeto (nome, cargo e assinatura do patrocinador).
Por exemplo: Presidência do Tribunal de Justiça.
Segundo, Heldman (2009), as principais entradas para desenvolver o termo são a declaração do trabalho, o caso
de negócio, contratos, fatores ambientais da empresa e ativos de processos organizacionais.
No grupo de processos de iniciação o gerenciamento da integração seleciona o gerente de projetos, determina

a cultura e os sistemas existentes na organização, coleta informações históricas, dividi projetos grandes em
fases, compreende o business case, identifica riscos e requisitos iniciais, criação de objetivos mensuráveis e
desenvolve o termo de abertura.
Outra forma de representar o termo de abertura do projeto é utilizando o modelo project canvas, que é um
modelo adequado às práticas enxutas e ágeis de gerenciamento de projeto, e tem por princípios:
• Dispor a informação de forma mais agrupada e visual;
• Simplificar e sequenciar a integração das informações;
• Estabelecer uma base sólida para os interessados.
Por exemplo:
FIGURA 12 – MODELO DE PROJECT CANVAS
O CNJ utiliza o seguinte modelo de project canvas:
FIGURA 13 – MODELO DE PROJECT CANVAS DO CNJ
Saiba mais sobre como elaborar o termo de abertura do projeto, tendo em vista as seguintes dicas: http://
www.p4pro.com.br/index.php/artigos/32-dicas-para-a-elaboracao-de-termos-de-abertura-de-projetos
2.2. DESENVOLVER O PLANO DE GERENCIAMENTO DO PROJETO
É o processo de documentação das ações que você necessárias para definir, preparar, integrar e coordenar todos
os planos auxiliares e define como o mesmo será executado, monitorado e controlado e encerrado (Figura 14).
FIGURA 14 – PROCESSO DESENVOLVER O PLANO DE GERENCIAMENTO DO PROJETO
Para Heldman (2009), os planos são estratégias desenvolvidas para gerenciar projetos e processos, isso quer dizer
que você deve planejar antes de agir. O nível de detalhamento dos planos depende das necessidades do projeto,
do estilo do gerente de projetos e das influências da organização.
O plano de gerenciamento de projetos te função de integração de todos os planos de gerenciamento das áreas de
conhecimento em uma unidade coesa. Para Mulcahy (2009) o plano de gerenciamento de projetos inclui:
• Quais processos de gerenciamento de projetos que serão utilizados no projeto, pois o gerente de projetos
não precisa utilizar todos os processos de gerenciamento de projetos previstos no Guia PMBOK, ele utilizará
os que acharem necessário;
• Os planos de gerenciamento de escopo, cronograma, custos, qualidade, recursos humanos, comunicações

riscos e aquisições;
• Os planos de gerenciamento auxiliares como o de requisitos (como serão identificados, gerenciados e con-
trolados), o de mudanças (como serão controladas, quem, nível de aprovação...), o de configuração (versão
de documentos) e o de melhoria de processos (para ganhar tempo, diminuir custos e qualidade superior);
• Linhas de base do escopo (declaração do escopo, EAP e o dicionário da EAP, do cronograma (datas de início
e término) e de custos (orçamento de custos por período); e
• Desvios nas linhas de base do projeto ocorrem por problemas na identificação e no gerenciamento dos riscos.
Para Dismore; Cavalieri (2010), o planejamento de um projeto é um processo dinâmico que ocorre durante todo o
ciclo de vida do projeto, se sobrepondo em muitos momentos aos processos de execução e controle.
A dica é que após a elaboração do plano de gerenciamento do projeto e sua aprovação, é realizada a reunião de
partida ou kickoff dando início à execução do projeto.
Assista ao vídeo a seguir. Ele dá um panorama geral e resumido sobre o plano de gerenciamento de projetos.
https://www.youtube.com/watch?v=qc9XNXXhfpQ
Gerenciamento do Escopo do Projeto

O gerenciamento do escopo do projeto inclui os processos necessários para assegurar que o projeto inclui todo
o trabalho necessário, e apenas o necessário, para terminar o projeto com sucesso, incluindo, principalmente, a
relação de definição e controle do que está e do que não está incluso no projeto, segundo o Guia PMBOK (2017).
A Figura 15 mostra os processos do gerenciamento do escopo do projeto.
FIGURA 15 – GRUPO DE PROCESSOS DO GERENCIAMENTO DO ESCOPO
Segue alguns termos que você deve conhecer, segundo Heldman (2009):
1) Escopo do produto define características e funções que descrevem um produto, serviço ou resultado. Ele
responde a pergunta de qual é o resultado final desejado que você queira ter ao encerrar o projeto;
2) Escopo do projeto define o trabalho que precisa ser realizado para entregar o produto, serviço ou resultado
com as características e funções especificadas do projeto; e
3) Plano de gerenciamento do Escopo define como você determina o escopo, quais ferramentas necessárias
você deve usar para planejar como realizar o escopo do projeto. Então, ele deve ser desenvolvido em três
partes, como o escopo será planejado, executado e controlado.
A dica é que como o Guia PMBOK não indica que o plano de gerenciamento do escopo é um processo documentado,
separado, você deve saber que ele está incluso no gerenciamento da integração como uma saída do processo
Desenvolver plano de gerenciamento do projeto.
3.1. COLETAR REQUISITOS

Processo de definir e documentar as funções e funcionalidades do projeto e do produto necessárias para atender
às necessidades e expectativas das partes interessadas, Guia PMBOK (2017). A Figura 16 demonstra este processo.
FIGURA 16 – PROCESSO COLETAR REQUISITOS
Este processo envolve coletar informações mais específicas sobre os requisitos de alto nível identificados no termo
de abertura do projeto. Este processo é crítico para o sucesso do projeto, tendo em conta que um requisito não
incluso pode significar mudanças, conflitos e até o fracasso do projeto.
Na prática, é provável que você execute definir escopo antes do processo coletar requisitos, pois as entregas pre-
cisam ser identificadas antes que você possa documentar seus requisitos detalhados, segundo Heldman (2009).
O gerente de projetos deve escolher quais técnicas utilizar para coletar requisitos do projeto junto das partes
interessadas. A seguir, seguem técnicas utilizadas, segundo Mulcahy (2009):
1) Entrevista técnica utilizada com especialistas e com partes interessadas, assim de levantar elementos
específicos do produto ou do projeto ou do projeto de maneira global;
2) Grupos de foco técnica de reunião utilizada para levantar informações específicas de um projeto. É realizada
com especialistas de um determinado ponto específico do projeto e coordenada por um moderador;
3) Workshops facilitados está técnica reúne técnicos de diversas áreas para discutir sobre o produto e che-
garem a um consenso;
4) Brainstorming técnica que reúne as pessoas para buscar um pensamento em grupo, ou seja, uma pessoa
dá uma ideia e os outros vão formando opiniões sobre o assunto;
5) Técnica de grupo nominal utilizada na reunião de brainstorming para selecionar as melhores ideias;
6) Técnica Delphi técnica que por meio de solicitação de informações a especialistas que participam anoni-
mamente, encaminham opiniões, as quais são compiladas e os resultados são enviados de volta a eles
para revisão até o alcance de um consenso;
7) Mapas mentais é um diagrama de ideias ou observações para ajudar a gerar, classificar ou registrar informações;
8) Diagramas de afinidade são o agrupamento, por afinidade, das ideias geradas com quaisquer outras
técnicas de coleta de requisitos, facilitando a visualização de escopo adicional;
9) Questionários e pesquisas ferramentas que apresentam questões que auxiliam na identificação dos requi-
sitos dos entrevistados;
10) Observação técnica que consiste em assistir a um potencial usuário de o produto utilizá-lo e, assim, iden-
tificar mais requisitos
11) Protótipos são um modelo do produto proposto, sendo apresentados aos interessados a fim de gerar
opinião; e
12) Tomada de decisão em grupo quando existem opiniões diferentes num grupo, esta técnica é utilizada pela
escolha majoritária.
Para o Guia PMBOK (2017), as saídas deste processo são a documentação de requisitos (nada mais é que a docu-
mentação dos requisitos após a coleta e a finalização dos requisitos), plano de gerenciamento dos requisitos
(descreve os métodos utilizados para identificar os requisitos e responde a questões do tipo quando eu tiver
todos os requisitos, o que farei para analisar, priorizar, gerenciar e controlar as mudanças neles? Criar matriz de
rastreabilidade para eles?) e Matriz de rastreabilidade de requisitos (busca controlar os requisitos durante o ciclo
de vida do projeto a fim de garantir que sejam cumpridos).
A dica é a de que quando ocorrer requisitos conflitantes, Mulcahy (2009) afirma que o gerente de projetos deve
facilitar sua solução aceitando aqueles que são compatíveis com os critérios do business case, do termo de aber-
tura, da declaração do escopo do projeto e das restrições do projeto.
3.2. DEFINIR ESCOPO
Processo de desenvolvimento de uma descrição detalhada do projeto (Figura 17) e do produto, refere-se, principal-
mente ao que está ou ao que não está incluso no projeto e nas suas entregas, para o Guia PMBOK (2017).
FIGURA 17 – PROCESSO DEFINIR ESCOPO
Segundo Mulcahy (2009), este processo é importante para construir um cronograma e um orçamento realistas e
para que isso aconteça o gerente de projetos deve realizar iterações com os outros processos.
As principais saídas deste processo, para Dismore; Cavalieri (2010),é a declaração do escopo do projeto que
pode incluir o escopo do produto e do projeto, as entregas, os critérios de aceitação do produto, o que não
faz parte do projeto e as restrições e premissas, bem como fornecer uma base de referência em termos de
escopo do projeto.
A dica aqui é a de que a declaração de escopo do projeto, junto da EAP e do dicionário da EAP, compõe a linha de
base do escopo do projeto e que faz parte do plano de gerenciamento do projeto. Ela fornece um entendimento
comum acerca do escopo do projeto a todos os stakeholders, detalha os escopos do produto e do projeto, relaciona
os limites do projeto, serve como base para avaliar solicitações de mudanças ou trabalhos adicionais.
3.3. CRIAR A ESTRUTURA ANALÍTICA DO PROJETO (EAP)

A Estrutura Analítica do Projeto (EAP) é uma representação gráfica detalhada de todo e somente o trabalho neces-
sário para atingir os objetivos do projeto.
Para o Guia PMBOK (2017) é o processo que realiza a subdivisão das principais entregas do projeto e do trabalho
do projeto em componentes menores e mais gerenciáveis, ilustrado na Figura 18.
Também, o nível mais baixo de uma EAP é pacote de trabalho, cada pacote de trabalho deve possuir um código
de identificação único, uma entrega específica e verificável, um único responsável, deve ter de 40 a 80 horas de
duração de acordo com o ciclo de acompanhamento, recursos humanos, materiais e equipamentos alocados, um
custo definido cujo cálculo deve considerar os recursos alocados, cada Entrega deve ter um cliente validador e
critérios de aceite previamente acordados com este cliente.
Ainda, os elementos decompostos, ou seja, aqueles que não são pacotes de trabalhos são chamados de
tarefas-resumo.
FIGURA 18 – PROCESSO CRIAR A EAP
Para Heldman (2009), a exatidão da EAP depende da exatidão de sua lista de requisitos e entregas, as entregas se
tornarão agrupamentos que formarão os níveis mais altos da EAP, a partir dos quais as atividades serão derivadas
mais tarde nos processos de planejamento.
Para o preenchimento de uma EAP, segundo Mulcahy (2009), é necessário utilize substantivos para nomear cada
elemento da EAP, crie no Dicionário da EAP uma tabela que contenha as definições de cada elemento da estrutura,
deve possuir um sistema de numeração que possibilite a identificação única de cada elemento de sua composição,
não pode haver um elemento filho vinculado a mais de um elemento pai, nunca elabore a EAP sem a participação
da sua equipe, use a técnica de planejamento em ondas sucessivas caso não consiga decompor alguma entrega
do seu projeto e lembre-se do esforço de gerenciamento do projeto ao elaborá-la.
Uma EAP pode ser montada da seguinte forma, segundo o website https://www.elirodrigues.com/como-fazer-
-uma-eap-wbs/:
1) Por fase ou estágio (Figura 19), mostra as fases principais necessárias para um projeto e não necessitam
estar na sequência correta;
FIGURA 19 – EAP POR FASE
Fonte: PMI
2) Por linha de tempo (Figura 20), a equipe cria EAP sequencial na ordem em que o trabalho deve ser
executado; e
FIGURA 20 – EAP POR LINHA DE TEMPO
Fonte: PMI
3) Por entregas (Figura 21), inicialmente você determinará as entregas que o projeto produzirá e então dividirá
estas entregas em pacotes, que formam a entrega.
FIGURA 21 – EAP POR LINHA DE TEMPO
Fonte: PMI
Exemplo de EAP aplicada ao PJe:

FIGURA 22 – EAP POR ENTREGA DO PJE
Uma outra abordagem para construção de EAPs, considerando a abordagem ágil de gestão de projetos, é estru-
tura-la da seguinte forma:
FIGURA 23 – EAP ÁGIL
Fonte: https://www.quora.com/
A figura 25 ilustra um comparativo entre o modelo tradicional e o modelo ágil de construção de EAPs:
FIGURA 25 – EAPS COMPARATIVO
Fonte: PMI
Dicas para a uma utilização de uma EAP são as de que uma boa imagem é melhor do que mil palavras, é melhor
entender o todo pelas suas partes constituintes e o trabalho que não está na EAP está fora do escopo do projeto.
Elaborada a EAP, segundo Dismore; Cavalieri (2010), é criado o dicionário da EAP, que consiste em fornecer uma
descrição do trabalho a ser realizado em cada pacote de trabalho e ajuda a garantir que o trabalho resultante
corresponda ao que é necessário.
A dica é a de que o dicionário da EAP, para Heldman (2009), deve conter as definições dos elementos que compõem
a EAP, códigos contábeis ou sistemas de numeração que possibilitam identificar individualmente cada elemento
da EAP e as descrições dos componentes de trabalho.
Os benefícios da EAP são: proporcionar uma visão única de todo o escopo do projeto, fornecer uma base para
estimativas de recursos, custos e tempo, fornecer uma base para identificação e análise de riscos, facilitar a defi-
nição clara de papéis e atribuição de responsabilidades, facilitar a comunicação entre a equipe do projeto e os
stakeholders, é um instrumento de marketing, dentre outros.
Assista ao vídeo do Ricardo Vargas sobre a elaboração de EAP. https://www.youtube.com/watch?v=TS9eciG-Ddw
Referências citadas na UIA 1

DISMORE, Paul Campbell; CAVALIERI, Adriane. Como se Tornar um Profissional em Gerenciamento de Projetos.
3ª Edição. Rio de Janeiro. Qualitymark Editora Ltda. 2010.
HELDMAN, K. Guia para o Exame Oficial do PMI. 5ed. Rio de Janeiro: Elsevier, 2009. cap. 1 a 12.
MULCAHY, R. Preparatório para o Exame de PMP. 6ª ed. EUA. RMC Publications, Inc, 2009. cap 1 a 12.
PROJECT MANAGEMENT INSTITUTE (PMI). Project Management Boby of Knowledge (PMBOK). ed. Pennsylvania, 2017.
Gestão de Projetos na Prática, 5.3.01.1 Como fazer EAP. Disponível em: https://www.elirodrigues.com/como-fazer-
-uma-eap-wbs/. Acesso em 20 de abril de 2020.
Glossário dos termos citados na UIA 1
Tabela de termos técnicos da UIA e suas respectivas definições.
Termo Definição do termo apresentado
É uma representação gráfica detalhada de todo e somente o trabalho necessário para

EAP
atingir os objetivos do projeto.
Ou deliverable é, na terminologia do gerenciamento de projeto, um objeto tangível

Entrega ou intangível produzido como resultado da execução do projeto. Uma entrega pode
ser criada a partir de múltiplas entregas menores.
É a reunião inicial do projeto, e marca o momento em que os acertos institucionais e

comerciais devem ser feitos entre as partes envolvidas e a realização propriamente dita
Kick-off
pode começar. Com escopo variável de acordo com os profissionais e as organizações
envolvidas, este encontro ajuda a criar um clima propício à criação e à colaboração.
Registros e documentos de projetos, todas as informações e a documentação relativas

ao encerramento do projeto, informações sobre os resultados de decisões a respeito
Lições Aprendidas
da seleção de projetos anteriores e informações sobre o desempenho de projetos
anteriores e informações do esforço de gerenciamento de riscos.
Indivíduos ou organizações que estão envolvidos diretamente com o projeto ou são

Stakeholders
afetados positiva ou negativamente com sua execução ou resultados.
Scrum É um framework de gerenciamento de projetos, da organização ao desenvolvimento

ágil de produtos complexos e adaptativos com o mais alto valor possível
User stories scrum As histórias de usuários são um dos principais artefatos de desenvolvimento para as
equipes de projeto do Scrum. Uma história de usuário é uma definição de nível muito
alto de um requisito, contendo apenas informações suficientes para que os desen-
volvedores possam produzir uma estimativa razoável do esforço para implementá-lo.
UIA 2 | GERENCIAMENTO DO
TEMPO E DO CUSTO DOS PROJETOS
Gerenciamento do Tempo I
O gerenciamento do tempo aborda o trabalho necessário para definir o cronograma de um projeto, bem como
gerenciar e controlar. Inclui todos os processos necessários para planejar como concluir o projeto no prazo, para
o Guia PMBOK (2017).
Também, Dismore; Cavalieri (2010), reforça que a finalidade é a de assegurar que o projeto será implantado no
prazo previsto.
A Figura 26 lista o grupo de processos do gerenciamento do tempo.
FIGURA 26 – GRUPO DE PROCESSOS DO GERENCIAMENTO DO TEMPO
Para Mulcahy (2009), o plano de gerenciamento do cronograma é desenvolvido no processo desenvolver o

plano de gerenciamento do projeto no gerenciamento da integração. Um plano de cronograma inclui a meto-
dologia e o software utilizados para desenvolvê-lo, o estabelecimento de uma linha de base do cronograma
para medição durante o monitoramento e controle, identificação das medições de desempenho que serão
usadas do projeto para detectar variações e como elas serão geridas e identificação dos procedimentos de
controle de mudanças.
Leia o artigo que trata das 10 dicas para melhorar a gestão de tempo no gerenciamento de projetos.
https://www.riotron.com.br/10-maneiras-de-melhorar-a-gestao-de-tempo-dos-seus-projetos/
4.1. DEFINIR AS ATIVIDADES
É o processo de Identificar as atividades que devem ser executadas para a entrega dos produtos do projeto. Para o
Guia PMBOK (2017), é o processo de identificação das ações específicas a serem realizadas para produzir as entregas
do projeto como pode-se ver na Figura 27.
FIGURA 27 – PROCESSO DESENVOLVER O TERMO DE ABERTURA DO PROJETO
Uma vez definido o escopo do projeto e seus principais produtos identificados, as atividades para o alcance dos
objetivos precisam ser detalhadas a partir dos pacotes de trabalho da EAP.
Para Mulcahy (2009), definir as atividades resulta em uma lista de atividades e na conclusão dos detalhes das
atividades (atributos). E também resulta na determinação dos marcos que serão usados no projeto.
Para Dismore; Cavalieri (2010), os marcos são eventos significativos no cronograma do projeto. Lembrando que eles
não são atividades do projeto, são como por exemplo, datas de entregas do cliente.
4.2. SEQUENCIAR AS ATIVIDADES

Identificar e documentar a sequencia lógica na qual as atividades devem ser executadas e estabelecer a relação
de dependência entre elas. Cada atividade e marco, com exceção do primeiro e do último, são conectados a pelo
menos um predecessor e um sucessor, segundo o Guia PMBOK (2017).
Para Mulcahy (2009), o resultado de processo é, principalmente, um diagrama de rede de cronograma do Projeto,
como se pode ver na Figura 28.
FIGURA 28 – PROCESSO SEQUENCIAR AS ATIVIDADES
Os diagramas de rede do projeto são representações esquemáticas das atividades do cronograma do projeto e
dos relacionamentos lógicos entre elas (dependências), desenhados da esquerda para direita para refletir ordem
cronológica dos acontecimentos e se podem ser executadas em paralelo.
4.3. MÉTODO DO DIAGRAMA DE PRECEDÊNCIAS (MDP) OU ATIVIDADE NO NÓ (ANN)

Para Mulcahy (2009), neste método são usados nós para representar atividades e setas para mostrar depen-
dências. Existem quatro tipos de relacionamentos lógicos, segundo Heldman (2009) que seguem:
1) Término para início (TI) uma atividade deve terminar antes que a sucessora possa iniciar;
2) Início para início (II) uma atividade deve começar antes que a sucessora inicie;
3) Término para término (TT) uma atividade deve terminar antes que a sucessora possa terminar; e
4) Início para término (IT) é necessário iniciar uma atividade antes que a sucessora possa terminar.
Ainda, Heldman (2009), afirma que o relacionamento término para início é o mais comumente utilizado no método
MDP e que o de início para término é o menos utilizado.
Vejam os gráficos ilustrativos desse tipo de diagrama de redes no seguinte website: http://wpm.wikidot.com/
tecnica:metodo-do-diagrama-de-precedencia-mdp
4.4. GRAPHIC EVALUATION AND REVIEW TECHNIQUE (GERT)
Essa técnica permite ciclos entre atividades dentro de um diagrama de redes. Para Mulcahy (2009), essa técnica
é utilizada quanto você tem uma atividade de projetar um componente e depois testá-lo, depois do teste pode
ser ou não necessário reprojetá-lo.
Segundo o Guia PMBOK (2017), existem 3 tipos de dependências:
1) Obrigatórias (lógica rígida),são inerentes ao trabalho que está sendo executado;
2) Arbitrarias (lógica preferida, preferencial ou flexível), definido pela equipe de gerenciamento do projeto
com base nas melhores práticas; e
3) Externas, são relações entre atividades do projeto e atividades fora do projeto.
Para Mulcahy (2009), existem antecipações que podem ser adicionadas para iniciar uma atividade antes que a
predecessora esteja terminada e uma espera que nada mais é do que uma inserção de um tempo entre atividades.
Ainda, a dica é a de que as estimativas devem se basear numa EAP para aumentar sua exatidão, sempre que
possível elas devem ser elaboradas pela pessoa que irá executá-la, as estimativas podem ser diminuídas redu-
zindo ou eliminando riscos, deve haver um processo de sequenciamento das atividades e o gerente de projetos
tem a responsabilidade de fornecer estimativas exatas e viáveis.
Uma abordagem ágil para definição e sequenciamento de atividades é utilizar o modelo de sprints assim como
ilustrado na figura 29:
FIGURA 29 – PROCESSO SEQUENCIAR AS ATIVIDADES
Fonte: https://www.visual-paradigm.com/
Gerenciamento do Tempo II
5.1. ESTIMAR OS RECURSOS DA ATIVIDADE

Este processo determina quais recursos são necessários, que quantidades de cada um devem ser usadas, e
quando estarão disponíveis para a execução das atividades do projeto segundo o Guia PMBOK (2008), o processo
está demonstrado na figura 26.
Para Mulcahy (2009), depois das atividades sequenciadas, é necessário determinar o tipo e a quantidade de
recursos necessários para executá-las, visando falta de recursos e a retirada de recursos do projeto, verificado
na Figura 30. Os principais resultados são a quantidade para cada atividade dos pacotes de trabalho da EAP
que os recursos são necessários, uma estrutura analítica dos recursos de forma hierárquica e por categoria
e um calendário de recursos que identificam o período de disponibilidade dos recursos alocados (pessoas,
materiais, equipamentos, salas, etc.).
FIGURA 30 – PROCESSO ESTIMAR OS RECURSOS DA ATIVIDADE
Lembre-se, segundo Heldman (2009), que a saída de recursos da atividade a partir do processo estimar os recursos
das atividades é uma entrada para o processo desenvolver o plano de recursos humanos.
5.2. ESTIMAR AS DURAÇÕES DA ATIVIDADE
Para o Guia PMBOK (2008) este processo concerne na em analisar informações sobre o escopo do projeto e os
recursos disponíveis para estimar a duração de cada atividade do cronograma (Figura 32).
FIGURA 32 – PROCESSO ESTIMAR AS DURAÇÕES DA ATIVIDADE
Segundo Mulcahy (2009), as atividades podem ser estimadas usando as seguintes técnicas:
1) Estimativa única é quando o estimador apresenta uma única estimativa por atividade e é responsabilidade
do gerente de projetos fornecer o maior número de informações para que se estime adequadamente cada
atividade, informar o quanto elas devem ser refinadas e impedir aumentos arbitrários;
2) Estimativas análogas (top down) baseadas nas durações reais de atividades similares em projetos
anteriores;
3) Estimativas paramétricas quantidade de trabalho da atividade (esforço) dividido pela taxa de produ-
tividade com base em registros históricos de projetos anteriores e outras informações. Os resultados
desta estimativa podem virar uma heurística (o trabalho de protótipo sempre representa 25% da
duração total do projeto);
4) Análise das reservas (contingência) tempo adicional que pode ser adicionado à duração da atividade,
levando em conta os riscos de atraso; e
5) Estimativas de três pontos (Análise PERT) média ponderada entre uma estimativa mais provável (MP), uma
otimista (O) e pessimista (P) [P+4MP+O]/6.
A dica aqui é a de que você deverá saber as seguintes fórmulas e quando utilizá-las da análise PERT:
• Duração esperada [P+4MP+O]/6
• Desvio padrão [P-O]/6
• Variância [P-O]/6
Para Heldman (2009), o objetivo é usar as técnicas acima mencionadas para controlar melhor o projeto.
5.3. MÉTODOS DO DESENVOLVIMENTO DO CRONOGRAMA

É o processo em que são indicadas as datas de início e término planejadas para todas as atividades do projeto.
Se estas datas não forem realistas, provavelmente o projeto não terminará conforme o planejado, segundo o Guia
PMBOK (2017) (Figura 33).
Segundo Dismore; Cavalieri (2010), você deve levar bastante atenção nas restrições e premissas para desenvolver
um cronograma, pois elas podem ser limitações de tempo.
FIGURA 33 – PROCESSO DESENVOLVER O CRONOGRAMA
Depois de elaborado um cronograma inicial é realizada uma análise de rede do cronograma para chegar à
uma versão final do documento, podendo utilizar uma ou mais das seguintes técnicas, Método do caminho
crítico, compressão do cronograma, análise do tipo “e-se”, nivelamento de recursos e método da cadeia
crítica, segundo Mulcahy (2009).
5.3.1. Método do caminho crítico

Para Dismore; Cavalieri (2010), o objetivo é determinar o caminho mais longo no diagrama de rede e a data mais
cedo e mais tarde que uma atividade pode iniciar e a data mais cedo e mais tarde que ela pode terminar.
1) O caminho crítico é o caminho com a duração mais longa para percorrer um diagrama de rede e o mais
curto para terminar um projeto. Ele ajuda a comprovar o tempo do projeto, a determinar onde o gerente
de projetos deverá concentrar seus esforços, fornece um método eficaz para comprimir um cronograma e
para determinar quais atividades tem folga;
2) O caminho quase crítico é o caminho que tem a duração quase tão longa como a do caminho crítico e
quanto mais longos forem o caminho crítico e quase crítico maior é o risco do projeto (tempo, custos); e
3) A folga é o tempo que uma atividade pode atrasar sem atrasar o projeto e quase sempre as atividades do
caminho crítico tem folga zero e pode ser divido em três, a total (atividade atrasada sem atrasar o projeto
ou marco), livre (atividade atrasada sem atrasar o início mais cedo de sua sucessora) e do projeto (tempo
que o projeto pode atrasar sem atrasar a data imposta pelo cliente ou do projeto);
5.3.2. Compressão do cronograma

Esta técnica procura alternativas para reduzir o cronograma do projeto sem alterar o seu escopo, atuando nas
atividades do caminho crítico e ela pode ser utilizada da seguinte forma, segundo Mulcahy (2009):
1) Compressão (Crashing) – alocar mais recursos às atividades do caminho crítico ou executá-las em menor
tempo, por definição ela resulta em mais custos para o projeto; e
2) Paralelismo (Fast Tracking) – realizar atividades em paralelo que normalmente deveriam ser executa-
das em sequência, podendo resultar em retrabalho, aumento do risco e requer maior atenção com as
comunicações.
Leia mais sobre as técnicas de compressão do cronograma no seguinte blog. http://h12sse.blogspot.com.

br/2013/11/tecnicas-de-compressao-do-cronograma.html
5.3.3. Análise do tipo “e-se”

Para o Guia PMBOK (2017), você deverá fazer uma análise de um pergunta do tipo “E se a situação representada
pelo cenário X acontecer?”. Essa técnica pode ser utilizada para avaliar se o cronograma do projeto é praticável
sob condições adversas e para preparar planos de contingência e de resposta para superar ou mitigar o impacto
de situações inesperadas. Uma das formas de calcular o efeito das análises de cenário é por meio da análise de
Monte Carlo (lida com convergências e situações reais de um projeto).
5.3.4. Nivelamento de recursos

É elaborado um cronograma com os recursos limitados do projeto. O nivelamento permite alterar o cronograma e
aumentar os custos para lidar com uma quantidade limitada de recursos, segundo Mulcahy (2009).
Para Heldman (2009), o nivelamento de recursos pode causar alterações no caminho crítico.
5.3.5. Método da cadeia crítica

Esta técnica é outra forma de desenvolver um cronograma bem aceito, aprovado, realista e formal. Segundo
Mulcahy (2009), você deve criar um diagrama de rede, após o cronograma é desenvolvido atribuindo cada
atividade para ocorrer o mais tarde possível e, ainda assim, cumprir o cronograma. Com a adição dos recursos,
você irá inserir buffers (pulmões) de duração, na cadeia dos marcos críticos. Essas reservas ficam espalhadas
em todo o projeto para suprir riscos e possíveis atrasos.
Assista também ao vídeo a seguir para aprender mais um pouco sobre esse método. https://youtu.be/iv096JdBaS8
Gerenciamento do Tempo III
6.1. DESENVOLVIMENTO DO CRONOGRAMA DO PROJETO

É o resultado da análise de rede do cronograma e dos processos de planejamento anteriores. Com base no geren-
ciamento dos riscos e em outras partes do planejamento, o cronograma é iterado até que se defina um cronograma
aceitável e realista, tornando-se a linha de base do cronograma e parte do plano de gerenciamento do projeto,
segundo o Guia PMBOK (2017).
O cronograma pode ser mostrado com ou sem dependências e pode ser mostrado nas formas de diagrama de
rede, gráficos de marcos e gráfico de barros.
1) Gráficos de marcos, mostram apenas os eventos principais do projeto e são simplesmente o término de
marcos, a Figura 34 mostra um exemplo; e
FIGURA 34 – GRÁFICO DE MARCOS
Veja nesse pequeno artigo, como definir os marcos do projeto. http://www.elirodrigues.com/como-definir-mar-

cos-milestones-de-um-projeto/
2) Gráficos de barras (gráfico de gantt) são ferramentas de planejamento fracas, mas eficazes para relatórios
e controle do progresso, a Figura 35 mostra um exemplo.
FIGURA 35 – GRÁFICO DE BARRAS
Observe nesse artigo, como criar um gráfico de gantt em seis passos. http://pt.wikihow.com/Criar-um-Gr%-
C3%A1fico-de-Gantt
A dica é que um diagrama de redes é utilizado para mostrar as interdependências entre todas as atividades, o
gráfico de marcos é utilizado para fornecer relatórios à alta administração e um gráfico de barras é utilizado para
acompanhar o progresso e para fornecer relatório à equipe.
Seguindo Mulcahy (2009) a dica é que no grupo de processos de planejamento gerenciamento do tempo você
determina como você fará a parte do planejamento de todos os planos de gerenciamento, criar lista de atividades,
criar o diagrama de rede, estimar as necessidades de recursos, estimar o tempo e o custo, determinar todos os
papéis e responsabilidades, iterações, finalizar a parte de como executar e controlar de todos os planos e desen-
volver o plano final e uma linha de base para medição do desempenho realistas.
Por fim, o macro cronograma abaixo ilustra a visão de longo prazo da implantação do programa PDPJ-Br:
Gerenciamento dos Custos

O gerenciamento dos custos aborda as estimativas de custos para cada atividade definida dentro do geren-
ciamento do tempo, a fim de elaborar um orçamento realista para o projeto, bem como gerenciar e controlar
os gastos. Inclui todos os processos necessários para planejar, como concluir o projeto dentro do orçamento
aprovado, segundo o PMBOK (2017).
Também, Dismore; Cavalieri (2010) afirmam que o sucesso de um projeto depende em grande parte da habilidade
gerencial em controlar os custos, sendo assim o planejamento e o controle dos custos são fundamentais.
A Figura 36 apresenta o grupo de processos do gerenciamento dos custos.
FIGURA 36 – GRUPO DE PROCESSOS DO GERENCIAMENTO DOS CUSTOS
Para Mulcahy (2009), o gerenciamento do tempo discute a identificação de atividades como componentes menores
dos pacotes de trabalho, sendo elas utilizadas para criar as estimativas de custos em muitos projetos. Porém,
para alguns projetos maiores, pode ser mais prático estimar e controlar os custos em um nível diferente da EAP,
chamado de contas de controle. Os centros de custo são um nível superior dos pacotes de trabalho.
Ainda, o Plano de Gerenciamento de Custos é desenvolvido no processo desenvolver o plano de gerenciamento do

projeto no gerenciamento da integração. Um plano de custos inclui especificações de como as estimativas devem
ser informadas (moeda), nível de exatidão necessário das estimativas, formato dos relatórios, regras de medição
do desempenho dos custos, se os custos incluirão custos diretos (atribuíveis diretamente ao projeto) e custos
indiretos (não atribuíveis diretamente ao projeto, custos administrativos) e limites de controle (quantidades de
variações nos custos aceitáveis antes de se tomar uma providência).
O plano de gerenciamento dos custos do projeto é estabelecido utilizando a EAP e suas contas de controle asso-
ciadas, segundo Heldman (2009).
7.1. ESTIMAR CUSTOS

É o processo de tomar como base o planejamento de recursos feito anteriormente e as taxas associadas de
cada um dos recursos, calculando assim o custo previsto para cada pacote de trabalho. Além de identificar as
atividades que devem ser executadas para a entrega dos produtos do projeto. Para o PMBOK (2017), é o processo
de desenvolvimento de uma estimativa dos recursos monetários necessários para executar as atividades do
projeto (Figura 37).
FIGURA 37 – PROCESSO ESTIMAR OS CUSTOS
Estimar os custos é o processo onde são feitas as estimativas, de forma aproximada, dos custos de cada atividade.
Não é função deste processo ainda abranger todas as estimativas de um plano de despesas ou orçamento de
custos por período, isso você verificará no próximo processo, determinar orçamento.
Segundo Muto; Pereira(2008), uma boa definição do escopo logo de início é um componente essencial na
determinação eficiente dos custos estimados e deve ser concluída no projeto assim que possível porque é mais
fácil especificar os custos nas fases iniciais do projeto. Não é possível especificar custos se você não entender
o escopo do projeto.
Para Mulcahy (2009), você deverá saber que as estimativas devem se basear na EAP e elaboradas pela pessoa
que executará as atividades, buscando maior exatidão, informações históricas, é necessário manter uma linha
de base dos custos (somente alterada por mudanças aprovadas), as estimativas são mais exatas se compo-
nentes de trabalho menores forem estimados, o gerente de projetos nunca deve somente aceitar restrições da
administração e sim analisar as necessidades do projeto, produzir estimativas próprias e conciliar quaisquer
diferenças para produzir objetivos realistas, aumentar arbitrariamente as estimativas do projeto não é aceitável
para o gerenciamento do projeto, as estimativas devem ser revisadas durante o ciclo de vida do projeto para
manterem-se realistas e podem ser diminuídas diminuindo os riscos.
Os custos podem ser (MUTO; PEREIRA, 2008):
• Variáveis, diretamente relacionados ao volume produzido (mão-de-obra alocada, comissões, matéria-prima,

peças e componentes);
• Fixos, não variam segundo o rendimento ou volume produzido, seu valor unitário se torna menor a medida
que a produção aumenta (salários de pessoal administrativo, seguros, aluguéis e taxas);
• Diretos, diretamente relacionados com as atividades do projeto (viagens, salários, gratificações e material
usado no projeto); e
• Indiretos, não são apenas atribuíveis a um projeto específico, mas que estão distribuídos em muitos deles,
(serviços de apoio, aluguéis, impostos).
Dismore; Cavalieri (2010) afirmam que os custos podem ser estimados utilizando:
• Estimativas “bottom-up”, desenvolve estimativas para cada pacote de trabalho, o custo total do projeto
se dará pelo somatório das estimativas individuais realizadas. Para Mulcahy (2009), as vantagens são de
que é mais precisa, obtém apoio da equipe porque cria estimativas bem aceitas, baseada em uma análise
detalhada do projeto é base para monitoramento e controle, medição de desempenho e gerenciamento;
• Estimativa Análoga “top-down”, utiliza custos reais de projetos anteriores e similares para prever as
estimativas de custos do projeto atual. Para Mulcahy (2009), as vantagens são de ser rápidas, as ativi-
dades não precisam ser identificadas, menor custo para ser criada, o gerente tem uma ideia do nível de
expectativa da administração, os custos gerais do projeto terão um limite máximo; e
• Estimativa paramétrica, quantidade de trabalho dividido pela taxa de produtividade (ponto de função,
custo de construção por m²).
Para Mulcahy (2009), existem outros itens que auxiliam na criação de estimativas, tais como:
• Os software, auxilia a otimizar a estimativa das atividades;
• Ao determinar os valores de custo dos recursos, devem ser analisados os custos dos recursos humanos,
consultores, prestadores de serviços, fornecedores e processos licitatórios;
• A análise das reservas (contingência), deve ser utilizada para acomodar os riscos de custos e de
cronograma; e
• Os custos da qualidade, trabalho adicional ao projeto para incluir o planejamento da qualidade não
podem ser esquecidos.
A precisão das estimativas na parte inicial do projeto, um intervalo mais amplo é fornecido, com o tempo, a medida
que mais informações são levantadas durante o planejamento, o intervalo das estimativas diminuirá.
Para Mulcahy (2009), os intervalos de estimativas são:
• Estimativa por ordem de magnitude (OM), feito durante o processo de iniciação com intervalo de + ou –
50% do real, podendo variar dependo do conhecimento do projeto;
• Estimativa orçamentária, realizada durante a fase de planejamento com intervalo de -10 a +25% do real; e
• Estimativa definitiva, durante o projeto a estimativa será mais refinada, com intervalos de + ou – 10% ou,
dependendo do gerente de projetos, -5 a + 10% do real.
A dica aqui é a de que depois de elaboradas as estimativas dos custos de todas as atividades, bem como a base
dos cálculos para tais, você poderá ter de realizar mudanças ou atualizações nos riscos do projeto, além de outras
partes do plano de gerenciamento e nos documentos do projeto para reduzir custos.
Leia esse artigo que trata da importância da estimativa para o correto gerenciamento de custos de projetos. http://
www.techoje.com.br/site/techoje/categoria/detalhe_artigo/767
7.2. DETERMINAR ORÇAMENTO
Agrega as estimativas dos custos globais do projeto ao custo das atividades individuais dos pacotes de trabalho
com a finalidade de estabelecer uma linha base de custos para realizar a medição do desempenho do projeto,
segundo o PMBOK (2017), conforme Figura 38.
FIGURA 38 – PROCESSO DETERMINAR O ORÇAMENTO
Para Mulcahy (2009), o resultado deste processo é o orçamento total do projeto calculado para que a organização
possa deixar, em separado, os recursos necessários para sua realização.
Deste modo, a criação de um orçamento, os custos de cada atividade são reunidos nos custos do pacote de tra-
balho, que somados resultam nos valores das contas de controle e, por fim, nos custos do projeto. As reservas de
contingência são somadas para gerar a linha de base dos custos e na etapa final acrescentadas as reservas de
gerenciamento. As Figuras 39, 40 e 41 exemplificam formas de representar os custos em um projeto.
FIGURA 39 – VISÃO DOS CUSTOS POR FRENTE DE TRABALHO
FIGURA 40 – VISÃO DOS CUSTOS POR PACOTE DE TRABALHO E TIPO DE RECURSOS
FIGURA 41 – PLANILHA APOR PACOTE DE TRABALHO
Fonte: Programa de Apoio ao Desenvolvimento Sustentável da Zona da Mata de Pernambuco
A dica aqui é a de que a linha de base dos custos e o orçamento propostos somente serão finais após a conciliação
com quaisquer restrições de custos no termo de abertura do projeto.
A dica de Mulcahy (2009) é que no grupo de processos de planejamento gerenciamento dos custos você deter-
mina como fará a parte do planejamento de todos os planos de gerenciamento, bem como, estimar o tempo e o
custo, desenvolver o orçamento, determinar todos os papéis e responsabilidades, iterações, finalizar a parte de
como executar e controlar de todos os planos e desenvolver o plano final e uma linha de base para medição do
desempenho realistas.

MUTO, C. A.; PEREIRA, B. T. Exame PMP: a Bíblia : manual para certificação. 2ª Edição. ed. Rio de Janeiro: Brasport, 2008.
PROGRAMA DE APOIO AO DESENVOLVIMENTO SUSTENTÁVEL DA ZONA DA MATA DE PERNAMBUCO. Planilha Orçamentária

– Projeto básico reflorestamento.

É uma representação gráfica detalhada de todo e somente o trabalho necessário para

EAP
o atingir os objetivos do projeto.
É essencialmente a fragmentação de um item para promover compreensão da

Top-down composição de seus subitens. Numa abordagem de cima para baixo é formulada uma
visão geral do item, partindo de uma instância final para a inicial.
É a “colcha de retalhos” do item para dar rumo a itens mais complexos. Tornando assim,
Botton-up
a cada passo, os itens originais em subitens de um item maior.
É uma unidade de medida de software reconhecida pela ISO para estimar o tamanho
Ponto de função de um sistema de informação baseando-se na funcionalidade percebida pelo usuário
do sistema, independentemente da tecnologia usada para implementá-lo.
Uma sprint é uma reunião de pessoas envolvidas num projeto para promover um desen-
Sprints
volvimento mais focalizado do projeto. Sprints geralmente duram de uma a três semanas.
UIA 3 | GERENCIAMENTO DA
QUALIDADE, COMUNICAÇÃO E
RECURSOS HUMANOS DOS PROJETOS
Gerenciamento da Qualidade
Para o PMBOK (2017), qualidade é definida como “o grau no qual o projeto satisfaz seus requerimentos” e “grau é
atribuído produtos e serviços que atendem à mesma finalidade com características diferentes”.
Qualidade baixa é sempre um problema já o grau baixo não.
Já para Mulcahy (2009), a qualidade é definida como “o grau em que o projeto cumpre seus requisitos”.
O nível de qualidade explicita ou implícita devem ser alcançados não somente por força de concorrência de mer-
cado, mas também por imposições legais (VALERIANO, 2005).
Planejar a qualidade é um processo facilitador crucial executado durante o processo de planejamento visando o
cumprimento de padrões de qualidade relevantes, segundo Heldman (2009).
Assim a área de gerenciamento da qualidade aborda os processos e as atividades da organização executora que
determinam as políticas de qualidade, os objetivos e as responsabilidades de modo que o projeto satisfaça as
necessidades para as quais foi empreendido, segundo o PMBOK (2017).
A Figura 42 nos mostra os processos da área de gerenciamento da qualidade.
FIGURA 42 – GRUPO DE PROCESSOS DO GERENCIAMENTO DA QUALIDADE

Ainda para Mulcahy (2009), a definição de gerenciamento da qualidade inclui criar e seguir políticas e procedi-
mentos para garantir que um projeto atenda às necessidades definidas que deveria atender, do ponto de vista
do cliente.
Segundo Dismore; Cavalieri (2010):
• O gerente de projetos (GP) deve recomendar melhorias nos padrões, nas políticas e nos processos da orga-
nização executora, pois são esperadas pela alta administração;
• Sempre que houver mudanças em restrições do projeto a qualidade deve ser considerada;
• A qualidade deve ser verificada antes da conclusão de uma atividade ou pacote de trabalho;
• O GP deve dedicar tempo para melhorar a qualidade;
• O GP deve implementar um plano de melhoria contínua dos processos; e
• O GP deve assegurar que os processos autorizados sejam cumpridos.
Também, salienta Dismore; Cavalieri (2010), você deve conhecer:
• Trabalho supérfluo (gold plating), significa entregar funcionalidades não especificadas no escopo do
projeto, componentes com qualidade mais elevada ao cliente. Esse trabalho não deve ser realizado e é
responsabilidade do GP ficar atento para que isso não ocorra;
• Prevenção acima de inspeção, a qualidade deve ser planejada e não somente inspecionada;
• Análise marginal, procurar o ponto em que os benefícios ou a receita que serão recebidos com a melhoria
da qualidade se igualem ao custo incremental para alcançar tal qualidade e quando esse ponto é atingido,
se para de buscar melhorias na qualidade, pois não agrega valor;
• Sob demanda (Just in Time – JIT), quando a empresa solicita a matéria-prima somente quando neces-
sária, uma empresa que utiliza essa técnica possui um alto padrão de qualidade e isso reduz o estoque
a quase zero;
• Gerenciamento da qualidade total (GQT), estimula as empresas a sempre buscar formas de melhoria
contínua da qualidade nas práticas comerciais e dos produtos;
• Responsabilidade pela qualidade, o GP tem a responsabilidade final pela qualidade do produto, mas cada
membro da equipe deve verificar e inspecionar seu próprio trabalho. A alta administração tem responsa-
bilidade final pela qualidade na organização e cerca de 85% dos problemas de qualidade de um projeto
podem ser atribuídos ao ambiente gerencial e ao sistema gerencial no qual a equipe trabalha; e
• Impacto da má qualidade pode gerar, além da qualidade ruim, aumento dos custos, moral baixo, baixo
nível de satisfação do cliente, aumento dos riscos, retrabalho e atrasos no cronograma.
Assista ao vídeo do Ricardo Vargas que dá um panorama geral dobre o que é gerenciar qualidade de projeto.
https://www.youtube.com/watch?v=gs63l_zerag
8.1. PLANEJAR A QUALIDADE
É o processo que identifica e define os padrões de qualidade relevantes para o produto e para o projeto e determina
como satisfazê-lo e ainda, que critérios serão utilizados para avaliar sua conformidade, além da documentação
de como o projeto demonstrará a qualidade (MUTO; PEREIRA, 2008).
A Figura 43 apresenta os processos de planejar a qualidade, segundo o PMBOK (2017).
FIGURA 43 – PROCESSO PLANEJAR A QUALIDADE
Para Mulcahy (2009), o objetivo de utilizar as ferramentas e técnicas neste processo é o de determinar quais são
os requisitos e os padrões para o projeto e o produto.
As ferramentas e técnicas, segundo o PMBOK (2017) podem ser:
• Análise de custo-benefício, o GP pondera os benefícios com relação ao custo para atender aos requisitos
de qualidade;
• Custo da qualidade (CDQ), assegura que o projeto não esteja gastando demais para garantir a quali-
dade, por meio da análise de quais custos serão os custos da conformidade e da não conformidade
com a qualidade no projeto e criar um equilíbrio. O Quadro 1 mostra itens a serem levados em conta
para o cálculo de conformidade;
QUADRO 1 – CUSTOS DE CONFORMIDADE E NÃO CONFORMIDADE DA QUALIDADE
Custo da conformidade Custo da não conformidade
Treinamento sobre qualidade Retrabalho
Estudos Sucata
Pesquisas Custos de estoque
Esforços para assegurar que todos saibam Custos de garantia

quais processos usar para terminar seu trabalho
Fonte: Mulcahy, 2009
• Benchmarking, envolve analisar outros projetos visando obter ideias para melhoria do projeto atual e
fornecer uma base para usar na medição do desempenho da qualidade;
• Planejamento de experimentos (DOE-Design of Experiments), usa experimentação para determinar

estatisticamente quais variáveis melhorarão a qualidade, como por exemplo, as pessoas podem tentar
melhorar a qualidade analisando o efeito do uso de diferentes processos para desenvolvimento de
software sobre a qualidade geral, deixando todos os outros aspectos iguais;
• Amostragem estatística, consiste em coletar uma amostra estatisticamente válida, pois fazer testes
em todos os exemplares poderá levar muito tempo, custar mais e ser destrutivo demais. O tamanho e
a frequência das medições são determinados neste processo; e
• Elaboração de fluxogramas, mostra como o processo ou sistema flui do início ao fim e como os elementos
se inter-relacionam e utilizado para ver um processo e encontrar possíveis problemas de qualidade.
• Gráficos de controle – São definidos, para o PMBOK (2017), no processo planejar a qualidade como parte
do esforço para determinar o que será qualidade no projeto e utilizado para no processo para realizar
o controle da qualidade, onde ajudam a determinar se um processo está dentro dos limites aceitáveis.
As regras de medição do controle dos projetos são:
> Limites de controle superior e inferior, são o intervalo de variação aceitável de um processo, normal-
mente calculado com base em + ou – 3 sigma ou desvios padrão;
> Média, é indicada por uma linha no meio do gráfico de controle, mostrando o ponto médio do intervalo
de variação aceitável do processo;
> Limites de especificação, representam as expectativas do cliente ou os requisitos contratuais de

desempenho e qualidade no projeto e eles não são calculados com base no gráfico de controle e
sim entradas do cliente;
> Fora de controle, é quando um ponto de dados está fora do limite de controle superior e inferior ou
quando dados não aleatórios, mesmo dentro dos limites de controle superior e inferior, como na
regra dos sete;
> Regra dos sete, é uma regra geral ou heurística e refere-se a pontos de dados não aleatórios agrupados
em uma série que totaliza sete em um lado da média; e
> Variação com causa atribuível/causa especial, refere-se a um ponto de dados ou regra dos sete que
requer investigação para determinar a causa da variação.
Os resultados deste processo, segundo o PMBOK (2017), são:
• Plano de gerenciamento da qualidade, determina o que é qualidade e implementa um plano

para gerenciá-la (padrões, envolvidos, revisar decisões, reuniões, relatórios, métricas usadas, o que e
quando será medido)
• Métricas da qualidade, são a base para que o GP faça solicitações de mudanças no projeto
(nº de mudanças, de recursos usados, de itens reprovados na inspeção, de boas encontrados, varia-
ções de pesos...);
• Lista de verificação, lista de itens que devem ser inspecionados em um produto (Chico lista);
• Plano de melhoria de processos, ajuda a poupar tempo aumentando a eficiência e evitando problemas,
diminuindo gastos e aumentando a satisfação do cliente; e
• Atualizações no plano de gerenciamento e nos documentos do projeto, são necessárias essas atuali-
zações em todos os processos de gerenciamento de projetos.
A dica aqui é que qualidade é o grau no qual um conjunto de características inerentes satisfaz as necessidades.
E grau é uma categoria atribuída a produtos ou serviços que possuem o mesmo uso funcional, mas diferentes
características técnicas.
Muto; Pereira (2008) apresentam outras dicas: O gerente de projeto é o responsável final pela qualidade
do projeto.
Gerenciamento da Comunicação
Inclui os processos necessários para assegurar que as informações do projeto sejam geradas, coletadas, dis-
tribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada. O Gerente de projetos
gasta a maior parte do tempo se comunicando com os membros da equipe e outras partes interessadas,
quer sejam internas (em todos os níveis da organização) ou externas à organização, segundo o PMBOK (2017).
Uma estatística, segundo Muto; Pereira (2008): Ele gasta 90% do tempo com comunicação, 50% do tempo de
comunicação com a equipe de projeto (Requer comunicação clara, oportuna, eficaz e eficiente entre ao longo
da vida do projeto.) e 55% de todo este tempo de com comunicação não verbal. Esta área, portanto, tem
um elevado nível de importância, pois se torna imprescindível que as informações cheguem ao seu destino
(interessados) dentro das regras e necessidades requeridas.
A Figura 44 nos mostra o processo de gerenciamento das comunicações.
FIGURA 44 – GRUPO DE PROCESSOS DO GERENCIAMENTO DAS COMUNICAÇÕES
Para Heldman (2009), compreende a determinação das necessidades de comunicação das partes interessadas,
por meio da definição dos tipos de dados necessários e do formato em que serão transmitidos.
Para Mulcahy (2009), as comunicações se baseiam em gerenciar as partes interessadas por parte do gerente
de projetos e ele deve identificar todas elas (pois se forem identificadas posteriormente elas podem solicitar
mudanças e impactar negativamente no projeto), determinar todos os seus requisitos, determinar o seu nível
de influência, as suas expectativas e transformá-las em requisitos, quando e quanto elas serão envolvidas no
projeto, avaliar conhecimentos e habilidades, analisar o projeto para assegurar que as necessidades estão sendo
alcançadas, informar requisitos escolhidos e não escolhidos e o porquê, obter e manter envolvimento, influenciar,
usar como especialistas, utilizar, quando necessário no gerenciamento de mudanças, auxílio na elaboração das
lições aprendidas, obter aceitação formal do projeto ou fases, reavaliar envolvimento, gerenciar expectativas e
assegurar entendimento comum.
Ouça esse podcast do Ricardo Vargas que trata do conceito de um anteparo de comunicação: http://www.ricar-
do-vargas.com/pt/podcasts/do-you-know-what-is-a-communication-filter-or-noise/
9.1. IDENTIFICAR AS PARTES INTERESSADAS

Processo de identificar todas as pessoas ou organizações que possam vir a ser afetadas pelo projeto e de documen-
tar as informações relevantes e relacionadas aos seus interesses, envolvimento e impacto no sucesso do projeto
(Representado na Figura 45). As partes interessadas podem ser clientes, patrocinadores, a organização executora
e o público que estão de alguma forma, envolvidos no projeto, conforme o PMBOK (2017).
Também, as partes interessadas (Stakeholders) podem ter interesse positivo ou negativo no projeto, exercer influên-
cia sobre o projeto e suas entregas, estar em diversos níveis da organização e ter diferentes níveis de autoridade.
FIGURA 45 – PROCESSO DE IDENTIFICAR AS PARTES INTERESSADAS
Para Mulcahy (2009), a análise das partes interessadas envolve a identificação de todas as partes interessadas,
o gerente pode usar a lista inicial no termo de abertura do projeto, bem como contratos. Em seguida o Gerente
de Projeto analisa o impacto e a influência em potencial de cada parte interessada e podem ser classificadas por
grades de poder/interesse e modelos de saliência visando agrupar por qualificações, nível de autoridade, impacto
ou influência ou requisitos.
O registro das partes interessadas é onde todas as informações sobre as partes interessadas são compiladas,
podendo conter o nome, o cargo, o supervisor, a função no projeto, as informações de contato, os requisitos e as
expectativas, o impacto e a influência, a atitude perante o projeto, as classificações e outras informações relevantes.
A estratégia de gerenciamento das partes interessadas é desenvolvida pelo gerente de projetos que pode agrupar
partes interessadas ou gerenciar individualmente dependendo da necessidade do projeto.
Veja esse guia que ajuda a identificar os principais stakeholders do projeto. http://www.youwilldobetter.
com/2012/05/guia-para-identificar-os-stakeholders-do-seu-projeto/
9.2. PLANEJAR AS COMUNICAÇÕES

É o processo que determina as necessidades de informações das partes interessadas e de definir a abordagem de
comunicação, quem precisa de qual informação, quando será necessário disponibilizá-la, como será produzida e
por quem (Figura 46), conforme PMBOK (2017).
FIGURA 46 – PROCESSO DE PLANEJAR AS COMUNICAÇÕES
Assim, na visão de Muto; Pereira (2008), este processo resume em gerar as informações para os interessados
que sejam realmente necessárias, com uma mensagem clara e que atendam às suas precisões e expectativas.
Para isso o planejamento de comunicações deve ser iniciado o quanto antes.
Segundo o PMBOK (2017), os requisitos de comunicação da organização são, por exemplo, tecnologia de comunicação
específica disponível, mídia de comunicação permitida, política de retenção de registros e requisitos de segurança.
Para Mulcahy (2009), as informações do projeto que precisam ser comunicadas são: o termo de abertura do pro-
jeto, o plano de gerenciamento e documentos do projeto, impactos de outros projetos e em outros projetos, EAP,
quando os recursos são necessários, cronograma de reuniões, designações de trabalho, situação, novos riscos,
incertezas, problemas, sucesso, mudanças, atualizações, trabalho futuro, atrasos, datas de marcos, lições apren-
didas, desempenho, informações de contatos de todas as partes interessadas.
As comunicações ocorrem interna ou externamente à equipe principal do projeto e vertical (superiores e inferiores
da organização) e horizontalmente (entre colegas)
Segundo o PMBOK (2017) a atividade de comunicação tem muitas dimensões em potencial, incluindo:
• Interna (dentro do projeto) e externa (cliente, outros projetos, os meios de comunicação, o público);
• Formal (relatórios, memorandos, instruções) e informal (emails, discussões ad hoc);
• Vertical (nos níveis superiores e inferiores da organização) e horizontal (com colegas);
• Oficial (boletins informativos, relatório anual) e não oficial (comunicações confidenciais);
• Escrita e oral; e
• Verbal e não verbal (inflexões da voz, linguagem corporal).
A maioria das habilidades de comunicação são comuns ao gerenciamento geral e o gerenciamento do projeto.
Alguns exemplos PMBOK (2017):
• Ouvir ativamente e de modo eficaz;
• Perguntar, investigando ideias e situações para garantir um melhor entendimento;
• Educar a fim de aumentar o conhecimento da equipe para que ela seja mais eficaz;
• Levantar fatos para identificar ou confirmar as informações;
• Definir e administrar as expectativas;
• Persuadir uma pessoa ou empresa a executar uma ação;
• Negociar para conseguir acordos mutuamente aceitáveis entre as partes;
• Solucionar conflitos para evitar impactos negativos; e
• Resumir, recapitular e identificar as etapas seguintes.
Gerenciamento dos Recursos Humanos

Segundo o PMBOK (2017) o Gerenciamento dos Recursos Humanos aborda os processos que definem, organizam e
gerenciam a equipe do projeto sendo a equipe formada por pessoas com responsabilidades e papéis designados
para a conclusão do projeto. Na Figura 47 verificam-se os processos de Gerenciamento dos Recursos Humanos.
FIGURA 47 – GRUPO DE PROCESSOS DO GERENCIAMENTO DOS RECURSOS HUMANOS
Para Mulcahy (2009), é no gerenciamento dos recursos humanos que o gerente de projetos define os papéis
e responsabilidades dos membros da equipe, da administração e de outras partes interessadas dentro do
projeto. Para isso ele recorre à matriz de responsabilidades. Os papéis desempenhados pelas partes inte-
ressadas no projeto são:
• Patrocinador/iniciador do projeto, estabelece objetivos, prioridades e requisitos, aprova termo de abertura

e planejamentos e arbitra conflitos, identifica riscos, fornece opinião de especialista, obtém apoio;
• Equipe do projeto executam as atividades do projeto de acordo com o planejado, identifica requisitos, cria
EAP, estima tempo e custo, conduz melhoria nos processos;
• Partes interessadas, envolvidas na elaboração do temo de abertura, do plano do projeto, na aprovação

de mudanças, na identificação de requisitos e restrições, no gerenciamento dos riscos e podem se tornar
responsáveis pelas respostas aos riscos;
• Gerente funcional provê recursos e equilibra necessidades e prioridades de múltiplos projetos;
• Gerente de projetos faz o projeto acontecer conforme o planejado, coordena os trabalhos e propõe ações
corretivas para o alcance dos resultados previstos.
A responsabilidade do gerente de projetos sobre os recursos humanos pode ser ética, profissional e social e admi-
nistrativa. Os membros da sua equipe são seus subordinados diretos.
A dica de Mulcahy (2009) é a de que o gerente de projetos deve determinar a necessidade de recursos, negociar
os recursos ideais com o gerente funcional, criar lista da equipe e descrições de cargo, assegurar, claramente, os
papeis e responsabilidades e incluir relatórios de desempenho dos membros da equipe.
Leia as duas primeiras páginas desse artigo para ter uma visão geral sobre como gerenciar recursos humanos em
projetos. http://www.mundopm.com.br/download/artigo_demo_RH.pdf
10.1. DESENVOLVER O PLANO DE RECURSOS HUMANOS

É o processo de documentar e identificar papéis, responsabilidades, habilidades necessárias e relações hierárqui-
cas do projeto e criar um plano de gerenciamento de pessoal, de acordo com o PMBOK (2017). A Figura 48 ilustra o
funcionamento deste processo com suas Entradas, Ferramentas e Técnicas e Saídas.
O gerenciamento dos recursos humanos para Dismore; Cavalieri (2010) tem como objetivo principal possibilitar a
utilização mais efetiva das pessoas envolvidas no projeto.
FIGURA 48 – PROCESSO DE DESENVOLVER O PLANO DE RECURSOS HUMANOS
O gerenciamento dos recursos humanos para Dismore; Cavalieri (2010) tem como objetivo principal possibilitar a
utilização mais efetiva das pessoas envolvidas no projeto. Assim, o plano de recursos humanos determina onde
estão definidas as funções e responsabilidades necessárias para completar o projeto, bem como sobre o plane-
jamento e o monitoramento e controle.
Para este processo envolve os itens:
• Fatores ambientais da organização, verificar a cultura (quais empresas evolvidas, alguém que não deseja
o projeto, contrata terceirizados, disponibilidade para treinamento) e os sistemas existentes na empresa
com os quais o projeto lidará e ou poderá usar;
• Ativos de processos organizacionais, processos, procedimentos e informações históricas (modelos de pro-

jetos anteriores que possam ser utilizados);
• Organogramas e descrições de cargos, descrever todas as competências e funções que a equipe do projeto
pode exercer;
• Matriz de responsabilidades relaciona os membros da equipe às atividades ou pacotes de trabalho;
• Tabela RACI (responsável pela Execução, responsável pela Aprovação, é Consultado, é Informado), con-
forme ilustrado no Quadro 2;
QUADRO 2 – GRÁFICO RACI
Fonte: Muto; Pereira (2008)
Um exemplo prático de matriz de responsabilidades aplicada especificamente para a implantação do PJe nos TJs
está ilustrada logo abaixo:
QUADRO 3 – MATRIZ DE RESPONSABILIDADES DO CICLO DE VIDA DO PROJETO DE IMPLANTAÇÕES DO PJE
Fonte: Metodologia de Gerenciamento de Projetos de TI do CNJ
Mais outro exemplo prático de matriz de responsabilidades aplicada especificamente para gestão da operação
do PJe junto aos TJs está ilustrada logo abaixo:
QUADRO 4 – MATRIZ DE RESPONSABILIDADES DA OPERAÇÃO DAS IMPLANTAÇÕES DO PJE
• Estrutura analítica organizacional, mostra as responsabilidades por departamento (Figura 49);
• Estrutura analítica de recursos, divide o trabalho por tipo de recurso (Figura 49); e
• Descrições de cargos, normalmente feitas em formato de texto (Figura 49).
FIGURA 49 – ESTRUTURAS DE DEFINIÇÃO DE RECURSOS
Fonte: Muto; Pereira (2008)
A título ilustrativo, demonstra-se abaixo os papéis dos recursos humanos envolvidos nos projeto do CNJ, que são
adequados aos projetos do PJe, principalmente por correlacionarem com o modelo ágil.
QUADRO 5 – PAPÉIS DA METODOLOGIA DE GERENCIAMENTO DE PROJETOS DO DTI CNJ
Para Mulcahy (2009), o resultado deste processo é o Plano de recursos humanos que informa quando e como os
membros da equipe serão incluídos, gerenciados, controlados e liberados do projeto. Ele inclui papéis e responsa-
bilidades, organogramas do projeto e plano de gerenciamento do pessoal.
O Plano de Gerenciamento de Pessoal inclui o plano de mobilização, calendário, plano de liberação de recursos,
bem como necessidades de treinamento, reconhecimento e recompensas, conformidade de cumprimento do plano
e segurança do pessoal.
Os sistemas de reconhecimento e recompensas incluem dizer obrigado, conceder prêmios, recomendar mem-
bros para trabalhos ou aumentos preferenciais, enviar cartas de recomendação aos seus gerentes funcionais,
planejar festas, pagar treinamento com o orçamento do projeto, designar recursos para outras atividades a
fim de desenvolver competências.
O gerente de projeto de lançar mão do histograma de recursos (gráfico de barras) que explicita o número de recursos
utilizados no período e onde há um pico na necessidade de recursos.
O diagrama de processos de Mulcahy (2009) nos traz a dica de que no grupo de processos de planejamento você
determina como você fará a parte do planejamento de todos os planos de gerenciamento, determina a equipe,
determina todos os papéis e responsabilidades, iterações, finaliza a parte de como executar e controlar de todos
os planos e desenvolver o plano final e uma linha de base para medição do desempenho realista.
Diante deste processo, é importante destacar o modelo de governança da PDPJ-Br, baseada em uma Rede de
Governança constituída por:
I – Comissão Permanente de Tecnologia da Informação e Infraestrutura do CNJ;
II – Comitê Gestor Nacional da PDPJ;
III – Comitês Gestores dos Tribunais;
IV – Gerência Executiva da PDPJ; e
V – Grupos de Trabalho.
Comitê Gestor Nacional:
I – propor à Presidência, mediante sugestão da Gerência Executiva, a política de tecnologia da informação a

ser seguida pela PDPJ-Br;
II – homologar e propor ajustes aos projetos de desenvolvimento de microsserviços sugeridos pela Gerência
Executiva e pelos Comitês Gestores dos tribunais de forma a conciliar e integrar as necessidades dos diversos seg-
mentos do Poder Judiciário e dos usuários externos, com o auxílio da Gerência Executiva e seus Grupos instituídos;
III – ratificar as decisões tomadas pela Gerência Executiva e seus grupos instituídos;
IV – propor normas regulamentadoras à Comissão Permanente de Tecnologia da Informação e Infraestrutura do CNJ;
V – sugerir à Presidência o modelo de rateio dos custos da nuvem computacional e, após aprovado,
acompanhar sua execução; e
VI – deliberar sobre questões autorizadas pela Presidência e realizar outras ações para o cumprimento do
seu objetivo.
Comitês Gestores Dos Tribunais:
I – avaliar as necessidades de evolução e correção dos microsserviços e módulos da PDPJ-Br;
II – propor a organização da estrutura de atendimento às demandas de seus usuários internos e externos,

que será responsável pelo atendimento de primeiro e segundo níveis;
III – divulgar as ações da PDPJ-Br no âmbito da respectiva jurisdição;
IV – apresentar ao Comitê Gestor Nacional a proposta de plano de ação para a implantação da PDPJ-Br no tribunal;
V – acompanhar a execução do plano de ação, avaliando se as atividades desenvolvidas estão adequadas

e em consonância com o planejamento aprovado; e
VI – monitorar e avaliar periodicamente os resultados do plano de implementação, com vistas a melhorar a

sua qualidade, eficiência e eficácia, bem como aprimorar a execução e corrigir eventuais falhas identificadas.
Gerência Executiva:
§ 1º Caberá à Gerência Executiva da PDPJ-Br e ao Departamento de Tecnologia da Informação e Comunicação do

CNJ a orquestração das atividades colaborativas de desenvolvimento, sustentação e evolução dos módulos
e serviços disponibilizados na Plataforma.
§ 2º Será responsabilidade da Gerência Executiva subsidiar, promover e acompanhar a definição de tribunais

e/ou órgão que ficarão responsáveis pelo desenvolvimento de cada módulo e serviço estabelecido pelo Comitê
Gestor Nacional.
§ 3º Para cada projeto de desenvolvimento será designado pelo DTI um líder técnico para atuar como facilitador
e supervisor das atividades realizadas e artefatos a serem entregues, para garantia de compatibilidade com
os padrões e normativos da PDPJ-Br.
§ 4º Para cada projeto também será designado pelo Departamento de Tecnologia da Informação e Comunicação
um gerente de projetos, que será responsável pelo acompanhamento do cronograma estabelecido e pela atua-
lização de informações sobre o andamento e comunicação de eventuais impedimentos à Gerência Executiva.
Grupos Nacionais:
I – Grupo Nacional de Gerenciamento, Desenvolvimento e Sustentação, presidido pelo Diretor de Divisão do PJe; e
II – Grupo Nacional de Requisitos de Negócio, presidido por Juiz Auxiliar da Presidência.

DISMORE, Paul Campbell; CAVALIERI, Adriane. Como se Tornar um Profissional em Gerenciamento de Projetos. 3ª
Edição. Rio de Janeiro. Qualitymark Editora Ltda. 2010.
VALERIANO, D. L. Moderno Gerenciamento de Projetos. São Paulo: Prentice Hall, 2005.

É uma representação gráfica detalhada de todo e somente o trabalho necessário

EAP
para atingir os objetivos do projeto.
É o processo de verificação de lotes ou amostras a fim de determinar se a qualidade

Inspeção
do produto atende às especificações
A prevenção de defeitos em produtos que enfatiza que qualidade deve ser construída
Prevenção
no produto e não meramente verificada depois que o produto foi feito
Indivíduos ou organizações que estão envolvidos diretamente com o projeto ou são

Stakeholders
afetados positiva ou negativamente com sua execução ou resultados.
UIA 4 | GERENCIAMENTO DAS
AQUISIÇÕES E RISCOS DOS PROJETOS
Gerenciamento das Aquisições
O gerenciamento das aquisições inclui os processos necessários para comprar ou adquirir produtos, serviços ou
resultados externos à equipe do projeto (Figura 50) e abrange processos de gerenciamento de contratos e controle
de mudanças que são necessários para desenvolver e administrar contratos ou pedidos de compra imitidos por
membros autorizados da equipe, segundo o PMBOK (2017).
Para Dismore; Cavalieri (2010), as aquisições devem ser um “projeto” por si só e, portanto, devem ser gerenciadas
e controladas como tal, mesmo as de pequeno porte.
FIGURA 50 – GRUPO DE PROCESSOS DO GERENCIAMENTO DAS AQUISIÇÕES
Para Mulcahy (2009), com o gerenciamento das aquisições é um processo formal pelo qual muitas organizações
obtêm produtos e serviços. Ela lista alguns conceitos que você deve conhecer:
• Compradores e fornecedores, a pessoa que presta serviços ou fornece produtos são fornecedores e a
empresa ou pessoa que compra um serviço é chamada de compradora; e
• Contratação centralizada/descentralizada, a centralizada é quando existe um departamento de aqui-

sições e um gerente de aquisições responsável pelas aquisições na empresa, já na descentralizada um
gerente de aquisições é designado para um projeto em tempo integral e está subordinado ao gerente
de projetos.
Para Mulcahy (2009), o papel do gerente de projetos em aquisições é conhecer o processo para saber o que vai
acontecer e quando, entender termos e condições do contrato e se contém os requisitos de gerenciamento de
projetos, identificar e incorporar riscos ao contrato bem como formas de mitigá-los, adaptar o contrato ao projeto,
encaixar o cronograma de aquisições no do projeto, se envolver nas negociações visando bom relacionamento
com o fornecedor, proteger e integridade do projeto, ajudar a garantir que todo o trabalho previsto no contrato
seja entregue, não solicitar algo que não esteja no contrato sem realizar o processo de mudanças e trabalhar
com o gerente de aquisições para administrar as mudanças do contrato.
11.1. PLANEJAR AS AQUISIÇÕES

É o processo de documentação das decisões de compras do projeto (Figura 51), especificando a abordagem e iden-
tificando fornecedores em potencial. Identifica também que necessidades do projeto podem ser satisfeitas pelo
uso de produtos externos (inclui decidir se adquirir, como, o que, quanto e quando adquirir), para o PMBOK (2017).
FIGURA 51 – PROCESSO DE PLANEJAR AS AQUISIÇÕES
Para Mulcahy (2009), este processo responde a questões de “quais produtos e serviços você precisa adquirir para
o projeto, como você os comprará e quais fornecedores potenciais você usará?”.
Na mesma linha, Heldman (2009) afirma que este processo inclui identificar quais bem ou serviços comprar fora
da organização e quais necessidades a equipe do projeto precisa atender.
As atividades deste processo incluem:
• Análise de fazer ou comprar – São considerados os custos no gerenciamento das aquisições, juntamente
com os custos diretos do produto ou serviço a ser adquirido. Um dos motivos para comprar é reduzir risco
das restrições do projeto e é melhor fazer se você tem a fábrica ou força de trabalho ociosa, deseja manter
o controle e se envolve informações ou procedimentos prioritários, segundo Heldman (2009).
Lei o artigo citado para entender mais sobre essa análise tão importante para o planejamento da aquisição.
https://universoprojeto.wordpress.com/2013/09/23/analise-de-fazer-ou-comprar/
• Plano de gerenciamento de aquisições – Descreve como o processo de aquisições será planejado, execu-
tado e controlado.
• Declaração do trabalho da aquisição – O gerente de projetos deve definir o escopo do trabalho a ser reali-
zado, por meio da divisão da linha de base do escopo do projeto no trabalho no trabalho que a equipe do
projeto realizará e no trabalho que será adquirido do fornecedor. Essa declaração deve ser clara, completa
e concisa, além de descrever todo o trabalho e todas as atividades que o fornecedor deverá completar.
Existem alguns tipos de declaração:
> Desempenho determina o que o produto final deverá fazer, em vez de descrever como deve ser
construído ou quais devem ser suas características de design (quero um carro que vá de zero a
cem em 4 segundos);
> Funcional determina a finalidade ou resultado final e deve ser usada na execução do trabalho e inclui
uma declaração das características mínimas do produto (quero um carro com 10 porta copos); e
> Design determina precisamente qual trabalho deve ser realizado (construir exatamente o que consta
nesses desenhos).
• Tipos de contrato – Segundo Muto; Pereira (2008) existem três categorias, o de preço fixo (PF), tempo e
material (T&M) e custos reembolsáveis (CR), detalhados abaixo:
> Preço Fixo (PF) – usado para adquirir produtos ou serviços com especificações ou requisitos bem defini-
dos e quando há concorrência suficiente para se determinar um preço justo e razoável antes do início
do trabalho. Neste tipo de contrato o fornecedor aceita o alto nível de risco, o comprador paga mais,
tendo em conta o acréscimo de reservas para riscos e a declaração do trabalho deve ser completa
para que o fornecedor não deixe de fazer algo do escopo;
» Preço Fixo com Remuneração de Incentivo (PFRI) – para cada mês de antecipação do término do
projeto, adicionais são pagos ao fornecedor;
» Preço Fixo com Remuneração Concedida (PFRC) – para cada mês em que o desempenho exceder
o nível planejado de 15%, um valor de R$ 10.000 adicionais serão concedidos ao fornecedor, com
uma concessão máxima de R$ 90.000,00 (essa é a diferença para o PFRI, um limite de concessão);
» Preço fixo com Ajuste Econômico de Preço (PFAEP) – contrato de R$ 100.000, mas um aumento pode
ser permitido no segundo ano com base no índice de preços ao consumidor referente ao primeiro ano;
» Ordem de compra – contrato elaborado para comprar um determinado equipamento, é unilateral

apenas com a assinatura do comprador;
> Contrato por tempo e material (T&M) – contrato de R$ 100 por hora mais R$ 10 por metro linear
de madeira;
> Contrato de Custos reembolsáveis (CR) – usado quando o escopo do trabalho é incerto, portanto os
custos não podem ser estimados com precisão, permitindo ao comprador pagar ao fornecedor custos
incorridos admissíveis;
» Contrato de custos – o valor do contrato de CR é igual ao custo, não há lucro;
» Custo Mais Remuneração (CMR) ou custo mais percentual de custo (CMPC) – este tipo de CR é
quando o valor do contrato é igual ao custo gasto mais 10% dos custos como remuneração;
» Custo Mais Remuneração Fixa (CMRF) – este tipo de CR é quando o valor do contrato é igual ao
custo gasto mais uma remuneração de R$ 200.00;
» Custo Mais Remuneração de Incentivo (CMRI) – o fornecedor é pago pelos custos reais mais uma
remuneração que será ajustada se os objetivos de desempenho específicos declarados no contrato
forem cumpridos. A proporção é de 80% para o fornecedor e 20% para o comprador; e
» Custo Mais Remuneração Concedida (CMRC) – o custo mais uma remuneração de R$ 4.000 em cada
mês que uma produção exceder 20.000 unidades, com prêmio máximo de R$ 50.000.
Os incentivos se destinam a motivar os esforços do fornecedor em relação a itens que talvez não fossem enfati-
zados de outra maneira e visa desestimular a ineficiência e o desperdício do fornecedor.
Os pagamentos são realizados conforme está determinado nos contratos, conforme o trabalho vai sendo incorrido,
o cronograma de pagamentos, dentre outros.
Quem assume os riscos dependendo do tipo de contrato, para os CR é o comprador, pois se os custos aumentarem
o comprador paga os custos, já no contrato de PF quem assume o fornecedor, pois se os custos aumentarem o
fornecedor paga os custos e lucra menos
Segundo Mulcahy (2009), existem outros termos que se deve conhecer:
• Preço – quantia que o fornecedor cobra do comprador.
• Lucro (remuneração) – preço que o fornecedor apresenta para o comprador com uma margem aceitável
de lucro.
• Custo – quanto custa para o fornecedor criar, desenvolver ou comprar um item;.
• Preço-alvo – compara o resultado final com o que era esperado (o preço-alvo), sendo este a medida
do sucesso.
• Proporção de compartilhamento – são incentivos como por exemplo 80 (comprador)/20 (fornecedor).
• Preço-teto – o preço mais alto que o comprador pagará.
• Ponto de Premissa Total (PPT) – aplicada em contratos de preço fixo com remuneração de incentivo e
refere-se à quantia ao qual o fornecedor assume toda a perda de um estouro de custos a fórmula é PPT
= ((Preço-teto – Preço-alvo)/Proporção de compartilhamento do comprador) + Custo-alvo.
• Documentos de aquisição – Quando o tipo de contrato estiver escolhido e a declaração do trabalho da

aquisição estiver criada, o comprador pode elaborar os documentos de aquisição:
> Solicitação de proposta ou de oferta (SDP), proposta detalhada de como o trabalho será realizado,
quem fará os currículos, experiência da empresa, preço, dentre outros, utilizada em contratos de CR e
declaração do trabalho de desempenho ou funcional;
> Convite para licitação (CONV) solicita um preço total para realizar o trabalho, utilizado em contratos de
PF e a declaração do trabalho da aquisição é de design; e
> Solicitação de cotação (SDC) solicita cotação de preço por item, hora, metro ou outra unidade de medida,
utilizada em contratos de T&M e pode ser utilizada qualquer uma das declarações.
• Critérios de seleção – São as bases pelas quais o comprador avalia as ofertas ou propostas, esses critérios
podem ser experiência na área, entendimento da necessidade, capacidade técnica, qualidade do desem-
penho anterior, capacidade de terminar no prazo e em gerenciamento de projetos.
• Acordo de confidencialidade – É um acordo entre o comprador e o fornecedor para não divulgar alguma
informação, caso uma das partes não queira que seja divulgada e se for violado podem ocorrer conse-
quências previstas em contrato.
• Acordo de parceria (Joint Venture) – Quando dois fornecedores que possuem mais chances de conseguir
o trabalho de um comprador unem forças, assinando um acordo de parceria.
• Contrato padrão – Utilizado em aquisições semelhantes pelo comprador.
• Cláusulas especiais – É quando o gerente de projetos se reúne com o de aquisições para inserir necessida-
des do projeto e determinar os termos e condições do contrato final e pode ser resultado de uma análise
de riscos, requisitos, tipo de projeto e requisitos administrativos, legais ou empresariais.
• Termos e condições – A seguir algumas categorias que podem constituir cláusulas padrão e especiais:
> Aceitação, caracteriza (descreve explicitamente) como o trabalho será aceitável;
> Agente – Representante autorizado de cada uma das partes;
> Arbitragem – Terceiro(s) “particulare(s)” indicado(s) para tomar decisão de disputa;
> Cessão – Circunstâncias em que uma parte pode ceder a terceiros seus direitos ou obrigações estipu-
lados em um contrato;
> Autoridade – Caracteriza quem tem o poder de fazer o que;
> Fianças – Item que protege o comprador contra reivindicações do fornecedor por falta de pagamento;
> Quebra de contrato/inadimplência – Salienta quando qualquer obrigação do contrato não é cumprida,
geralmente é realizada por meio de uma carta formal;
> Mudanças – Descreve como serão feitas, formato usado, prazos para notificação e execução;
> Confidencialidade – Expõe o que não deve ser divulgado;
> Resolução de disputas – Descreve como será resolvida e quem a resolve (árbitro ou tribunal);
> Força maior, um caso fortuito, incêndios, desastres, dentro outros;
> Incentivos – São os benefícios ao fornecedor caso este esteja alinhado aos objetivos do projeto;
> Indenização – Esclarece quem será responsável por lesões corporais, danos e acidentes;
> Empreiteiro independente – Quando o fornecedor não é empregado do comprador;
> Inspeção – Assinala terá pode para inspecionar o trabalho durante a execução do projeto e em
quais circunstâncias;
> Propriedade intelectual – Aponta quem detém patente, marcas, direitos autorais, dentre outros,
podendo incluir determinadas propriedades intelectuais no cumprimento do contrato;
> Faturamento – Descreve quais documentos de apoio, para quem e quando devem ser produzidos;
> Multas contratuais – Item que estima os casos de inadimplências específicas. Devem ser descritas
com antecedência;
> Requisitos de gerenciamento – Inclui os comparecimentos às reuniões, aprovação de pessoal desig-

nado ao projeto, dentre outros;
> Inadimplência substancial – Abarca os casos de quebra de contrato tão relevante que pode não ser
mais possível continuar o contrato;
> Notificações – Assinala para quem enviar;
> Propriedade – Lista quem possuirá os itens tangíveis usados em associação ou desenvolvidos
no contrato;
> Pagamentos – Descreve quando, as multas de atrasos, motivos para falta de pagamento;
> Declaração do trabalho da aquisição – Se não for um documento separado, ela pode estar inclusa
no contrato;
> Relatórios – Descreve quais, a freqüência e de quem para quem;
> Retenção – Item que esclarece a quantia retida a cada pagamento e realizada ao final do contrato;
> Risco de prejuízo – Nomeia a alocação de riscos às partes do contrato caso produtos sejam perdidos;
> Acesso ao local – Item que descreve os requisitos de acesso;
> Rescisão – Apresenta os itens para o caso de interrupção do contrato antes do término;
> Prazo essencial – Representa as datas de entrega e são obrigações rigorosas, portanto, qualquer
atraso é uma inadimplência substancial do contrato;
> Renúncias – São declarações de que os direitos definidos no contrato só podem ser renunciados ou
modificados por acordo expresso entre as partes;
> Garantias – Promessas de qualidade para produtos ou serviços em termos contratuais e em uma
linha de tempo restrita; e
> Trabalho feito sob encomenda – Trabalhos fornecidos no contrato que serão de propriedade do
comprador.
• Carta de intenções – Pelo fato de negociações do contrato, termos e assinatura pode levar tempo, o for-
necedor pode solicitar uma carta de intenções junto ao comprador, pois deve levar tempo para contratar
recursos para a execução do contrato. Esta carta não é um contrato, não tem uma obrigação legal, apenas
uma garantia para o fornecedor assumir o risco.
• Participação de direitos – Significa uma relação contratual, é quando a empresa A contrata a empresa
B para fazer um trabalho e a empresa B contrata a C para executar o trabalho, caso a empresa A queira
alterar algo na execução ela deve conversar com a empresa B, pois a relação contratual é com ela.
• Formas de aquisição sem concorrência – Você pode conceder contrato sem concorrência caso o cronograma
esteja muito apertado, fornecedor com qualificações exclusivas ou existe somente um fornecedor ou um
fornecedor tem a patente do item necessário. Esse tipo de aquisição pode ser:
> Fonte única, você negocia o contrato diretamente com seu fornecedor preferencial, sem realizar o pro-
cesso de aquisições (pode ser uma empresa que você já trabalhou e gostou do resultado); e
> Fonte exclusiva, quando existe apenas um fornecedor, pode ser uma empresa que possui a patente.
Considerando que temos uma lei específica que rege os procedimentos de aquisições no Brasil, leia o artigo que
trata de um estudo comparativo entre o processo de aquisições do PMBOK® e a lei 8.666.
http://www.ipog.edu.br/uploads/arquivos/a75b8cbce012bc090ce64d143c0dfcdb.pdf
Gerenciamento dos Riscos I
O que é risco?
Risco segundo Muto; Pereira (2008) é o evento ou condição incerta, presente em todos os projetos, que ao ocorrer
poderá impactar positivamente ou negativamente o projeto, afetando pelo menos um objetivo do projeto, como
tempo, custo, qualidade, escopo, etc.
O risco do projeto é sempre futuro. O risco do projeto tem origem na incerteza existente em todos os projetos.
Um risco pode ter uma ou mais causas e, se ocorrer, pode ter um ou mais impactos.
O gerenciamento de risco envolve a tomada de decisões em um ambiente incerto, complexo e dinâmico. E tem como
meta identificar as potenciais forças e riscos do projeto.
Caberá à equipe de gerenciamento de projeto identificar as potenciais forças e riscos do projeto e assim, poten-
cializar o impacto dos eventos positivos e minimizar ou anular a probabilidade e o impacto dos eventos adversos
aos objetivos do projeto.
O gerenciamento dos riscos aborda os processos de planejamento, identificação, análise, planejamento de res-
postas e monitoramento e controle dos riscos, visando aumentar a probabilidade e o impacto dos eventos de
riscos positivos e reduzir a probabilidade e o impacto dos eventos negativos do projeto, segundo o PMBOK (2008).
A Figura 52 ilustra o grupo de processos do Gerenciamento dos Riscos em um projeto.
FIGURA 52 – GRUPO DE PROCESSOS DO GERENCIAMENTO DOS RISCOS
Para Mulcahy (2009), com o gerenciamento dos riscos, o projeto deixa de controlar o gerente de projetos e o gerente
de projetos é quem controla o projeto.
Também, Dismore; Cavalieri (2010), afirmam que um risco é qualquer incerteza ou condição em potencial que, se
concretizado, pode afetar negativamente ou positivamente um objetivo do projeto. Eles listam alguns conceitos:
• Ameaças e oportunidades, risco é um evento identificado antecipadamente e pode ou não acontecer,

podendo ter impacto positivo ou negativo. As ameaças são eventos que podem ter impacto negativo no
projeto, já as oportunidades são eventos que, caso ocorram, causam impactos positivos no projeto;
• Incerteza é uma falta de conhecimento sobre um evento, o que causa redução na confiança das conclusões
tiradas baseadas nos dados disponíveis;
• Fatores de risco são a probabilidade de ocorrência (o quê), intervalo de resultados possíveis (impacto ou
valor em jogo), momento esperado (quando) e com que frequência prevista de riscos da mesma origem;
• Avesso a riscos uma pessoa que não quer correr riscos; e
• Tolerâncias e limites para riscos são as áreas de riscos aceitáveis e pode incluir restrições do projeto (escopo,
tempo, custos...), bem como reputação e fatores intangíveis do cliente.
Nesta animação, podemos ver vários temas da Gestão de Projetos como Gestão de Riscos.
https://www.youtube.com/watch?v=O2M8Ou35GKQ
12.1 PLANEJAR O GERENCIAMENTO DOS RISCOS
Para o PMBOK (2017) é o processo de definição de como conduzir as atividades de gerenciamento dos riscos
(Figura 53), um planejamento cuidadoso e explícito aumenta a probabilidade de sucesso para os outros
cinco processos.
FIGURA 53 – PROCESSO DE PLANEJAR O GERENCIAMENTO DOS RISCOS
Para Mulcahy (2009), este processo responde a questões de quanto tempo deve ser dedicado ao gerenciamento
de riscos, baseado nas necessidades do projeto, quem estará envolvido, como o gerenciamento será realizado, os
procedimentos da empresa e matrizes de probabilidade e impacto padrão.
O Plano de Gerenciamento de Riscos descreve como os riscos serão gerenciados ao longo da vida do projeto e
estabelece um orçamento para isto, Dismore; Cavalieri (2010).
Ainda, o resultado ao terminar este processo você deve ter os seguintes itens, segundo o PMBOK (2017):
• Plano de gerenciamento de riscos, que inclui uma metodologia (define como você realizará o gerencia-
mento dos riscos);
• Papéis e responsabilidades, quem fará o quê (pessoas fora da equipe podem ter responsabilidades
nos riscos);
• Orçamentação inclui o custo dos processos de riscos (você deve saber que gerenciamento de riscos
economiza tempo e custos);
• Momento, quando realizar o gerenciamento dos riscos (assim que você tiver as entradas apropriadas você deve
iniciar e repetir ao longo de todo o projeto a fim de identificar novos riscos ou o grau de riscos pode mudar);
• Categorias de riscos;
• Definições de probabilidade e impacto, padronizar as avaliações de um risco, pois uma pessoa pode achar
que 7 é alto e outra não ao avaliar um risco;
• Tolerâncias das partes interessadas devem ser descobertas na iniciação do projeto e esclarecidas ou
refinadas continuamente;
• Formatos de relatórios, quais relatórios serão usados e o que incluirão; e
• Acompanhamento significa como o processo de riscos será auditado e o que ocorre no processo.
12.1.1. Categorias de riscos

Para Dismore; Cavalieri (2010), listas de amplas áreas ou fontes de riscos comuns enfrentados pela empresa ou
em projetos semelhantes. Existem formas de classificar ou categorizar os riscos:
• Externos, regulatórios, ambientais, governamentais, mudanças de mercados;
• Internos, inexperiência, tempo, custo, pessoas, materiais, equipamentos, planejamento inadequado;
• Técnicos, mudanças tecnológicas; e
• Imprevisíveis, pequena parte dos riscos cerca de 10%.
Existem categorias de riscos específicas, que podem ser geradas:
• Pelo cliente;
• Por falta esforços ou conhecimento em gerenciamento de projetos;
• Pelos clientes do cliente;
• Pelos fornecedores;
• Por resistência a mudanças; e
• Por diferenças culturais.
Uma maneira de categorizar os riscos é por sua origem:
• Cronograma, equipamento chegue antes e um pacote de trabalho iniciar cinco dias antes;
• Custo, talvez o equipamento chegue depois do planejado e seja necessário prorrogar o aluguel com custo
de R$ 50.000,00;
• Qualidade, o concreto pode secar antes do previsto e os pacotes de trabalho sucessores podem iniciar
antes do planejado;
• Escopo, o escopo não foi definido corretamente, caso seja verdade, será necessário acrescentar pacotes
de trabalho ao custo de R$ 35.000,00;
• Recursos, uma pessoa importante do projeto poderá sair, caso isso ocorra, o cronograma atrasará entre
5 e 10 dias úteis; e
• Satisfação do cliente ou das partes interessadas, o cliente pode não estar satisfeito com as entregas ABC,
provocando aumento de tempo de 15% de retrabalho.
A dica aqui é a de que as categorias ou fontes de riscos podem ser organizadas em um organograma no formato
de uma EAP, gerando a estrutura analítica dos riscos.
Além dessas categorias riscos descritas anteriormente podem existir os tipos de riscos, segundo Muto; Pereira (2008):
• Negócio/Business – Possibilidade de lucro ou prejuízo; e
• Puros/Pure ou seguráveis – Existe somente a possibilidade de perda (fogo, furtos, catástrofe natural etc.)
E ainda há três grandes categorias de riscos, relacionadas a conhecimento e existência:
• Conhecidos/Conhecidos – Known/Known – Sabemos que existem e conhecemos. Trazem a informação

completa nos levando à certeza em relação a eles, ou seja, são aqueles que foram identificados e anali-
sados, possibilitando o planejamento de respostas.
• Conhecidos/Desconhecidos – Known/Unknown – Sabemos que existem e não os conhecemos. Trazem a

informação incompleta e nos levam à incerteza moderada em relação a eles. A gerência de projetos atua
predominantemente nessa categoria de riscos.
• Desconhecidos/Desconhecidos – Umknown/Unknown – Não sabemos que existem e, logicamente, não

os conhecemos. São o fruto da total falta de conhecimento, não trazem informação alguma e nos levam
à incerteza absoluta em relação a eles.
12.2. IDENTIFICAR OS RISCOS

É o processo que envolve a determinação de quais riscos podem afetar e da documentação de suas características,
segundo o PMBOK (2017). A Figura 54 descreve este processo.
FIGURA 54 – PROCESSO DE IDENTIFICAR OS RISCOS
Para Mulcahy (2009), este processo envolve todas as partes interessadas, pois cada um tem uma perspectiva
diferente do projeto e pode apresentar suas ideias sobre as oportunidades e ameaças. Também, a principal parte
da identificação dos riscos ocorre na parte inicial do projeto e um número menor ocorre posteriormente.
Identificar os riscos é um processo iterativo porque novos riscos podem surgir ou se tornar conhecidos durante
o ciclo de vida do projeto, assim os riscos devem ser reavaliados continuamente, principalmente em atividades
como o controle integrado de mudanças, ao trabalhar com recursos a ao lidar com questões no projeto.
É necessária a revisão da documentação (termo de abertura, contratos, documentação de planejamento, lições

aprendidas, artigos e outros documentos) para ajudar a identificar mais riscos.
Para Mulcahy (2009), existem algumas técnicas de coleta de informações para coletar ou identificar mais riscos,
tais como:
• Braistorming, usada em uma reunião em que uma ideia ajuda outra;
• Técnica Delphi, usada para alcançar um consenso de especialistas anonimamente, por meio do envio
de uma solicitação de informações, suas respostas são compiladas e enviadas novamente para
validação ou revisão;
• Entrevista, consiste na equipe ou o gerente de projetos entrevistar os participantes do projeto e as partes

interessadas;
• Análise de causas-raiz, organizar os riscos por sua origem ajuda a identificar mais riscos;
• Análise de forças, fraquezas, oportunidades e ameaças (SWOT), avalia o projeto analisando seus pontos
fortes e fracos para identificar mais riscos (oportunidades e ameaças);
• Análise da lista de verificação, usada para identificar riscos específicos em cada categoria;
• Análise das premissas, verificar quais foram usadas no projeto, se são válidas, pode levar a identificar
mais riscos; e
• Técnicas de diagramas, para identificar mais riscos os diagramas de causa e efeito e fluxogramas auxiliam
a analisar as causas-raiz de problemas.
A única saída deste processo é, segundo PMBOK (2017), o registro dos riscos, local em que as informações dos
riscos são mantidas, é um documento utilizado para todo o processo de gerenciamento dos riscos e neste
processo deve conter a lista dos riscos, a lista de possíveis respostas, a causas-raiz dos riscos e a categoria de
riscos atualizada.
Ouça esse podcast sobre a identificação de riscos.
http://www.ricardo-vargas.com/pt/podcasts/riskidentification/
Gerenciamento dos Riscos II
13.1. REALIZAR A ANÁLISE QUALITATIVA DOS RISCOS

É o processo de priorização de riscos para análise ou ação adicional através da avaliação e combinação de sua
probabilidade de ocorrência e impacto, segundo o PMBOK (2017).
Como salienta Muto; Pereira (2008), incluem métodos subjetivos que permitem qualificar os riscos em função de
seu efeito potencial individual e priorizá-lo para o projeto como um todo. A Figura 55 ilustra este processo.
FIGURA 55 – PROCESSO DE REALIZAR A ANÁLISE QUALITATIVA DE RISCOS
Para Mulcahy (2009), este processo envolve criar uma lista curta dos riscos identificados anteriormente e que será
encaminhada para o processo posterior de Realizar análise quantitativa dos riscos ou transferida ao processo
Planejar as respostas aos riscos.
Também, Dismore; Cavalieri (2010), afirmam que é o processo de avaliar o impacto e a probabilidade dos riscos
identificados.
Para realizar uma análise qualitativa, deve-se basear no julgamento, na intuição e na experiência para estimar
probabilidades de ocorrência de riscos e de medir a intensidade de perdas, ela é simples, rápida e econômica. O
principal objetivo é determinar quais os riscos são mais críticos no projeto, determinando:
• Probabilidade de ocorrência de cada risco, usando escala padrão, como baixa, média e alta ou de 1 a 10; e
• Impacto consequências positivas ou negativas, usando escala padrão, como baixa, média e alta ou de 1 a 10.
O resultado dessas escalas é uma classificação dos riscos dentro de uma matriz de probabilidade e impacto,
conforme Figura 56, um exemplo de matriz de probabilidade e impacto.
FIGURA 56 – EXEMPLO DE MATRIZ DE PROBABILIDADE E IMPACTO
Essa matriz é usada para organizar ou classificar os riscos a fim de determinar uma resposta imediata, por-
tanto passarão por todo o processo de riscos e quais devem ser colocados numa lista de observação, segundo
o PMBOK (2017).
A categorização dos riscos consiste em agrupar os riscos por uma causa, com o objetivo de saber quais pacotes de
trabalho, processos, pessoas e outras causas em potencial apresentam mais riscos associados a ele.
Deve ser realizada, também, uma avaliação da urgência dos riscos que consiste em identificar quais riscos devem
ser priorizados no processo.
A única saída deste processo é, segundo PMBOK (2017) o registro dos riscos, local em que as informações dos riscos
são mantidas, é um documento utilizado para todo o processo de gerenciamento dos riscos e neste processo deve
conter os resultados da análise qualitativa dos riscos, como a classificação de riscos do projeto em comparação
com outros projetos, a lista dos riscos priorizados e classificados em sua probabilidade e impacto, riscos agrupados
por categoria, lista de riscos que exigem análise adicional em curto prazo e lista dos que necessitam análise e
respostas adicionais, lista de observação (riscos não críticos mas revistos no monitoramento e controle).
13.2. REALIZAR A ANÁLISE QUANTITATIVA DOS RISCOS

É o processo de analisar numericamente a probabilidade dos riscos (Figura 57) e seu impacto nos objetivos do
projeto, segundo o PMBOK (2017).
FIGURA 57 – PROCESSO DE REALIZAR A ANÁLISE QUANTITATIVA DE RISCOS
Para Dismore; Cavalieri (2010), é o processo de levantar informações históricas, entrevistas com especialistas e
observações estatísticas, criando assim uma base para determinar estimativas mais precisas e confiáveis.
Mulcahy (2009) define como este processo envolve determinar quais riscos exigem uma resposta, qual é o
risco geral do projeto (tolerância), reservas de custo e cronograma, identificar quais exigem mais atenção e
criar metas.
Para realizar uma análise quantitativa você pode realizar entrevistas, estimativas de tempo e custo, técnica Delphi,
registros históricos, opinião especializada, análise do valor monetário esperado (VME), análise de Monte Carlo e
árvore de decisão, segundo o PMBOK (2017).
• A análise do valor monetário esperado é uma medição para determinar a classificação geral de riscos pela
multiplicação da probabilidade (P) vezes o impacto (I), a fórmula é a seguinte VME = P x I.
• A análise de Monte Carlo (técnica de simulação), usa o diagrama de rede e estimativas para realizar o
projeto muitas vezes e simular os resultados de custo ou cronograma do projeto. Esta análise, geral-
mente é feita por um programa de computador devido à complexidade dos cálculos, avalia o risco geral
do projeto, fornece uma probabilidade de terminar o projeto num dia específico ou qualquer custo, de
uma atividade estar no caminho crítico, converte incertezas em impactos no projeto total e resulta numa
distribuição de probabilidades.
• A árvore de decisão é escolher entre muitas alternativas qual é a alternativa que melhor beneficia o projeto
para escolher, ela considera eventos futuros ao tomar uma decisão hoje, calcula o VMA em situações mais
complexas e envolve exclusividade mútua.
Exercício: Você precisa viajar de avião de uma cidade a outra e pode escolher uma das companhias aéreas A ou B.
Qual companhia aérea você deve escolher e qual é o valor monetário esperado de sua decisão considerando: Com-
panhia A, tarifa de R$ 900,00, Probabilidade de chegar no horário de 90% e o custo do atraso é de R$ 4.000,00; e
Companhia B, tarifa de R$ 300,00, Probabilidade de chegar no horário de 70% e o custo do atraso é de R$ 4.000,00.
Resposta: você deve analisar que a companhia aérea deve chegar atrasada 10% das vezes, já a B em 30% das
vezes. O impacto de atraso das duas companhias é de R$ 4.000,00. O cálculo a ser realizado é Companhia A
(10% x 4000,00) + (90% x 0) + 900 = R$ 1.300,00; e Companhia B (30% x 4000,00) + (70% x 0) + 300 = R$ 1.500,00.
Portanto a melhor companhia é a com VME de R$1.300,00.
A única saída deste processo é, segundo PMBOK (2017) é o registro dos riscos, local em que as informações
dos riscos são mantidas, é um documento utilizado para todo o processo de gerenciamento dos riscos e neste
processo deve conter os resultados da análise quantitativa dos riscos, como a lista dos riscos priorizados
quantificados, quantidade de reservas de tempo e custo para contingências necessárias (acrescentar 2 meses
ao projeto para acomodar os riscos), possíveis datas de término e custos do projeto realistas e alcançáveis,
com níveis de confiança, probabilidade quantificada de atingir os objetivos do projeto (80% de probabilidade
de completar o projeto em 6 meses) e tendências.
13.3. PLANEJAR AS RESPOSTAS AOS RISCOS

É o processo responsável por desenvolver opções e ações para aumentar as oportunidades e reduzir as ameaças
aos objetivos do projeto, ilustrado na Figura 58, assegurando que os riscos identificados serão adequadamente
tratados, segundo o PMBOK (2017).
FIGURA 58 – PROCESSO DE PLANEJAR RESPOSTA DE RISCOS
Para Mulcahy (2009), este processo envolve adotar alternativas para eliminar ameaças antes que ocorram, asse-
gurar oportunidades e as ameaças restantes que não podem ser eliminadas você deve preparar planos de con-
tingência e caso estas não forem eficazes você deve possuir planos alternativos.
Segundo Muto; Pereira (2008) as respostas planejadas e dadas aos riscos:
• Devem ser adequadas à relevância do risco;
• Serem rápidas e realistas dentro do contexto do projeto,
• Ter eficácia de custos para atender ao desafio;
• Acordadas por todas as partes envolvidas para inserir recursos no orçamento, atividades no cronograma
e alterar o plano de gerenciamento do projeto, conforme necessário.
A dica aqui é a de que todos os riscos do projeto podem ser eliminados do projeto, mas o tempo e os problemas
gerados para eliminá-los no projeto não valeria a pena.
13.4. ESTRATÉGIAS DE RESPOSTA AOS RISCOS

Após terminadas as respostas aos riscos, é necessária uma análise minuciosa das possíveis respostas aos riscos e
segundo Dismore; Cavalieri (2010) as técnicas utilizadas como opções de estratégias para resposta às ameaças incluem:
• Eliminar, eliminar a ameaça eliminando a causa (eliminar um pacote de trabalho ou afastar uma pessoa);
• Mitigar, reduzir a probabilidade ou o impacto, tonando-se um risco menor e removendo-o do alto da lista
de riscos principais; e
• Transferir, desviar ou alocar, tornar outra parte responsável pelo risco (contratar seguro, garantias, tercei-
rização do trabalho, contratos).
• Já as técnicas utilizadas como opções de estratégias para resposta às oportunidades incluem:
• Explorar (oposto de eliminar), adicionar trabalho ou mudar o projeto para que a oportunidade ocorra;
• Melhorar (oposto de mitigar), aumentar a possibilidade e/ou os impactos positivos do evento de risco; e
• Compartilhar, alocar parte da propriedade da oportunidade a um terceiro, pois é mais capacitado para
concretizar a oportunidade.
Quando a estratégia de respostas a ameaças e oportunidades escolhida é aceitar, você deixa acontecer sem tomar
nenhuma providência.
As saídas deste processo são, segundo Guia PMBOK (2017), atualizações no plano do projeto, pois atividades ou
pacotes de trabalho podem ser adicionados ou retirados, tornando o planejamento um processo iterativo, atua-
lizações nos documentos do projeto e atualizações no registro dos riscos como os riscos residuais (permanecem
após o planejamento de respostas aos riscos) planos de contingência (descrevem ações específicas que serão
adotadas se ocorrer a oportunidade ou ameaça), responsáveis pelas respostas (não necessariamente será um
membro da equipe o dono do risco), riscos secundários (análise dos novos riscos gerados pela implementação das
respostas), gatilhos de riscos (eventos que acionam a resposta de contingência), contratos (o gerente de projetos
deve ser envolvido antes da assinatura do contrato para inserir termos e condições de mitigação ou transferir
ameaças ou ampliar oportunidades), planos alternativos e reservas para contingências.
A dica aqui é a de que existem dois tipos de reservas, a de contingência, que cobrem os riscos residuais do projeto
e a de gerenciamento, estes são itens que não se conseguiu ser identificar no gerenciamento de riscos e podem
ser estimados, como por exemplo, 5% dos custos do projeto.
Aprenda aqui como fazer planos de resposta e contingência. http://www.elirodrigues.com/2013/09/21/como-

-gerenciar-riscos-como-fazer-planos-de-resposta-e-contingencia/

PROJECT MANAGEMENT INSTITUTE (PMI). Project Management Boby of Knowledge (PMBOK). Pennsylvania, 2017.

Algo ou alguém que licita; licitador. Que ou aquele que faz ofertas para comprar alguma
Licitantes
coisa pelo preço que aponta
Análise FOFA ou FFOA (Forças, Fraquezas, Oportunidades e Ameaças) é uma ferramenta

Análise SWOT utilizada para fazer análise de cenário (ou análise de ambiente), sendo usada como base
para gestão e planejamento estratégico de uma corporação ou empresa
UIA 5 | EXECUÇÃO, MONITORAMENTO
E CONTROLE DE PROJETOS PDPJ-Br
Sumário
1. Introdução
2. Visão Geral da Fase
3. Fluxo do Processo
4. Instrumentos, ferramentas e técnicas
5. Gestão do Valor Agregado (EVM)
6. Resumo
7. Exercitando UIA 5
1. Introdução
Todo projeto precisa ser executado, e por isso precisa de uma orientação e gestão para orientar a sua execução,
isso quer dizer, gerenciar as diversas interfaces técnicas e organizacionais para executar o trabalho previsto no
Plano do Projeto. Além disso...
O AMBIENTE DE PROJETOS ENVOLVE SEMPRE UM GRAU DE INCERTEZA DEVIDO

AO NÚMERO DE VARIÁVEIS QUE PRECISAM SER “CONTROLADAS”.
E para controlar essas incertezas, temos o:
Podemos concluir então que...
Gerenciar um projeto é administrar as incertezas do projeto, planejando sua execução

(antes de iniciá-la), a viabilizando e controlando o projeto de modo a assegurar sua
conclusão no prazo e orçamento estipulados, conforme as especificações, atendendo
ou superando as necessidades e expectativas das partes interessadas.
Monitorar e controlar significa acompanhar o progresso e medir o desempenho do projeto por meio da comparação
entre o realizado e o planejado, tomando ações corretivas apropriadas, conforme necessário.
Portanto, nesta UIA, você vai aprender quais são as opções e decisões necessárias à execução do projeto e seu
monitoramento e controle. Também vai estudar e compreender as ferramentas que dão suporte ao comprimento
da premissa do gerenciamento de projetos que é realizar o que foi planejado – e como elas afetam diretamente
o desempenho do projeto.

Essa fase envolve a coordenação das pessoas e dos recursos, além da integração e da realização das atividades
do projeto de acordo com o Plano Geral do Projeto, isto é, a equipe do projeto e recursos deve estar a postos para
executar as atividades planejadas na fase anterior.
Devido a algumas variações de execução, o que é normal, poderá ser necessário algum replanejamento em deter-
minados momentos. Essas variações podem incluir as durações de atividades, disponibilidade de recursos, e os
riscos não esperados. A maior parte do orçamento previsto é gasto nessa fase.
O Monitoramento e Controle servem para observar o andamento do projeto, de forma que possíveis problemas
possam ser identificados no momento adequado e que possam ser tomadas ações corretivas, quando necessário,
para controlar a execução do projeto. O principal benefício é de que o desempenho do projeto passa a ser observado
e medido regularmente para identificar variações em relação ao Plano Geral do Projeto.
Observem abaixo um quadro exemplo resumido dos processos de execução, monitoramento e controle:
QUADRO 1 – PROCESSO DE EXECUÇÃO, MONITORAMENTO E CONTROLE
Processo
Fase do Projeto Instrumentos
Entradas Atividades Saídas
Execução, Plano de Projeto Executar/controlar Termo de Metodologia de

monitoramento atividades previstas Homologação Gerenciamento
e controle no cronograma de Projetos
Produtos do
Monitorar/ajustar Projetos Software de
Plano de Projeto Gerenciamento
Relatórios de
de Projetos
Gerenciar solicitações Progressos
de mudanças Treinamento
Requisições de
Gerenciar as Mudanças Habilidades de
expectativas do Comunicação
Atas de Reuniões
stakeholders
Opinião Especializada
Plano de Projeto
Realizar reuniões
Ajustado Inspeção
de progresso do
projeto/etapas Registro de Replanejamento
Questões
Solicitar aprovação Template de Relatório
de entregas (termo de Progresso
de homologação) Gerenciamento
Elaborar solicitações de de Conflitos
mudanças (requisições Reavaliação do Riscos
de mudanças)
Métodos de
Envolver áreas Comunicação
interessadas no
momento adequado Reunião de Avaliação
de Desempenho
Comunicar-se com os
principais stakeholders Regras de
Escalonamento
Manter equipe
motivada e envolvida
no projeto
Elaborar planos
de ação
Registrar questões
(problemas e riscos)
E o resumo dos principais papéis do processo:
TABELA 1 – PAPÉIS DO PROCESSO DE EXECUÇÃO, MONITORAMENTO E CONTROLE
Execução, Monitoramento e Controle
Executar Plano Geral do Projeto
Produzir relatório gerencial de desempenho do projeto
Registrar issues
Gerente do Projeto Analisar riscos do projeto
Realizar as ações corretivas
Registrar solicitação de mudanças
Elaborar plano de ação
Analisar relatório de progresso do projeto
Submeter issues a um Comitê Executivo
Validar previamente o documento do plano de projeto
Escritório de Projetos (EP) Encaminhar plano de ação para os envolvidos
Receber mudança aceita
Ajustar Plano Geral do Projeto
Assegurar atualizações do Plano Geral do Projeto
Deliberar sobre issues em pauta
Rejeitar mudança
Comitê Executivo
Arquivar mudança rejeitada
Aceitar mudança
3.1. GRUPO DO PROCESSO DE EXECUÇÃO

Com a linha de base planejada, aprovada e com os recursos alocados, o projeto passará para a fase de Execu-
ção. Este processo resume-se a colocar os planos do projeto em ação, onde o gerente de projeto coordenará e
direcionará os recursos para atender aos objetivos do planejado. Neste processo, os custos são geralmente mais
altos, demandando um maior número de recursos e os gerentes de projetos encontram normalmente os maiores
conflitos relacionados aos cronogramas.
FIGURA 60 – ÁREAS DE CONHECIMENTO X GRUPOS DE PROCESSOS DE EXECUÇÃO
EXECUÇÃO
Integração Escopo Tempo
Custo Qualidade Pessoas
Comunicação Riscos Aquisição
Áreas de Conhecimentos cobertas no Processo de Execução
Esta área de conhecimento, INTEGRAÇÃO, para o grupo de processo Execução, resume-se à execução do plano
de projeto.
A execução do plano de projeto é definida como sendo o processo pelo qual é conduzido de acordo com o planejado,
com o orçamento, os membros da equipe e o tempo.
FIGURA 61 – GERENCIAMENTO DE INTEGRAÇÃO NO GRUPO DE PROCESSO DE EXECUÇÃO
As solicitações de mudanças geralmente são identificadas enquanto o trabalho está sendo realizado. Outros
resultados encontrados neste grupo de processo são as atividades que estão sendo desenvolvidas.
Na execução, esta área de conhecimento, QUALIDADE, resume-se à garantia da qualidade.
A garantia da qualidade é uma função gerencial para todas as atividades e sistemáticas implementadas dentro
de um sistema de qualidade estabelecido no processo do planejamento do projeto.
FIGURA 62 – GERENCIAMENTO DA QUALIDADE NO GRUPO DE PROCESSO DE EXECUÇÃO
Se existe mais de uma pessoa trabalhando no projeto, você tem uma equipe, dispondo de habilidades diferentes,
necessidades e problemas. Esta área de conhecimento para o grupo de processo “Execução” foca no desenvolvi-
mento da equipe.
O desenvolvimento da equipe significa criar um ambiente estimulante e aberto para que as pessoas envolvidas
contribuam com o desenvolvimento do projeto, assim como, desenvolver a equipe no sentido de um grupo coor-
denado, funcional e eficiente. Em muitos casos, é importante treinar os mesmos em técnicas ou ferramentas para
que possam desempenhar seus trabalhos da melhor forma possível. Quanto melhor for o trabalho em conjunto,
tanto mais tranquila e eficiente será a sua execução.
No grupo de processo de execução, a comunicação dar-se através da disponibilização das informações para as
pessoas envolvidas no projeto (stakeholders).
A distribuição da informação inclui a implementação do plano de gerenciamento de comunicação junto aos

stakeholders para a obtenção das informações em tempo hábil. A comunicação pode ser feita de várias maneiras:
• Escrita;
• Oral;
• Interna (dentro do projeto);
• Externa (para clientes, mídia, público);
• Formal ou informal:
• Formal escrita (termo de abertura do projeto, plano de gerenciamento);
• Informal escrita (anotações, memorandos);
• Formal oral (apresentação, seminários);
• Informal oral (conversa entre stakeholders);
• Vertical (de cima para baixo na organização);
• Horizontal (entre colega da organização).
FIGURA 63 – GERENCIAMENTO DA COMUNICAÇÃO NO GRUPO DE PROCESSO DE EXECUÇÃO
Neste processo, a aquisição trata da solicitação de propostas, seleção de fornecedores e o gerenciamento

dos contratos.
A solicitação de propostas envolve a obtenção de respostas das ofertas e propostas dos potenciais fornecedores.
O maior esforço deste processo é gasto na prospecção dos fornecedores.
A seleção dos fornecedores envolve a aplicação de critérios de seleção dos fornecedores de acordo com as ofertas
e propostas entregues.
A administração de contrato é um processo de garantia do desempenho dos fornecedores de acordo com os

requisitos contratados. Em grandes projetos com vários fornecedores de produtos e serviços, o aspecto chave da
administração de contratos é o gerenciamento das interfaces entre os vários fornecedores.
FIGURA 64 – GERENCIAMENTO DA AQUISIÇÃO NO GRUPO DE PROCESSO DE EXECUÇÃO
3.2. GRUPO DO PROCESSO DE MONITORAMENTO E CONTROLE
Neste processo é analisada a avaliação de desempenho para descobrir se a realizado está de acordo com o plano
do projeto. As variações são alimentadas neste processo em várias áreas do conhecimento, se for encontrado algum
desvio, deverão ser aplicadas medidas corretivas para sincronizar as atividades ao plano. Controlar consiste em
coletar dados para monitorar o desempenho em relação ao planejado, analisando variações do plano do projeto,
decidindo-se se as ações corretivas são necessárias para trazer o desempenho de acordo com o planejado, e
decidir-se se o plano necessita ser ajustado.
FIGURA 65 – ÁREAS DE CONHECIMENTO X GRUPOS DE PROCESSOS DE CONTROLE
CONTROLE
Áreas de Conhecimentos cobertas no Processo de Controle
O propósito do gerenciamento integrado de mudanças é gerenciar e implementar as políticas organizacionais a elas rela-
cionadas. O gerenciamento integrado de mudanças estrutura a base para todos os processos de controle de mudanças.
A preocupação maior do gerenciamento integrado de mudanças é coordenar as mudanças através do projeto em

seu ciclo de vida. As mudanças não indicam necessariamente, um impacto negativo no projeto, podendo gerar
também resultados positivos.
Existe neste controle um risco alto, se não gerenciado com cuidado, pois o excesso de mudanças, ou até mesmo
uma única mudança significativa, poderá impactar no custo, no cronograma, no escopo e na qualidade do produto.
FIGURA 66 – GERENCIAMENTO DA INTEGRAÇÃO NO GRUPO DE PROCESSO DE CONTROLE
O controle na área de conhecimento “Escopo” consiste basicamente em duas atividades: Verificação do escopo e
Controle de mudanças do escopo.
As saídas do processo de mudanças do escopo são: mudanças do escopo, ações corretivas, lições aprendidas e
linha de base ajustada.
A verificação do escopo é o processo de formalização da aceitação do escopo através das pessoas que estão
envolvidas no projeto (stakeholders). Quando são requisitadas mudanças no escopo, todas as áreas devem ser
revisadas para detectar os possíveis impactos.
O controle de mudanças do escopo cobre os assuntos abordados pelo controle de mudanças integradas, focando
apenas na mudança de escopo.
O controle de mudanças se preocupa com:
• Influências de fatores geradores de mudanças;
• Determinação e registro da ocorrência de mudança;
• Gerenciamento das mudanças reais quando e se elas ocorrerem;
No grupo de processos de Controle, o controle do tempo, gerencia as mudanças efetuadas no cronograma. De acordo
com o PMBOK Guide, mudanças no escopo impactarão no cronograma, e conseqüentemente revisões deverão ser
realizadas no cronograma.
O controle do cronograma se preocupa com:
• Influências de fatores geradores de mudanças no cronograma;
• Determinação e registro da ocorrência da mudança;
• Gerenciamento das mudanças reais quando e se elas ocorrerem;
O controle dos custos resume-se na procura dos “porquês”, ou seja, as causas positivas ou negativas das variações
do custo do projeto.
O controle dos custos se preocupa com:
• Influência de fatores geradores de mudanças na linha de base do custo;
• Determinação e registro da ocorrência das mudanças na linha de base de custo ocorridas;
• Gerenciamento das mudanças reais quando e se elas ocorrerem.
Uma parte importante do controle de custos é determinar o que está causando a variação e decidir se requer
ação corretiva.
O controle da qualidade é uma função técnica que envolve a definição da linha de base do projeto para coletar
os dados específicos para medir se a linha de base está em conformidade. É específico quanto ao monitora-
mento dos resultados obtidos do trabalho, verificando se atendem aos padrões determinados no plano de
gerenciamento da qualidade.
Existem alguns termos e conceitos associados ao controle da qualidade:
• Variável: Uma característica da qualidade que é medida em incrementos;
• Atributo: Uma característica da qualidade que seja classificada como estando em conformidade ou em
não conformidade às especificações ou aos requisitos;
• Probabilidade: refere-se à possibilidade que alguma coisa acontecerá;
Deve ser aplicado e executado ao longo de todo o projeto para identificar e eliminar as causas dos resultados
inadequados. Os resultados estão relacionados com a perspectiva do gerenciamento de projeto, ou seja, com
cronograma, desempenho dos custos, por exemplo.
No controle do projeto, o relatório de desempenho, é a ferramenta utilizada referente à área do conhecimento

comunicação.
O relatório de desempenho envolve a coleta e a disseminação das informações de desempenho para as pessoas
envolvidas no projeto, sobre como os recursos estão sendo utilizados para atingir os objetivos, devendo fornecer
informações sobre escopo, cronograma, custo e qualidade.
Este processo inclui as seguintes atividades:
• Relatório de Situação (Status Reporting): Descreve onde o projeto se encontra atualmente;
• Relatório de Progresso (Progress Report): Descreve o que a equipe realizou de acordo com o planejado;
• Previsão (Forecasting): Prediz um progresso ou situação futura do projeto;
O PMI define o monitoramento e o controle dos riscos como sendo um processo de manter-se informado sobre os
riscos identificados, monitorando os riscos residuais e a identificação de novos riscos, garantindo a execução do
plano de risco.
O controle de risco envolve a escolha de alternativas, implementação do plano de contingência, ações corretivas
ou re-planejamento do projeto.
Para finalizar essa seção, a figura 9 exemplifica um fluxo de processos de execução, monitoramento e controle:
FIGURA 67 – EXEMPLO DE PROCESSO DE EXECUÇÃO, MONITORAMENTO E CONTROLE

Em seguida veremos os instrumentos, ferramentas e técnicas que dão suporte ao processo em questão.
4.1. METODOLOGIA DE GERENCIAMENTO DE PROJETOS

A metodologia de gerenciamento de projetos define um processo que auxilia a equipe de projetos na execução
do Plano Geral do Projeto.
4.2. SISTEMA DE GERENCIAMENTO DE PROJETOS

Possibilita acompanhar as datas planejadas em relação às datas reais e prever os efeitos das mudanças no cro-
nograma do projeto, o que demonstra sua utilidade como ferramenta de controle do cronograma.
4.3. TREINAMENTO
O treinamento inclui todas as atividades criadas para aprimorar as competências dos membros da equipe do
projeto, podendo esse ser formal ou informal.
Se os membros da equipe do projeto não possuírem as habilidades técnicas ou de gerenciamento necessárias,

essas habilidades poderão ser desenvolvidas como parte do trabalho do projeto.

4.4. HABILIDADES DE COMUNICAÇÃO
As habilidades de gerenciamento geral relacionadas às comunicações incluem garantir que as pessoas certas
obtenham as informações na hora certa. Como parte do processo de comunicação, o emissor é responsável por
garantir que as informações estejam claras e completas, de forma que o receptor possa recebê-las corretamente,
e pela confirmação de que elas são adequadamente entendidas.
4.5. OPINIÃO ESPECIALIZADA

É usada pelo gerente de projeto para monitorar e controlar o trabalho do projeto.
4.6. INSPEÇÃO
Inclui atividades como medição, exame e verificação para determinar se o trabalho e as entregas atendem aos
requisitos e aos critérios de aceitação do produto.
4.7. REPLANEJAMENTO
As solicitações de mudanças aprovadas que afetam o escopo do projeto podem exigir modificações na EAP e con-
sequentemente no Plano Geral do Projeto, isto é, essas solicitações de mudanças aprovadas podem resultar em
atualizações nos componentes do Plano Geral do Projeto.
4.8. RELATÓRIO DE PROGRESSO

O relatório de progresso e a situação atual do escopo e cronograma incluem informações como as datas de início
e término reais e as durações restantes das atividades do cronograma não finalizadas. Para identificar e analisar
o progresso real do projeto, é recomendável utilizar a técnica da Gestão do Valor Agregado ou Earned Value Mana-
gement (EVM), que será comentada na próxima seção.
4.9. GERENCIAMENTO DE CONFLITOS

Um gerenciamento de conflitos bem-sucedido resulta em maior produtividade e relações de trabalho positivas.
Quando gerenciadas adequadamente, as diferenças de opinião são saudáveis, podendo aumentar a criatividade e
melhorar a tomada de decisões. O conflito deve ser tratado desde o seu surgimento e normalmente em particular,
usando uma abordagem direta e colaborativa.
4.10. REAVALIAÇÃO DOS RISCOS

O processo de monitoramento e controle dos riscos normalmente exige a identificação de novos riscos e a reavalia-
ção de riscos antigos. O gerenciamento dos riscos do projeto deve ser um item da pauta de reuniões de andamento
da equipe do projeto.
4.11. MÉTODO DE COMUNICAÇÃO

As reuniões presenciais dos membros são os meios mais eficazes de comunicação e resolução de problemas
com as partes interessadas. Quando não há justificativa para essas reuniões com a presença física dos membros
ou quando elas são impraticáveis, telefonemas, e-mails e outras ferramentas eletrônicas são úteis para trocar
informações e estabelecer contatos.
4.12. REUNIÃO DE AVALIAÇÃO DO ANDAMENTO
As reuniões de avaliação do andamento são eventos regularmente agendados para trocar informações sobre os
projetos. Na maioria dos projetos, essas reuniões serão realizadas com frequências diferentes em níveis diversos.
A figura 10 apresenta uma agenda exemplo do CNJ.
FIGURA 68 – EXEMPLO DE AGENDA DE MONITORAMENTO E CONTROLE
4.13. REGRAS DE ESCALONAMENTO

As regras de escalonamento são as regras de decisão para os envolvidos no projeto quando há riscos, problemas
ou mudanças impactando o projeto. Isto é, quem decide o quê, assim não havendo sobreposição nos papéis
decisórios no projeto.
Essas diretrizes devem identificar as regras em que riscos, problemas ou mudanças devem ser escalados para
aprovação de um Comitê decisório.
• Abaixo uma tabela de diretrizes de escalonamento de Riscos, Problemas ou Mudanças que impactem o
Escopo do projeto
Ação GP EP Comitê
Quando riscos, problemas ou mudanças impactarem o
Analisa e
escopo, mas sem comprometerem o orçamento e/ou prazo Reporta
dá suporte
final e/ou objetivos do projeto.
Encaminha Escala
escopo e comprometerem o orçamento e/ou prazo final.
Delibera
Encaminha Escala
escopo e comprometerem o Objetivo do projeto.

• Abaixo uma tabela de diretrizes de escalonamento de Riscos, Problemas ou Mudanças que impactem o
Prazo do projeto
Quando riscos, problemas ou mudanças impactarem a

Analisa e
entrega dos pacotes de trabalho do projeto e/ou compro- Reporta
dá suporte
meterem o prazo final da frente de trabalho.

Encaminha Escala Aprova
prazo final do projeto.
• Abaixo uma tabela de diretrizes de escalonamento Riscos, Problemas ou Mudanças que impactem o
Custo do projeto

Resolve
orçamento dos centros de custos sem comprometerem o
internamente
orçamento final.

Escala Delibera
orçamento final do projeto.
Quando riscos, problemas ou mudanças impactarem no

Delibera
remanejamento de recursos financeiros entre projetos.
5. Gestão do Valor Agregado (EVM)

Desenvolvido em 1969, num esforço conjunto entre a NASA e o Departamento da Defesa dos EUA, a Gestão do
Valor Agregado, também conhecido como Análise do Valor Adquirido, ou ainda, pelas siglas EVA e EVM, derivadas
das respectivas expressões em inglês Earned Value Analisys e Earned Value Management, é um método que,
há algum tempo, tem registrado um aumento exponencial em todo o mundo.
O PMI (2017) define a Gestão do Valor Agregado, como uma maneira para realizar análise e previsão do desempenho
baseada em tendência, definida a partir da performance do próprio projeto. A Gestão do Valor Agregado torna
possível obter respostas para as respostas abaixo:
• Quando acabará?
• Quanto custará?
Podemos relacionar os principais papéis do EVM:
• Método muito utilizado em medições de desempenho

• Integra medições de escopo, custo e prazo
• Consiste na avaliação do “valor realmente gasto” com o trabalho entregue
• “Gerenciamento com as luzes acesas”
• Onde os problemas estão ocorrendo
• Se eles são críticos ou não
• O que deve ser feito para colocar o projeto novamente nos trilhos
Ele dá suporte à atividade de verificação e ação do ciclo PDCA:
FIGURA 69 – CICLO PDCA
O método EVM tem como elementos básicos:
PV – Planned Value
• Planned Value (valor planejado) ou PV: é o custo orçado do trabalho agendado a ser terminado em uma
atividade ou o componente da EAP até um determinado momento;
AC – Actual Cost
• Actual Cost (custo atual) ou AC: é o custo total incorrido na realização do trabalho na atividade do crono-
grama ou no componente da EAP durante um determinado período de tempo.
EV – Earned Value
• Earned Value (valor agregado) ou EV: é uma quantia orçada para o trabalho realmente terminado na ativi-
dade do cronograma ou no componente da EAP durante um determinado período de tempo;

Abaixo o gráfico do valor planejado, valor agregado e custo atual acumulados:
GRÁFICO 1 – CURVA S
Com os elementos acima determinados, é possível através de cálculos de variância responder a mais perguntas:
• No momento, gastei mais ou menos do que planejei?
• No momento, executei mais ou menos trabalho do que planejei?
• Em relação ao que já gastei, quanto mais vou gastar?
• Em relação ao que tinha planejado, o que consegui cumprir?
• Em relação ao tempo que já levei, quanto tempo mais vou levar?
• Quando deverá ser concluído?
• Quanto deverá custar?
Esses cálculos de variância são encontrados por meio das seguintes fórmulas:
• Schedule Variance (variação do cronograma) ou SV: indica se a execução do projeto está atrasada com
relação ao que foi previsto. É obtido através da fórmula EV – PV; Se negativo, projeto em atraso.
• Cost Variance (variação do custo) ou CV: indica se está sendo gasto mais do que foi previsto. É obtido
através da fórmula EV – AC; Se negativo, custo ultrapassado.
• Schedule Performance Index (Índice de perfomance do cronograma) ou SPI: índice que permite projetar
o término do projeto, baseado no tempo gasto até o momento. É obtido através da fórmula EV / PV.
Se o resultado for maior que “1”, o projeto acabará antes do previsto;
• Cost Performance Index (Índice de performance do custo) ou CPI: semelhante ao índice anterior, permite
fazer uma projeção de quanto será gasto no projeto, baseado no que foi gasto até o momento. É obtido
através da fórmula EV / AC. Se o resultado for maior que “1”, o projeto custará menos que o previsto;
Abaixo o gráfico dos valores cumulativos de um projeto que está acima do orçamento e atrasado em relação ao
plano de trabalho:
GRÁFICO 2 – CURVA S COM VARIÂNCIAS
Com as variâncias acima determinadas, ainda é possível através dos índices de projeção descritos abaixo, encontrar
mais informações gerenciais a respeito do progresso do projeto:
• Estimate Cost at Completion (estimativa de tempo para conclusão) ou ETC: permite fazer uma projeção de
quanto tempo o projeto irá durar. É obtido através da fórmula “tempo previsto”/SPI;
• Estimate Cost at Completion (estimativa de custo para conclusão) ou ECC: semelhante à variável anterior, permite
fazer uma projeção de quanto o projeto irá custar. É obtido através da fórmula “orçamento do projeto”/CPI;
Abaixo, no quadro 6, o resumo das fórmulas de cálculo do EVM:
QUADRO 6 – RESUMO DE FÓRMULAS EVM
Nome Fórmula Interpretação
Cost Variance CV = EV – AC NEGATIVO estou acima do orçado,

CV POSITIVO estou abaixo do orçado
Schedule Variance SV = EV – PV NEGATIVO estou atrasado

SV POSITIVO estou “adiantado”
Cost Performance Index CPI = EV / AC Estou gastando ___ centavos de cada R$ 1,00.
CPI
Schedule Performance Index SPI = EV / PV Estou progredindo ___% da taxa

SPI originalmente planejada.
Estimate at Completion EAC = BAC / CPI Da forma que está, Quanto eu espero
EAC gastar no total com este projeto?
Estimate to Complete ETC = TAC/SPI Da forma que está, Quanto tempo eu

ETC espero gastar até o final deste projeto?
Variation at Completion VAC = BAC - EAC Qual a variação frente ao orçado?

VAC

Veja, na leitura complementar 1, EVA Analisis, um exemplo de aplicação prática das fórmulas.
Além desse texto indicado, visite também o endereço indicado acesse os exemplos da aplicação do instrumento
http://www.earnedvaluemanagement.com/
6. Resumo
A fase de execução tem como objetivo principal a realização das atividades do projeto de acordo com o Plano Geral
do Projeto, pois com a linha de base planejada (escopo, tempo e custo), aprovada e com os recursos alocados, o
projeto estará apto a ser executado.
Em paralelo à fase execução, é realizada a de Monitoramento e Controle servem para observar o andamento do
projeto, de forma que possíveis problemas possam ser identificados no momento adequado e que possam ser
tomadas ações corretivas. Ou seja, nesta fase é analisada a avaliação de desempenho para descobrir se a reali-
zação está de acordo com o plano do projeto.
Essa avaliação de desempenho pode ser realizada por meio da técnica da Gestão do Valor Agregado (EVM), que
realiza uma análise e previsão do desempenho baseada em tendência, definida a partir da performance do
próprio projeto.
A figura 70 ilustra a interação entre as fases acima citadas.
7. Exercitando – UIA 5
Com base nos conteúdos estudados ao longo da UIA, nas suas leituras, reflexões e nas conversas e trocas de ideias
com o professor e com os colegas, responda o que se pede abaixo.
* Elabore um processo de controle de mudanças de projeto para a sua área/organização de acordo com o
formato abaixo.
• Formato:
a) Objetivo
b) Premissas
c) Áreas envolvidas
d) Descritivo das atividades (aderente ao formulário abaixo)
e) Fluxo do processo
f) Pontos de atenção
g) Formulários utilizados
(*Exemplo de formulário de solicitação de mudanças)
Solicitação de Mudança
Entrega: Mudança nº:
Solicitante: Data:
Mudança proposta: Telefone nº:
Motivo para a mudança: Expectativa de data de entrega:
AUTORIZAÇÃO
Autorizado/rejeitado
Assinatura: Cargo: Data:
DETALHES DA MUDANÇA
Comentários: (inclui motivos para rejeição)

UIA 6 | ENCERRAMENTO
DE PROJETOS PJe
Sumário
1. Introdução
5. Processo de Gestão de Lições Aprendidas
6. Resumo
7. Exercitando UIA 6
1. Introdução
Encerrar um projeto significa formaliza a aceitação do produto, serviço ou resultado e conduz o projeto a um
final ordenado.
A finalização do projeto não termina quando a última entrega prevista é viabilizada. O encerramento do projeto
envolve diversos passos que concluem a transição para o cliente, além de fornecer orientação sobre futuros
projetos para a equipe de recursos de implantação.
Realizando a revisão do projeto
Quando o projeto é concluído, a equipe de projeto deve ter uma reunião de análise para discutir o projeto e identi-
ficar os erros e acertos, o que pode ser aproveitado nos projetos futuros e o que deve ser modificado. Sem procurar
culpados, os membros conduzem a análise do projeto com o objetivo de aprender com os erros e aperfeiçoar os
projetos futuros. Geralmente chamada de postmortem ou de processo de lições aprendidas, a reunião de análise
do projeto algumas vezes acontece um pouco antes do final do projeto, e não depois, porque os integrantes da
equipe frequentemente têm que deixar o projeto um pouco antes de sua conclusão. A equipe deve, portanto,
realizar a reunião antes do encerramento da operação com o cliente.
A equipe registra sugestões de mudanças como itens de ação no próximo planejamento de projeto, se ele
estiver programado.
Produzindo o relatório final
O relatório final é o produto físico final da implantação. Ele inclui versões finais de todos os resultados finais.
O gerente do projeto assume a tarefa de compilar o relatório final, que pode ser usado pela equipe e pelo cliente
como fonte de consulta rápida sobre o trabalho realizado durante o projeto e como base para futuro planeja-
mento. O relatório final inclui, também, um resumo das informações solicitadas pelos usuários e um resumo dos
próximos passos conhecidos.
Olhando para o futuro
O conceito de lançamento de versão atualizada implica que a conclusão de um projeto é sempre o prelúdio de
um próximo, no qual a solução é reiteradamente construída e aperfeiçoada. Levando em consideração que preo-
cupações com recursos ou estratégias podem evitar ou limitar a necessidade de acompanhamento logo após a
implantação recém-concluída, há diversos próximos passos possíveis.
Portanto, nesta UIA, você vai aprender quais são as opções e decisões necessárias ao encerramento do projeto.
Também vai estudar e compreender as ferramentas que dão suporte ao comprimento da premissa de garantir
o encerramento efetivo do projeto.

A última fase do projeto é o Encerramento, que é iniciado quando todos os objetivos específicos do projeto foram
alcançados e o patrocinador aceitou todos os produtos e serviços gerados. O Encerramento do projeto inclui os
seguintes elementos chaves:
• Realocar os membros da equipe dos projetos dentro da estrutura organizacional;
• Efetuar o fechamento das questões financeiras tais como encerramento de contratos;
• Arquivar documentação do projeto;
• Documentar as questões e as lições aprendidas do projeto;
• Celebrar o sucesso do projeto.
Normalmente o processo de Encerramento é feito às pressas ou é totalmente ignorado. Entretanto, há vários
propósitos que poderão ajudar em novos projetos.
Embora o trabalho do projeto esteja concluído, o do gerente do projeto ainda não está. O processo de Encerramento
do ciclo de vida do projeto envolve a documentação dos resultados finais e a avaliação do projeto. Durante esse
processo, o gerente deverá avaliar todas as coisas que não tiveram êxito no projeto, aprender com essas coisas e
documentá-las. Todos os documentos criados no projeto finalizado poderão servir de referência para outros projetos.
Observem abaixo o quadro 7 com exemplo resumido do processo de encerramento:
QUADRO 7 – EXEMPLO DE PROCESSO DE ENCERRAMENTO
Processo
Fase do Projeto Instrumentos
Entradas Atividades Saídas
Encerramento Relatório de Elaborar Relatório Relatório de Metodologia de

Aceitação de Aceitação do Aceitação validado Gerenciamento
resultado final de Projetos
Produtos do Projeto Termo de
do projeto
Encerramento Processo de Lições
Relatórios de
Homologar validado Aprendidas
Progresso
resultado final
Sumário de Lições Opinião
Requisições de do projeto
Aprendidas Especializada
Mudança
Elaborar Termo de
Avaliação do
Atas de Reuniões Encerramento
Projeto
Plano de Projeto Validar Termo de
Ajustado Encerramento
Realizar Avaliação
do projeto
Finalizar projeto
no sistema
Levantar Lições
Aprendidas
Compilar Lições
Aprendidas
Divulgar
documentação
do projeto
Armazenar
documentação
do projeto

E o resumo dos principais papéis do processo de encerramento:
QUADRO 8 – EXEMPLO DE PAPÉIS DO PROCESSO DE ENCERRAMENTO
Encerramento
Elaborar Relatório de Aceitação Final do Produto ou Serviço do projeto
Elaborar Termo de Encerramento do projeto
Gerente do Projeto
Realizar Avaliação do Projeto
Finalizar projeto no sistema
Levantar Lições Aprendidas
Compilar Lições Aprendidas
Escritório de Projetos (EP)
Divulgar documentação do projeto
Armazenar documentação do projeto
Homologar resultado final do projeto
Comitê Executivo Validar previamente o Termo de Encerramento do projeto
Validar Termo de Encerramento do projeto
Neste processo será documentada a aceitação formal do produto do projeto pelos participantes, e arquivados
os registros do projeto para futuras referências. Os participantes têm influência mínima e os custos são mínimos,
uma vez que os trabalhos já foram realizados e as despesas já ocorreram. Nas empresas que não utilizam uma
metodologia de gerência de projetos com gerentes qualificados, o encerramento do projeto torna-se o processo
mais negligenciado.
Abaixo, figura com as áreas de conhecimento cobertas pelo processo de encerramento:
FIGURA 71 – ÁREAS DE CONHECIMENTO X GRUPOS DE PROCESSOS DE ENCERRAMENTO
ENCERRAMENTO
Áreas de Conhecimentos cobertas no Processo de Encerramento
No encerramento do projeto sua principal atividade corresponde ao “Encerramento Administrativo”, que está rela-
cionada com a obtenção e distribuição de informações para oficializar o encerramento do projeto, devendo também
ser realizada ao término de cada fase.
O encerramento administrativo verifica e documenta os resultados do projeto. Assim que os resultados forem
documentados, o aceite formal será solicitado aos participantes envolvidos (stakeholders).
O encerramento dos contratos é similar ao encerramento administrativo. Está relacionado à conclusão e liquidação
dos termos dos contratos, verificando se os trabalhos descritos foram finalizados de acordo com o contratado e
de forma satisfatória.
Os contratos podem condições ou termos específicos para sua conclusão e encerramento indevido referente a um
detalhe importante.
Para finalizar essa seção, segue abaixo um exemplo de um fluxo de processos de encerramento:
FIGURA 72 – EXEMPLO DE FLUXO DE PROCESSO DE ENCERRAMENTO

Em seguida veremos os instrumentos, ferramentas e técnicas que dão suporte ao processo em questão.
4.1. PROCESSO DE LIÇÕES APRENDIDAS

Uma sessão de lições aprendidas se concentra na identificação dos sucessos e fracassos do projeto e inclui
recomendações para melhorar o desempenho futuro dos projetos. Durante o ciclo de vida do projeto, a equipe
do projeto e as principais partes interessadas podem identificar as lições aprendidas relacionadas aos aspectos
técnicos, gerenciais e de processos do projeto. As lições aprendidas são compiladas, formalizadas e armazenadas
durante o projeto para então serem divulgadas. Dada a importância desse instrumento ele será comentado na
próxima seção.
4.2. METODOLOGIA DE GERENCIAMENTO DE PROJETOS

Define o processo que auxilia uma equipe de gerenciamento de projetos na realização dos procedimentos de
encerramento administrativo.
4.3. OPINIÃO ESPECIALIZADA

É aplicada no desenvolvimento e realização dos procedimentos administrativos
5. Processo de Gestão de Lições Aprendidas

• Lições Aprendidas são originalmente conceituadas como as diretrizes de algo feito certo ou errado de um
evento particular. (STEWART, 1977).
• Lições Aprendidas representam as experiências vivenciadas de valor. As lições podem apresentar sucesso ou
técnicas inovadoras ou elas podem mostrar deficiências ou problemas que podem ser evitados. (DoD/USA -
Departamento de defesa dos Estados Unidos da América)
• As lições aprendidas representa o conhecimento ou entendimento obtido pela experiência. (An Effective Way
to Prevent Failures and Problems)
Exemplos de lições aprendidas:
> Uma política ou procedimento informal;
> Alguma coisa que você quer repetir;
> A solução para um problema ou uma ação corretiva;
Como evitar a repetição de um erro; Alguma coisa que você nunca quer que aconteça novamente.
Durante o ciclo de vida do projeto a equipe do projeto e os stakeholder identificam as lições aprendidas relacionadas
aos aspectos técnicos gerenciais e de processos do projeto. As lições aprendidas são compiladas, formalizadas e
armazenadas durante o projeto.
Alguns resultados específicos das lições aprendidas incluem (citação):
• Atualizações da base de conhecimento de lições aprendidas;
• Entradas do sistema de gerenciamento do conhecimento;
• Políticas, procedimentos e processos corporativos atualizados;
• Habilidades de negócios aperfeiçoados;
• Melhorias gerais nos serviços e produtos;
• Atualizações no plano de gerenciamento de riscos.
Atualizar os registros históricos...

Contribuindo para o sucesso do próximo projeto.
Abaixo um exemplo de um sistema de gestão de lições aprendidas:
FIGURA 73 – MODELO DE SISTEMA DE GESTÃO DE LIÇÕES APRENDIDAS

O PROCESSO DE COLETA
• Envolve a coleta de informações, seja através de um relatório de incidente, críticas em projetos, formulários,
reuniões ou quaisquer outras fontes dentro da organização.
• As lições aprendidas devem ser baseadas em experiências positivas que visam economizar tempo e
dinheiro, mas também em experiências negativas que obtiveram resultados indesejáveis.
• Contudo, se as organizações focarem somente nas falhas, a efetividade total do programa será reduzida
e oportunidades serão perdidas para melhora de seus processos.
FIGURA 74 – PROCESSO DE COLETA
O PROCESSO DE VERIFICAÇÃO
• Já o processo de verificação serve para avaliar a aplicabilidade da lição aprendida submetida.
• Especialistas no assunto devem ser envolvidos para coordenar e conduzir as revisões para determinar se
a lição aprendida é relevante para outros projetos, é única ou particular de um departamento ou pode
ser aplicada na organização como um todo.
FIGURA 75 – PROCESSO DE VERIFICAÇÃO
PROCESSO DE ARMAZENAMENTO
• O aspecto do armazenamento da lição aprendida envolve o armazenamento das lições em um banco de
dados para disseminação e compartilhamento interno das informações.
• As informações devem ser armazenadas de uma forma que permita os usuários identificar as aplicabili-
dades das informações procuradas.
• Também, cada programa deve incluir capacidades de pesquisa por palavras chaves e categorias funcionais
para facilitar a recuperação de informações.
FIGURA 76 – PROCESSO DE ARMAZENAMENTO
PROCESSO DE DISSEMINAÇÃO
• O último elemento e mais importante é a disseminação das lições aprendidas dentro da organização.
• A disseminação pode se dar através da revisão de um processo de trabalho, treinamentos ou distribuições

rotineiras de informações através dos diversos meios disponíveis internamente na organização.
• As lições devem ser distribuídas de acordo com a prioridade atribuída a ela que denota risco, imediatismo
e urgência de sua aplicação.
FIGURA 77 – PROCESSO DE DISSEMINAÇÃO

PROCESSO DE REUTILIZAÇÃO
• A questão de reutilizar a LA recomendada é uma decisão do usuário.
• Existem três categorias de reutilização:
> Recomendação Pesquisável
» Apresenta a descrição da lição aprendida de acordo com a busca realizada no sistema.
> Recomendação Executável
» Os usuários podem executar a LA selecionada, através de um software de suporte a decisão,

por exemplo.
> Resultados da reutilização
» Grava os resultados obtidos na reutilização da lição aprendida para futuras pesquisas.
FIGURA 78 – PROCESSO DE REUTILIZAÇÃO
Veja, na leitura complementar 2, A Gestão do Conhecimento Aplicada à Prática do Gerenciamento de Projetos,

um exemplo de aplicação prática do processo de lições aprendidas.
Além desse texto indicado, visite também o endereço abaixo e verifiquem a viabilização do processo por meio de
um sistema.
http://www.lessonslearned.com/
6. Resumo
O processo de Encerramento do ciclo de vida do projeto envolve a documentação dos resultados finais e a avalia-
ção do projeto. Neste processo será documentada a aceitação formal do produto do projeto pelos participantes,
e arquivados os registros do projeto para futuras referências.
Durante a documentação do encerramento do projeto recomenda-se a execução do processo de gestão de lições

aprendidas, que se concentra na identificação dos sucessos e fracassos do projeto e inclui recomendações para
melhorar o desempenho futuro dos projetos.
7. Exercitando – UIA 6
Com base nos conteúdos estudados ao longo da UIA, nas suas leituras, reflexões e nas conversas e trocas de ideias
com o professor e com os colegas, responda o que se pede abaixo.
* Preencha o formulário abaixo com as lições aprendidas de algum projeto que você. participou ou tem
conhecimento.
LIÇÕES APRENDIDAS
Identificação do Projeto
Projeto Data de início
1. Recomendações para outros projetos
a) O que não foi previsto e facilitou o andamento do projeto?
b) O que não foi previsto e prejudicou o andamento do projeto?
c) Cite as facilidades encontradas para conseguir a contribuição e apoio das partes envolvidas (internas e
externas ao projeto)
d) Cite as dificuldades encontradas para conseguir a contribuição e apoio das partes envolvidas (internas e
externas ao projeto)
2. Descreva a utilidade observada no emprego das ferramentas e técnicas próprias da gestão:
a) Do escopo do projeto
b) Dos riscos do projeto
c) Dos recursos humanos do projeto
d) Do tempo do projeto
e) De outros quesitos importantes à gestão do projeto

3. Outras observações pertinentes à gestão do projeto
Experiência
Fase do Área do Lição
Relator Data
Projeto Conhecimento Aprendida
Positiva Negativa
UIA 7 | GERENCIAMENTO DE
PROGRAMAS E PORTFÓLIO PDPJ-Br
Sumário
1. Introdução
2. Gerenciamento de Programas
2.1. Contexto
2.2. Framework para o Gerenciamento de Programas
3. Gerenciamento de Portfólio de Projetos
4. Resumo
1. Introdução
O Moderno Gerenciamento de Projetos (MGP) foi desenvolvido a partir do início da década de 1990. Voltado para
uma ampla de aplicações, tendo sido usado em todas as áreas governamentais ou privadas, devido ao rápido
ciclo dos produtos, velocidade da tecnologia e acirrada competição, o que trás ao contexto do Gerenciamento
de Projetos, a necessidade de processos de gerenciamento mais amplos (Programas) e focados na estratégia de
negócios (Portfólio), tendo em vista a integração desses processos.
Abaixo a figura descreve a sequência de viabilização de idéias na visão do gerenciamento de projetos.
FIGURA 79 – FLUXO DE VIABILIZAÇÃO DE IDÉIAS

Abaixo está a relação desses modelos/processos e sua hierarquia:
FIGURA 79 – HIERARQUIA PORTFÓLIO, PROGRAMAS E PROJETOS
Portfólio
Portfólio Projetos Programas
Programas Projetos Programas Projetos Outros

Trabalhos
Projetos Projetos Projetos
Também abaixo as definições desses modelos:
FIGURA 80 – DEFINIÇÕES PORTFÓLIO, PROGRAMAS E PROJETOS
Esses novos modelos/processos possuem objetivos complementares e responde a perguntas distintas da orga-
nização, como:
Onde aplicar os recursos da organização?
Qual a sua escolha?
Como entregar os benefícios?

Portanto, nesta UIA, você vai aprender quais são as opções e decisões necessárias para gerenciar os empreendi-
mentos organizacionais e alinhá-los à estratégia negocial.
Também vai estudar e compreender as ferramentas que dão suporte ao comprimento da premissa de garantir o
gerenciamento de projetos e programas e seu alinhamento estratégico.
2. Gerenciamento de Programas
2.1. CONTEXTO
Finalmente, o Gerenciamento de Programas atingiu o elevado estágio das disciplinas reconhecidas sobre geren-
ciamento e abriu, assim, uma nova perspectiva para o crescimento. Isso se deu em maio de 2006, quando o PMI
introduziu sua norma para Gerenciamento de Programas pela primeira vez no mundo. O fato de o PMI ter “jogado
seu peso” sobre o Gerenciamento de Programas tem elevado o seu significado.
O PMI é a maior organização mundial de gerentes de projetos e tem vivido um crescimento exponencial em termos
de membros associados e é, de fato, o ponto de coesão da comunidade internacional de Gerenciamento de Projetos.
Não vamos nos esquecer de que apensa alguns anos atrás uma grande comunidade (internacional) de Gerencia-
mento de Programas sequer tinha uma ideia onde se situava o Gerenciamento de Programas do contexto; e agora
o Gerenciamento de Programas surge como um farol. Em outras palavras, até recentemente o Gerenciamento de
Programas era ignorado e negligenciado.
Portanto, porque que o Gerenciamento de Programas subitamente é tão crucial para tornar-se o foco de interesse
da sua comunidade? E, por que o Gerenciamento de Programas ocupa merecidamente seu lugar entre as discipli-
nas reconhecidas de gerenciamento?
A resposta para ambas as perguntas é bastante simples – e faz sentido. Por que? Porque as pessoas de forma
não-lógica tentaram empregar as práticas de Gerenciamento de Projetos para solucionar problemas em situações
que constituíam programas em sua essência e, assim, falharam.
O que é ilógico é utilizar uma estratégia (leia-se Gerenciamento de Programas) idealizada para solucionar problemas
via a tripla restrição em projetos e aplicá-la para solucionar problemas de estratégia secundária, cuja natureza
não é aquela da tripla restrição e sim a da estratégia do negócio, tendo os programas como veículos dos negócios
e do seu alinhamento. É mais ou menos como tentar chegar à lua voando com um jato. Uma vez que isso não é
possível, as pessoas pesquisaram e concluíram que chegar á lua de avião (Gerenciamento de Projetos) não vai
ocorrer e o que eles precisam e, melhor ainda, já possuem, é o já testado e aprovado foguete (Gerenciamento de
Programas), que nós referimos assim como o modelo de negócios Gerenciamento de Programas.
O Gerenciamento de Programas é tudo o que o Gerenciamento de Projetos não é. Resumidamente, o Gerenciamento

de Programas é estratégico na essência (imperam as metas do negócio) e no nível do modelo organizacional do
negócio, enquanto que o Gerenciamento de Projetos é tático (regras das metas de tripla restrição). O Gerenciamento
de Programas proporciona um ponto focal dos direitos autorais sobre os resultados dos negócios, já o Gerencia-
mento de Projetos não proporciona esse foco.
Além disso, ao passo que o Gerenciamento de Programas alinha objetivos funcionais com os objetivos do negócio,
o Gerenciamento de Projetos não possui esse mecanismo. Projetos transversais à organização e multidisciplinares
são características centrais do Gerenciamento de Programas, mas não do Gerenciamento de Projetos.
O Gerenciamento de Programas é mais do que o Gerenciamento de múltiplos projetos, enquanto o Gerenciamento

de Projetos lida somente com um projeto. E para concluir, enquanto o Gerenciamento de Programas demanda um
líder apto na gestão do negócio para conduzir um programa, o Gerenciamento de Projetos necessita de outro tipo
de gerente.
Tudo isso diz respeito a Gerenciamento de Programas e certamente pertence a dois níveis – o nível de modelo do
negócio e o nível de gerenciamento de um simples programa. Uma vez que esse modelo, que nós chamamos modelo
de negócios Gerenciamento de Programas, não está detalhado na literatura em um nível de detalhe adequado.
2.2. FRAMEWORK PARA O GERENCIAMENTO DE PROGRAMAS

Um programa é um conjunto de projetos relacionados entre si e gerenciados de uma maneira coordenada para
obter benefícios e efetivo controle não provenientes de um gerenciamento individual.
E o Gerenciamento de Programa é o gerenciamento central e coordenado de um programa para alcançar os bene-

fícios e objetivos estratégicos.
Adicionalmente, o gerenciamento de programas abrange o/a:
• Governança de programa;
• Gerenciamento de benefícios;
• Gerenciamento de stakeholders (envolvidos).
Os gerentes de projeto reconhecem que a melhor prática para se gerenciar e controlar o projeto consiste na divisão
do projeto em entregas discretas ou fases. O Gerenciamento de Programas tem a mesma diretriz.
Para assegurar o controle efetivo do programa, este move-se por fases discretas porém sobrepostas. Estas fases
facilitam a governança do programa, garantindo o controle, a coordenação dos recursos entre os projetos e a
administração de risco global.

O ciclo de vida do programa tem como objetivo administrar resultados e benefícios que são viabilizados pelas entre-
gas de seus produtos. Abaixo temos modelo de ciclo de vida e governança de programa, como mostra a figura 82.
FIGURA 82 – MODELO DE PROCESSO DE GOVERNANÇA DE PROGRAMA
O ciclo de vida do programa não é projetado somente para obedecer às necessidades da governança corporativa,
que comumente se preocupa em viabilizar entregas, mas também para assegurar que os benefícios esperados são
viabilizados dentro um processo previsível e coordenado. Por isso, o Gerenciamento de Programas suporta, além
das entregas dos projetos, a gestão de seus benefícios. Abaixo a figura 8, demonstra a interposição dos processos
do gerenciamento de programas.
FIGURA 83 – MODELO DE PROCESSO DE GOVERNANÇA DE PROGRAMA
Durante o ciclo de vida do programa o Gerenciamento de Programa também suporta o Gerenciamento de seus
Stakeholders. Esse processo gerencia cuidadosamente os interesses e preocupações da lista extensa de stakehol-
ders para assegurar o sucesso do programa.
Abaixo, segue uma lista completa dos processos que dão suporte ao Gerenciamento de Programas.
• Processos da Iniciação de um Programa:
> Iniciar um Programa => Program Charter ou canvas de programa
> Autorizar Projetos => Projects Charters ou canvas de projetos
> Iniciar o Time do Programa => Program Manager designado
• Processos do Planejamento de Programa:
> Desenvolvimento do Plano de Gerência do Programa
> Planejamento de Interface
> Planejamento da Transição
> Planejamento dos Recursos
> Definição do Escopo
> Criação do WBS do Programa
> Desenvolvimento do Cronograma do Programa
> Estimativa de Custo e Orçamentação
> Planejamento da Qualidade
> Planejamento dos Recursos Humanos
> Planejamento da Comunicação
> Planejamento e Análise dos Riscos
> Planejamento das Aquisições do Programa
> Planejamento da Contratação do Programa
• Processos da Execução de Programa:
> Direcionar e Gerenciar a Execução do Programa
> Selecionar o Time do Programa
> Desenvolver o Time do Programa
> Distribuir Informações
> Garantir a Qualidade
> Solicitar Propostas dos Fornecedores
> Selecionar Propostas dos Fornecedores

> Processos do Controle de Programa:
> Controle de Mudanças Integrado
> Monitorar e Controlar o Trabalho do Programa
> Controlar os Recursos
> Gerenciar e Controlar os Problemas
> Controlar o Escopo
> Controlar o Cronograma
> Controlar o Custo
> Controlar o Desempenho da Qualidade
> Controlar a Comunicação
> Reportar o Desempenho do Programa
> Monitorar e Controlar o Risco
> Administrar os Contratos do Programa
• Processos do Encerramento de Programa:
> Encerrar os Componentes do Programa
> Encerrar os Contratos do Programa
> Encerrar o Programa
Veja, na leitura complementar 3, Program and Project Management Difference, diferenças entre projeto
e programa.
3. Gerenciamento de Portfólio de Projetos

Programas consistem no gerenciamento coordenado de um grupo de projetos interdependentes, a fim de se obter
benefícios que, de forma isolada, não se obteria.
Já um portfólio é uma coleção de projetos e/ou programas agrupados para facilitar o gerenciamento efetivo deste
trabalho para atingir os objetivos estratégicos de negócios. Os projetos desse portfólio podem ser mutuamente
independentes ou diretamente relacionados. Em dado momento, o portfólio representa uma “fotografia” destes
projetos que refletem e afetam os objetivos estratégicos da organização (PMI, 2017).
É importante entender o relacionamento de um portfólio e os seus componentes. Abaixo a figura demonstra

essa relação:
FIGURA 84 – HIERARQUIA PORTFÓLIO, PROGRAMAS E PROJETOS
Portfólio
Portfólio Projetos Programas
Programas Projetos Programas Projetos
Projetos Projetos
Um portfólio reflete as intenções e as direções estratégicas de uma organização, condicionadas por prioridades
identificadas, decisões de investimento e recursos alocados.
O Gerenciamento do Portfólio de Projetos é o gerenciamento centralizado de um ou mais portfólios e envolve a

identificação, priorização, autorização, gerenciamento, e controle de projetos para atingir específicos objetivos
estratégicos de negócios (PMI, 2017).
O gerenciamento de portfólio é estruturado por processos de coleta, identificação, categorização, avaliação, sele-
ção, priorização, balanço, autorização, e revisão de componentes dentro do portfólio para avaliar a performance
desses comparada com os indicadores chaves e o planejamento estratégico.
Durante um típico ciclo de negócios, os componentes serão revisados e validados em relação ao alinhamento dos
componentes com a estratégia corporativa, viabilidade dos componentes como parte do portfólio baseado nos
indicadores chaves, valor e relacionamento entre outros componentes do portfólio, recursos disponíveis e priori-
dades de portfólio e adições e exclusões dos componentes do portfólio. Esses estão agrupados a seguir:
QUADRO 9 – RELAÇÃO ENTRE OS PROCESSOS DE ALINHAMENTO E MONITORAMENTO E CONTROLE

É recomendado que esses processos sejam gerenciados pelo Escritório de Gerenciamento de Projetos em uma
frequência diária ou semanal, recebendo reporte de status e atualizando os cronogramas das entregas para a
publicação dos relatórios de portfólio. Abaixo a figura 85 demonstra o papel do Escritório de Projetos no processo
de monitoramento e controle.
FIGURA 85 – PAPEL ESCRITÓRIO DE PROJETOS NO PROCESSO DE MONITORAMENTO
Visite também o endereço abaixo e assista a um vídeo sobre o tema project portfólio management.
https://youtu.be/BkMEYg3TDqw
4. Resumo
Podemos sintetizar essa UIA com a tabela abaixo que reflete a correlação entre projetos, programas e portfólio.
Projetos Programas Portfólio

Possuem um escopo Possuem um escopo Possuem um escopo de negócio
mais restrito com mais abrangente. que muda com os objetivos
entregas específicas. estratégicos da organização.
Sucesso é medido por Sucesso é medido em termos Sucesso é medido em termos
atendimento ao planejado de retorno sobre investimento, de desempenho agregado dos
em termos de custo, de prazo, novas capacidades e entrega componentes do Portfólio.
de escopo e de qualidade. dos benefícios esperados.
O estilo da liderança é focado O estilo da liderança é focado O estilo da liderança foca em
na entrega dos resultados. na manutenção de relações adicionar valor ao processo de
e na resolução de conflitos, tomada de decisão do Portfólio.
inclusive em aspectos políticos.
Gerentes de Projetos gerenciam Gerentes de Programas Gerentes de Portfólios podem
técnicos, especialistas etc. gerenciam Gerentes de Projetos. gerenciar ou coordenar profissionais
de gerência de Portfólio.
UIA 8 | ESCRITÓRIOS DE
GERENCIAMENTO DE PROJETO (PMO)
Sumário
1. Introdução
2. Definição
3. Histórico
4. O Papel do EGP na Gestão Estratégica
5. O Valor do EGP para uma Organização
6. Os Tipos de EGP
7. Diretrizes para um EGP estratégico
8. Resumo
1. Introdução
Até 2008, as organizações que estabelecerem padrões para gerenciamento de projetos, incluindo um Escritório de
Gerenciamento de Projetos com boa governabilidade, vão experimentar metade dos problemas de custos, atrasos
e cancelamento de projetos do que as que não conseguirem adotar essas práticas (70% de probabilidade). Gartner
Group – Agosto de2006.
As previsões do Gartner Group, empresa especializada na indústria de Tecnologia da Informação,nos indica que a
adoção de metodologias e processos em gerenciamento de projetos e a utilização de um Escritório de projeto será
um fator de competitividade das empresas em um futuro muito breve.
O termo Escritório de Gerenciamento de Projetos, do inglês Project Office, tem tido algum destaque no Brasil nos
últimos anos, em especial em 2004 e 2005. Esse tipo de estrutura já é largamente utilizado nas empresas dos
Estados Unidos e em outros países e o objetivo das empresas e organizações que adotam essa estrutura é a
melhoria da eficiência no planejamento e condução dos projetos.
Mas o que é o Escritório de Gerenciamento de Projetos?

Abaixo a figura demonstra o seu papel no alinhamento estratégico.
FIGURA 85 – O PAPEL DO EGP OU PMO NO ALINHAMENTO ESTRATÉGICO
Simplificando, o Escritório de Gerenciamento de Projetos é uma estrutura organizacional dedicada a desenvolver

uma disciplina para gerenciamento de projetos na empresa.
É curioso saber que o Escritório de Gerenciamento de Projetos, em especial para as empresas de TI, tomou mais
força devido ao chamado bug do milênio. Com a virada do milênio e com catástrofes possíveis imaginadas para os
sistemas ou equipamentos dependentes da informática, foram criadas estruturas nas empresas para a prevenção
dos problemas. De um único ponto da empresa, um grupo consolidou informações de todos os sistemas, todos os
equipamentos e demais fontes de problemas, acionou fornecedores e fez a preparação do ambiente evitando-se
os problemas da virada do ano.
Essas estruturas foram na sua grande maioria muito bem sucedidas nos seus objetivos. De acordo com o Gart-
ner Group, isso motivou às empresas a continuar com essa estrutura, para controlar os projetos que estavam
“espalhados” pelos departamentos da empresa. O Escritório de Gerenciamento de Projetos seria um lugar único
da empresa com visão dos projetos dentro da organização como um todo ou dentro do departamento (quando
restrito ao departamento de informática, por exemplo).
FIGURA 86 – PAPÉIS DO EGP
Portanto, nesta UIA, você vai aprender quais são as opções e decisões necessárias à implantação de Escritório de
Gerenciamento de Projetos, adequado as novas necessidades organizacionais, principalmente no contexto do PJe.
Também vai estudar e compreender as ferramentas que dão suporte ao comprimento da premissa de garantir a
operacionalização de um Escritório de Gerenciamento de Projetos e sua participação no alinhamento estratégico
projetos e negócios.
2. Definição
Existem diferentes nomenclaturas para um EGP, pois eles estão condicionados a diferentes níveis de autoridade e
funcionalidades. Um EGP que somente mede o desempenho dos projetos, sem prover expertise em gerenciamento
é denominado Escritório de Projetos. Porém, indiferente a qual nomenclatura utilizar, o EGP é definido e lançado
para melhorar os resultados provenientes do gerenciamento de projetos nas organizações.
FIGURA 87 – NOMENCLATURA PARA O EGP

Embora a nomenclatura mais utilizada para essa unidade seja Escritório de Gerenciamento de Projetos (EGP),
existem diferentes nomenclaturas adotadas pelas organizações, como Comitê Diretor de Projetos, Coordenação
de Projetos, Escritório de Apoio a Projetos, Grupo de Apoio à Gerência de Projetos.
Valeriano (2000) conceitua o EGP como uma organização formal destinada ao apoio à comunidade de gerencia-
mento de projetos em uma organização.
A definição mais simples do EGP é a que diz que ele é “um pequeno grupo de pessoas que têm relacionamento
com todos os projetos da empresa” e cita suas principais funções: prestar consultoria e treinamento, auditoria e
acompanhamento de desempenho.
O PMBOK (PMI, 2017) define EGP como sendo uma unidade organizacional que suporta o gerenciamento de proje-
tos na organização com o objetivo de servir de centro de excelência nas melhores práticas em gerenciamento de
projetos e atuar no alinhamento entre os projetos e as estratégias organizacionais.
Já Rad e Raghavan (2000) definem EGP como a entidade organizacional que provê o foco institucional nos proce-
dimentos de gerenciamento de projetos e na continuidade organizacional das experiências e lições aprendidas
durante o processo de gerenciamento de projetos. Além disso, facilita a integração das atividades de gerenciamento
de projetos com as políticas e procedimentos organizacionais, facilita a consistência freqüentemente desejada
nas políticas, procedimentos e ferramentas de gerenciamento de projetos e atua como um centro corporativo de
competência em gerenciamento de projetos.
Outro conceito de EGP, diz que ele é um provedor de serviços e processos completos para o gerenciamento de
projetos. Enfatiza-se esse conceito quando defini-se o EGP como um grupo de suporte que provê serviços para os
gerentes de projetos, gestores seniores e gerentes funcionais trabalhando em projetos, além disso, que o EGP não
substitui o gerente de projeto, apenas prepara informações e relatórios de apoio.
Bridges e Crawford (2001) definem EGP como sendo o provedor de infra-estrutura e suporte necessários para
“projetizar” a estrutura organizacional das empresas, que assim se voltaria para projetos e não para funções
departamentais.
As empresas procuram estabelecer Escritórios de Projetos que: “atuem como pontos focais para projetos, criem
consistência nas práticas de gestão de projetos, garantam as promessas de entregas dos projetos nos prazos e
orçamentos, permitam visualizar o cumprimento de prazos e resultados e, ao mesmo tempo, ‘isolem’ as organi-
zações desse ambiente de projetos”.
De forma consolidada, pode-se definir o EGP como sendo a entidade organizacional formalmente estabelecida
responsável por:
• Definir, uniformizar e defender padrões, processos, métricas e ferramentas de gerenciamento de projetos;
• Oferecer serviços de gerenciamento, treinamento e documentação de projetos;
• Garantir o alinhamento das iniciativas à estratégia organizacional;
• Receber os relatórios de progresso e acompanhamento dos projetos e enviar para os patrocinadores os

relatórios consolidados;
• Auxiliar a implementação das estratégias organizacionais.
E o que o EGP não é?
• Um chato que ficará “bisbilhotando” o gerente de projetos e fazendo micro-management

• Inspeção
• Um centro burocrático
• Um evento
• Uma função policial
• Focado em um departamento
• Somente mais uma nova “onda”...
3. Histórico
A evolução histórica do EGP começa como uma entidade relativamente bem definida desde meados dos anos 60,
nos grandes projetos militares, aeroespaciais e de construção civil. Podem-se denominar esses escritórios como
Escritórios de Controle de Projetos, pois os especialistas em projetos da época possuíam apenas funções de controle
e de ações corretivas, ou seja, o foco era a detecção e correção de problemas.
No final da década de 70 até meados da década de 80, com o surgimento dos primeiros softwares de gestão
“amigáveis”, o EGP mudou para expandir sua cobertura inicial para outros projetos de áreas diferentes, porém,
ainda isolados. Para isso, membros das áreas funcionais, não especialistas em projetos, foram alocados nos
escritórios que assumiram a função de suporte aos projetos.
No final da década de 80 e meados da década de 90, as ferramentas de gestão (e todas as demais ferramen-
tas computacionais) sofreram uma verdadeira revolução, facilitando o trabalho de controle e suporte dos EGP.
Com isso, gradativamente, o foco de atuação dos escritórios foi mudando de projetos relativamente simples e
isolados para um ambiente de multi-projetos e projetos complexos, de funções de controle e suporte para um
gerenciamento global e alinhado com as estratégias organizacionais .
Abaixo os fatores motivadores para implementação de um EGP:
• Uniformização de ferramentas, técnicas, formulários e termos de Gerenciamento de Projetos;
• Aumento da taxa de sucesso dos projetos quanto a tempo, custo, requisitos e qualidade, com impacto
direto na capacidade de trabalho da organização;
• Maior alinhamento entre o Planejamento Estratégico e o Gerenciamento de Projetos por meio da governança
corporativa dos programas e projetos;

• Maior facilidade na capacitação dos gerentes de projetos através de competências da própria organização;
• Disponibilização de informações sobre os projetos da organização para a alta administração.
Abaixo a figura resume a evolução histórica do EGP:
FIGURA 88 – EVOLUÇÃO HISTÓRICA DO EGP
4. O Papel do EGP na Gestão Estratégica

Existe uma forte ligação entre a origem dos projetos e as metas capazes de atender a estratégia de negócio da
organização. Cada projeto está associado a uma meta, e para prover o gerenciamento destes projetos de forma
a alinhá-los ao atendimento das metas estratégicas, é necessária uma coordenação centralizada promovida
e controlada por um EGP, que para atingir o objetivo do alinhamento estratégico com os projetos deve ter as
seguintes responsabilidades:
• Tornar a empresa mais ágil no sentido de aceitar mudanças;

• Garantir um maior alinhamento dos projetos com os negócios da organização;
• Consolidar o uso de uma linguagem uniformizada em toda a organização;
• Participar dos desdobramentos de metas no que se refere a projetos;
• Acompanhar a aquisição das metas corporativas como resultado da execução dos projetos e programas;
• Avaliar a aderência dos projetos de cada EGP setorial às prioridades e metas da organização;
• Cuidar da gestão do conhecimento, ou seja, do registro e disseminação do conjunto de processos que
tornam o gerenciamento de projetos uma boa prática.
Light e Berg (2000) delimitam o assunto do papel do EGP no alinhamento da estratégia com os projetos da organi-
zação, que tem o papel de dar um suporte consistente e disciplinado para seleção, priorização e gestão de recursos
dos projetos para mitigar os riscos da dependência dos negócios.
O EGP é uma unidade organizacional com a competência de integrar o gerenciamento de projetos dentro de
uma organização. Um EGP é um recurso chave em estabelecer a competência organizacional em análise, design,
gerenciamento e revisão de projetos. É um centro de competência que provê a expertise ao projeto para atender
as necessidades do negócio.
5. O Valor do EGP para uma Organização

O objetivo dos EGP é atuar como centro de excelência das melhores práticas em gerenciamento de projetos e atuar
no alinhamento entre os projetos e as estratégias organizacionais. Esse último objetivo tem importância significa-
tiva para a Governança Corporativa, pois implementa uma de suas diretrizes principais, que é o alinhamento entre
projetos e negócios e consiste em uma das principais fontes do sucesso de um EGP.
Barcaui (2003) relata que os EGP atuantes em organizações brasileiras não possuem um consenso sobre qual o
valor de um EGP. No entanto, aponta um fator que está faltando para garantir e aumentar o valor dos EGP, que é
a falta de alinhamento estratégico com os objetivos da organização.
Analistas da indústria enfatizam a importância em se estabelecer um EGP para implementar e enraizar a padro-
nização das práticas de gerenciamento de projetos.
Organizações que implantam um EGP experimentam a metade de desvios negativos em relação ao que é planejado
e realizado em termos de orçamento e tempo de seus projetos comparado com as que não tem, embora, não exista
nenhum modelo empírico para comprovar este fato.
Não se tem encontrado no meio acadêmico pesquisa que explore a relação entre a existência de um EGP e o uso
de melhores práticas específicas de gerenciamento de projetos e o aumento do sucesso dos projetos, após a
implantação do EGP. Portanto, há uma carência no meio acadêmico de pesquisas que explorem a importância de
um EGP e que provem empiricamente seus benefícios para a organização que o instalou.
Quanto mais próximo estiver o foco de atuação do EGP, maior valor ele terá para a organização que está inserido, ou
seja, quanto maior for a sua contribuição para a aquisição da visão estratégica do negócio por meio do aumento
da taxa de sucesso dos projetos que materializam essa estratégia.
Por outro lado, quanto mais próximo ele estiver do operacional, o seu valor estará vinculado a ganhos operacionais
como redução de custos dos projetos, diminuição dos estouros do cronograma, dentre outros.
Apesar do ganho da atuação do EGP no nível operacional, é na atuação estratégica que ele consegue gerar um
retorno mais significativo para a organização, e esse é um desafio dos, fazer com que a sua atuação viabilize o
que foi pré-definido no planejamento estratégico por meio da execução alinhada com a estratégia dos projetos, e
conseqüentemente fazendo com que os projetos estejam alinhados às estratégias de negócios.

6. Os Tipos de EGP
Os tipos de EGP em escritório de controle de projetos, que tem como função primordial a monitoração das variáveis
do (s) projeto (s), o escritório de projetos de uma área de negócios que tem por objetivo atuar como catalisador
da execução dos objetivos de negócios dessa área por meio de projetos e o escritório estratégico de projetos que
é responsável por transmitir as estratégias da organização à execução de todos os projetos dessa organização.
Outros autores definem os tipos de EGP como sendo: escritório de nível 1, que atua como uma espécie de estação
meteorológica monitorando o “tempo” dos escritórios de projetos, mas sem influenciar na condução dos mesmos;
escritório de nível 2, que atua como uma torre de controle para monitorar e influenciar a condução dos projetos e
o escritório de nível 3, que atua como um centro de recursos com autoridade de priorizar e selecionar os projetos
mais importantes para atender a estratégia da organização em dado momento.
Abaixo as figuras representam uma analogia aos tipos do EGP:
FIGURA 89 – ANALOGIA TIPOLOGIA EGP
FIGURA 88 – RELAÇÃO FOCO E TIPO DE EGP
Os dois fatores que modelam os EGP são as responsabilidades e a autoridade, com isso, ele descreve os tipos mais
comuns de EGP:
1) O Centro de Excelência: tem como objetivo principal manter e prover os padrões de gerenciamento de pro-
jetos e promover sua utilização em uma organização. Eles devem atuar como agentes de mudança em
todos os níveis organizacionais;
2) O Escritório de Apoio a Projetos: além de manter os padrões e práticas de gestão de projetos, apoia ativa-
mente um projeto por meio da execução de tarefas operacionais inerentes a gestão de projetos;
3) O Escritório de Gerenciamento de Programa: fornece o conhecimento técnico de todo o programa e dá

suporte na monitoração das principais baselines do programa, como tempo, custo e escopo.
Também se tipifica os EGP como sendo Escritório de Suporte de Projetos responsável pela padronização das melho-
res práticas em gerenciamento de projetos e como fonte de experiência e competências em práticas de gestão;
o Escritório de Projetos e Programas que atua exclusivamente dando apoio pontual a projetos e programas e o
Escritório de Governança de Projetos que tem como objetivo principal assegurar o alinhamento dos projetos e
programas à estratégia de negócios.
Kendall e Rollins (2003) identificam os tipos de EGP por modelos distintos, mas também definem como sendo três
os modelos de EGP, são eles:
• Modelo de Repositório de Projetos: serve como uma fonte de informação da metodologia de projetos e em
padrões, ferramentas para a modelagem, gerenciamento e reporte do projeto. Este modelo é empregado
de forma descentralizada, ou seja, atua no espectro de um projeto ou programa;
• Modelo de Coaching de Projetos: é uma extensão do modelo de repositório de projetos e atua através dos
projetos de um departamento divulgando as melhores práticas e melhorando a performance da estratégia;
• Modelo Estratégico de EGP: sua missão implica na avaliação de escopo, alocação de recursos e verificação
de tempo, orçamento, risco. E atua em diversos times de projetos dando suporte para a completude
do trabalho.
Os outros tipos definidos abaixo são limitados a duas categorias de atuação dos EGP, o focado em um projeto ou
o orientado a estratégia. Abaixo a figura demonstra a diferença entre esses tipos.
QUADRO 10 – CATEGORIAS DE EGP
Focado em Projeto Orientado a Estratégia
Consultoria de gestão Expansão de utilização de melhores práticas
Mentoring (treinamento durante a ação) Gerenciamento do Portfólio de Projetos
Gestão de Documentação Treinamento e Capacitação
Monitoramento do custo e orçamento do projeto Quantificação dos objetivos dos projetos para
melhoria da performance da estratégia

Por final, Dinsmore (2003) divide os tipos de EGP em Escritório Autônomo de Projeto, que atua exclusivamente
dando suporte a um projeto em específico, o Escritório de Suporte de Projeto que dá apoio ao planejamento e
controle de diversos projetos simultâneos e o Escritório de Programa de Projetos ou Centro de Excelência, que é
corresponsável pelo sucesso de projetos de uma organização. Ele também posiciona estes tipos de EGP em níveis
de atuação organizacional, categorizando-os em nível 1, nível 2 e nível 3, vide figura abaixo.
FIGURA 89 – DIVERSOS NÍVEIS DO EGP
Como visto atrás, a maior parte dos autores definem a tipologia dos EGP em três diferentes tipos. Essas tipologias
têm em comum a distinção dos EGP baseada nos diferentes graus de responsabilidade, autoridade, funções e
posicionamento organizacional. Apesar da diferenciação em termos de nomenclatura, as funções, responsabili-
dades e posicionamento desses EGP nos níveis organizacionais permanecem semelhantes. Para o foco desta UIA
consideraremos a seguinte tipologia e nomenclatura e seus posicionamentos nos níveis organizacionais:
> EGP de nível 1
> EGP de nível 2
> EGP de nível 3
I – O EGP DE NÍVEL 1
O EGP de nível 1 surge da necessidade de um controle mais efetivo das variáveis de projetos ou programas gran-
des e complexos. Ele é responsável pela gestão das atividades operacionais do projeto e não tem autoridade de
influenciar na condução desse projeto.
Esse tipo de EGP atua controlando as atividades cotidianas do projeto para auxiliar aos gerentes de projetos a
assegurar a monitoração das metas e baselines como as de escopo, tempo e custo com o intuito de alcançar os
resultados estipulados anteriormente para o projeto.
As funções mais comuns definidas para o EGP de nível 1 estão relacionadas abaixo:
• Controlar a qualidade das entregas do processo de gerenciamento dos projetos, como o plano do projeto,
plano de gerenciamento de escopo do projeto;
• Manter uma base de dados de ações históricas e lições aprendidas;
• Confeccionar relatórios de progresso do projeto;
• Confeccionar relatórios de monitoramento dos riscos identificados do projeto;
• Avaliar o risco do resultado do relatório de progresso dos projetos;
• Avaliar o cumprimento de baselines (escopo, tempo e custo) do resultado do relatório de progresso

dos projetos;
• Identificar precocemente issues e potenciais estouros de baselines;
• Apoiar o controle de mudança do projeto;
• Suportar a ferramenta de software de gerenciamento de projetos;
• Gerenciar contratos e suprimentos;
• Gerenciar documentação;
Em termos de posicionamento em uma dada estrutura organizacional, o EGP de nível 1 estaria abaixo do gerente
de projeto, assim como ilustrado abaixo:
FIGURA 90 – MODELO DE EGP NÍVEL 1

II – O EGP DE NÍVEL 2
O EGP de nível 2 atua no nível gerencial de uma empresa, abaixo do gerente de uma área ou departamento
específico. Está acima dos gerentes de projeto, em um nível tático departamental e tem visibilidade de todos
os projetos dessa área ou departamento. O EGP de nível 1 reporta-se ao EGP de nível 2.
Esse EGP atua no alinhamento dos projetos da área e é um centro de referência em gerenciamento de pro-
jetos para esses. Ele consolida os resultados da atuação do EGP de nível 1 e quando da ausência desse na
organização ele executa as atividades pertinentes ao nível 1, porém sua atuação extrapola os domínios dos
projetos e em linhas gerais diferencia-se do EGP de nível 1 por ter autoridade de influenciar na condução dos
projetos dessa área. Afirma-se que essa influência pode ser notada através da possibilidade de se implantar
um padrão de excelência em gerenciamento de projetos na área, ou seja, todos os projetos dessa área terão
que seguir esse padrão, caracterizando então a influência da atuação do EGP de nível 2 nos projetos da área
ou departamento.
Abaixo algumas funções definidas para o EGP de nível 2:
• Estabelecer e verificar o cumprimento de padrões e metodologia comuns aos projetos;
• Estabelecer e verificar o cumprimento de métricas e indicadores comuns aos projetos;
• Definir padrões de ferramentas em gerenciamento de projetos;
• Verificar o cumprimento dos padrões e métricas de gerenciamento de projetos;
• Controlar e armazenar as lições aprendidas e outros elementos e relatórios gerados pelos projetos;
• Definir, implementar e controlar mecanismos de controle de mudanças;
• Assumir o papel de mentor em projetos ou programas com problema;
• Promover a capacitação em gerenciamento de projetos;
• Elaborar e manter os procedimentos de planejamento de recursos dos projetos;
• Gerir a satisfação dos stakeholders dessa área ou departamento;
• Manter os procedimentos do ciclo de iniciação, planejamento, controle, execução e fechamento dos projetos;
• Prover análise e relatórios consolidados dos projetos;
• Analisar os riscos consolidados dos projetos;
• Prover o mentoring aos gerentes de projetos em relação à utilização de melhores práticas em gerencia-
mento de projetos;
• Prover o mentoring aos gerentes de projetos em relação à identificação de problemas e propostas de

soluções dos projetos.
Em termos de posicionamento em uma dada estrutura organizacional, o EGP de nível 2 estaria abaixo do gerente
de uma área, assim como ilustrado abaixo:
III – O EGP DE NÍVEL 3

O EGP de nível 3 atua mais próximo da camada diretiva de um departamento ou no nível corporativo de uma
organização, definindo diretrizes metodológicas gerais, políticas, padrões e principalmente alinhando os objetivos
estratégicos da corporação ou de um departamento com a execução dos projetos dessa organização ou depar-
tamento. Além disso, auxilia e monitora os EGP de níveis 1 e 2.
A principal diferença entre um EGP de nível 2 e um de nível 3 está na relação e visibilidade desse último com as
estratégias definidas por essa organização ou departamento, no que tange à responsabilidade de manter ali-
nhados a execução e entregas desses projetos com essas estratégias. A atuação tática de um EGP de nível 2 não
dá autoridade e visibilidade para que o mesmo atue de maneira estratégica, definindo priorizações de projetos
segundo perspectivas estratégicas, definição de indicadores e metas, provendo a seleção de projetos mais prioritá-
rios dado uma conjuntura de mercado, dentre outras. Só uma unidade, como o EGP de nível 3, com atuação diretiva
departamental ou corporativa possui autoridade para desempenhar essas funções de cunho mais estratégico.
Existe uma forte ligação entre a origem dos projetos e as metas capazes de atender a estratégia de negócio da
organização. Cada projeto está associado a uma meta, e para prover o gerenciamento destes projetos de forma
a alinhá-los ao atendimento das metas estratégicas, é necessária uma coordenação centralizada promovida e
controlada por um EGP estratégico, que para atingir o objetivo do alinhamento estratégico com os projetos deve
ter as seguintes responsabilidades:
• Tornar a empresa mais ágil no sentido de aceitar mudanças;
• Garantir um maior alinhamento dos projetos com os negócios da organização;
• Consolidar o uso de uma linguagem uniformizada em toda a organização;

• Participar dos desdobramentos de metas no que se refere a projetos;
• Acompanhar o atendimento das metas corporativas como resultado da execução dos projetos e programas;
• Avaliar a aderência dos projetos de cada EGP setorial às prioridades e metas da organização;
• Cuidar da gestão do conhecimento, ou seja, do registro e disseminação do conjunto de processos que

tornam o gerenciamento de projetos uma boa prática.
Algumas funções definidas para o EGP de nível 3 estão relacionadas abaixo:
• Define o portfólio de projetos;
• Prover o gerenciamento do portfólio de projetos;
• Define os programas e projetos mais estratégicos;
• Suporte ao gerenciamento de programas;
• Prover o estudo de viabilidade dos projetos
• Prover o acompanhamento do desempenho da viabilidade dos projetos;
• Prover o status consolidado dos projetos;
• Prover avaliação a respeito do status consolidado dos projetos;
• Gerir a satisfação dos patrocinadores dos projetos;
• Prover a seleção de projetos;
• Prover a priorização de projetos;
• Prover a centralização e monitoração do orçamento destinados aos projetos;
• Prover a revisão de projetos;
• Apoiar o desenvolvimento das carreiras dos gerentes de projeto;
• Atuar como um centro de gestão do conhecimento dos projetos;
• Prover o alinhamento dos projetos de um departamento ao planejamento estratégico desse departamento;
• Definir os procedimentos de priorização de projetos;
• Prover a padronização da metodologia de gerenciamento de projetos;
• Prover a otimização de utilização de recursos humanos entre os projetos por meio de realocação.
Em termos de posicionamento em uma dada estrutura organizacional, o EGP de nível 3 estaria abaixo do Diretor
de um departamento ou do Presidente de uma organização, assim como ilustrado abaixo:
7. Diretrizes para um EGP Estratégico

Nesta Seção, apresenta-se as diretrizes para um EGP estratégico. As diretrizes do EGP estratégico são compostas
pelos seguintes pilares: um mandato para o EGP; o patrocínio da alta administração; uma infraestrutura de pessoal
e ferramental; um sistema de gerenciamento estratégico; e um sistema de medidas de seu sucesso.
Abaixo, encontra-se o arcabouço dessas diretrizes:
QUADRO 11: ARCABOUÇO DAS DIRETRIZES DO EGP ESTRATÉGICO.
Pilares das Diretrizes Descritivo
O constitui como unidade organizacional, com atribuições e funções e conces-

são de autoridade para sua atuação. Além disso, define o seu posicionamento
Mandato para o EGP
organizacional como sendo vinculado diretamente ao posto gerencial máximo
dentro da organização.
Patrocínio da alta Constitui-se como premissa essencial para assegurar a atuação estratégica do
administração EGP, pois formaliza a sua autoridade perante a organização

Pilares das Diretrizes Descritivo
Consolida a sua operacionalização, por meio da definição de suas posições

Infraestrutura para o EGP internas que se constituem por profissionais com visão estratégica, por uma
ferramenta tecnológica que dê suporte às suas atribuições e funções.
Direciona o EGP a atuar com foco na gestão estratégica. Para elaboração do sis-
Sistema de gerenciamento
tema utiliza-se o Balance Scorecard, e consequentemente gera-se um produto
estratégico
fruto da customização do BSC para o EGP, o qual denomina-se Scorecard do EGP.
Constituem-se como um conjunto de medidas formadas por indicadores pro-

Medidas de sucesso venientes das perspectivas do Scorecard do EGP e tem como objetivo manter o
EGP no foco da estratégia.
A Figura abaixo sumariza a composição e interação dos pilares das diretrizes do modelo de EGP estratégico.
FIGURA 93 – ARCABOUÇO DAS DIRETRIZES DO EGP ESTRATÉGICO
8. Resumo
Você viu nessa UIA uma abordagem conceitual com diversas definições e sua consolidação; histórico da evolução
dos EGP; tipos e suas funções; fatores que motivam, que podem gerar fracasso e sucesso para implementação de
um EGP; e por último, diretrizes de um EGP estratégico que visa principalmente o alinhamento entre os projetos e
o negócio da organização.
Veja, na leitura complementar 4, Perfil de Escritórios de Gerenciamento de Projetos em Organizações Atuantes no

Brasil, um panorama da atuação dos EGP em nosso contexto.
ANEXOS
Program and Project Management: Understanding the Differences
By:
Russ Martinelli - Intel Corporation
Jim Waddell - Tektronix, Inc.
Introduction
It is quite common for the terms “program management” and “project management” to be used
interchangeably. Unfortunately, this serves to reinforce the misunderstanding of the distinctions between
the two disciplines, and to overshadow the importance of program management in the achievement of
business objectives. Volumes have been written about project management in the past two decades, but
little has been written about program management besides an occasional vague reference to program
management as the “management of multiple projects” (or worse yet, writings that confuse program
management with portfolio management). Viewing program management from a project management
mindset in order to make it fit the project paradigm is a fundamental flaw in thinking, but one that is
pervasive across many industries.
In the paper "Program Management: Linking Business Strategy to Product and IT Development"1, we
discussed program management as a proven discipline which effectively links multiple project outputs
to strategic business objectives. In this article we will dive deeper on this subject by describing the
distinction between the strategic nature of program management and the tactical nature of project
management, demonstrating what it really means to "manage multiple projects", and how program and
project management are utilized in conjunction to deliver high impact products in the high technology
industry.
Program and Project Management
Program management and project management are related but distinctly different disciplines. It is
important for everyone within the organization to understand the distinction between the two in order to
link project output to business strategy and to integrate the efforts of multiple project teams to achieve a
common set of business goals.
We feel the three most important distinctions between program and project management are the
following:
1. Program management is strategic in nature, while project management is tactical in nature. Within
our companies, Intel Corporation and Tektronix, Inc., program management focuses on
achievement of the intended strategic business results through the coordination of multiple
projects. Project management in contrast focuses on the tactics of planning and execution of the
work output. With this, program managers must augment their project management and technical
skills with core business, strategic and leadership skills.
2. Program management is entirely cross-functional, while project management focuses on a single
function, or limited cross-functional alignment at best. It is typical for the program manager to
manage across the various functions of an organization such as engineering, marketing, finance,
validation and customer support. Project managers typically manage a team within one of the
functions on the program.
Page 1 of 6

3. Program management integrates the individual elements of the projects in order to achieve a
common objective. Later in this article we will demonstrate how the work effort and deliverables
from multiple project teams such as hardware development, software development, mechanical
development and manufacturing are integrated to develop and launch a new personal computer
product.
Additional distinctions between program and project management are shown in Table 1.
Table 1: Program Management vs. Project Management
Delivering the "Whole Product"
To explore further, let's consider the concept of the "whole product". The program management function
is responsible for the delivery of the whole product to the customer and for achievement of the intended
business results, such as product quality, increased revenue and market share. The project management
function is responsible for the delivery of a single element of the whole product, and for ensuring the
delivered element integrates with all other elements. For example, Figure 1 shows five primary elements
involved in the development of a personal computer product. Other functions such as system
architecture, product marketing, quality, customer support and finance are not shown for the sake of
simplicity.
Page 2 of 6
Figure 1: Personal Computer Development Program
The program manager is responsible for the delivery of the whole product to the market. In this case, the
whole product would be the personal computer consisting of the integration of the various circuit
boards, the enclosure, the software stack, and the test, validation and manufacturing of the product. In
addition to delivery of the product, the program manager is responsible for the achievement of the
business objectives for which the product development effort was initiated. Examples would include
timely market introduction of the server, gross margin targets and key customer design wins.
The project managers are responsible for the delivery of a single element of the product to the program
team. For example, the software project manager is responsible for the development and integration of
the software stack embedded in the personal computer, the circuit board project manager is responsible
for the development and integration of the various circuit boards, (motherboard, memory board and
power distribution board), the enclosure project manager delivers the computer chassis including the
power and cooling elements, and the manufacturing project manager is responsible for the factory build
of the computer.
Figure 1 illustrates how the program manager manages across the various projects, whereas the project
manager manages within a single function or domain.
Managing Multiple Projects
As stated previously, program management is commonly referred to as the management of multiple

projects however, this broad definition can mean many things. We define program management as the
coordinated management of interdependent projects over a finite period of time to achieve a set of
business goals. The key words in this definition are coordinated, interdependent and business goals.
Coordinated management of multiple projects means that the activities for each project are synchronized
through the framework of a common lifecycle executed at the program level. If an organization is using
a phase-gate lifecycle model for example, all projects within the program pass through the phases and
gates simultaneously. Program management ensures the effective coordination and synchronization of
the multiple projects through the lifecycle.
Page 3 of 6

As the term implies, interdependent projects are those that have a mutual dependence on the output of
other projects in order to achieve success. Said another way, the successful completion of deliverables
from one project is needed for the successful completion of other projects. Program management
ensures the dependencies between the multiple projects are managed in a concerted manner. Using the
previous computer development example, the circuit board development project team cannot achieve the
motherboard power-on milestone without the successful completion of the BIOS (Basic Input-Output
System) software and the firmware deliverables from the software project team - both of which are
required to initiate the motherboard power-on sequence. The software project manager focuses on
delivery of the software functionality as scheduled, while the program manager ensures the schedules
for the circuit board and software teams remain in synch and that both teams agree on what is to be
delivered and when.
Managing multiple interdependent projects also requires the integration of the project planning and
execution activities at the program level. Figure 2 illustrates how plans for multiple projects are created
from the program definition and WBS (Work Breakdown Structure), and then integrated into an
interdependent, cohesive program plan
Figure 2: Integrating Project Plans into a Program Plan
Once the program definition and requirements are established for the "whole product", the program level
WBS (Work Breakdown Structure) can be created. A WBS for each project is then created from the
program WBS to define the work required from each project in order to achieve the deliverables. A plan
is then created for each project to develop and deliver each respective element of the product to the
program team. The project plans are then integrated into a program plan, within which the
interdependencies and intermediate deliverables between the project teams are defined and negotiated.
Page 4 of 6
During the implementation of the program, the project managers ensure execution of their respective
project plan, while the program manager ensures the implementation of all projects is occurring in
concert and that the interdependencies and inter-project deliverables are occurring as defined in the
program plan.
Accomplishment of the stated business goals is the ultimate responsibility of the program manager. In
product development, a key goal of the program is to deliver the whole product to the market. Delivery
of the right product at the right time is critical; however it is really only the mechanism to realize the
true business goals such as capturing additional market share, increasing profit through sales and gross
margin, and strengthening brand value through quality, features and customer support. Program
management is the business process that not only develops and delivers the product but also ensures the
project teams are focused on activities that contribute to achievement of the business goals. For
example, the program manager ensures that the design wins and sales projections from the marketing
team remain above minimum levels and that the engineering and manufacturing teams keep the product
and manufacturing costs at target levels or below in order to achieve the gross margin necessary to hit
the profit goals.
The Program Hierarchy
Figure 3 illustrates the hierarchy that is established on a product development program, as well as the
primary areas of responsibility between the program management and project management disciplines.
The program manager leads the product development effort and is responsible for defining the program
strategy to achieve the intended business objectives. The program manager also owns the program level
WBS and program plan, as well as the creation and accomplishment of the program success criteria. The
project managers lead the personnel on their respective functional project team. These may be large
teams depending upon the size and complexity of the product development effort. Each project manager
reports to the program manager and serves as a member of the program leadership team, commonly
referred to as the program core team. The project managers are responsible for the development and
execution of their project plan and for delivery of their element of the whole product. As members of the
program core team, the project managers also assist the program manager in the development and
execution of the integrated program plan.
Page 5 of 6

Figure 3: Program Hierarchy
Conclusion
This article addresses our view that even though the terms program management and project
management are often used interchangeably, they are related but distinctly different disciplines. The
primary differences being: program management is strategic in nature while project management is
tactical in nature, program management is entirely cross-functional while project management focuses
on a single function, and program management integrates the individual elements of the projects to
achieve a common objective, such as the delivery of the "whole product" to the marketplace. Program
management is a key business process utilized by Intel and Tektronix to manage complex product
development efforts that consist of multiple interdependent projects. Employing both program and
project management is a powerful approach to developing products that enable the achievement of
intended business objectives.
References
1 PM World Today, Volume V Issue 7, September-October 2003
Page 6 of 6
Aperfeiçoamento de

Projeto Gestão de Portfólio PDPJ Livro 2 de 3 em 18-03-21

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projeto Gestão de Portfólio PDPJ Livro 2 de 3 em 18-03-21

Enviado por

Direitos autorais:

Formatos disponíveis

Centro de Formação e

GESTÃO DE PORTFÓLIO, PROGRAMAS E PROJETOS

Corregedora Nacional de Justiça

Secretário Especial de Programas,

SECRETARIA DE COMUNICAÇÃO SOCIAL

Secretário de Comunicação Social

GESTÃO DE PORTFÓLIO, PROGRAMAS E PROJETOS

Cada Unidade de Interação e Aprendizagem (UIA) contém:

• Em cada UIA, são apresentados, links relacionados ao conteúdo apresentado

• As citações autor-data utilizadas ao longo do conteúdo, estão destacados em azul.

• Os termos contidos no glossário, estão destacados em amarelo.

• E os links para as leituras complementares, estão destacados em rosa.

UIA 1 | CONTEXTO DOS PROCESSOS, GERENCIAMENTO DE ESCOPO E DA INTEGRAÇÃO DOS PROJETOS 13

UIA 2 | GERENCIAMENTO DO TEMPO E DO CUSTO DOS PROJETOS 41

UIA 3 | GERENCIAMENTO DA QUALIDADE, COMUNICAÇÃO E RECURSOS HUMANOS DOS PROJETOS 57

UIA 4 | GERENCIAMENTO DAS AQUISIÇÕES E RISCOS DOS PROJETOS 73

UIA 5 | EXECUÇÃO, MONITORAMENTO E CONTROLE DE PROJETOS PDPJ-Br 91

UIA 6 | ENCERRAMENTO DE PROJETOS PJe 111

UIA 7 | GERENCIAMENTO DE PROGRAMAS E PORTFÓLIO PDPJ-Br 123

UIA 8 | ESCRITÓRIOS DE GERENCIAMENTO DE PROJETO (PMO) 133

O principal objetivo é modernizar a plataforma do Processo Judicial Eletrônico e transformá-la em um sistema

Destaca-se como pontos principais:

E tem por objetivos:

Seus requisitos de sistemas são:

I - padrões de desenvolvimento, documentação e operação de software;

II - padrões de comunicação e interoperabilidade entre sistemas e aplicações;

III - arquitetura de desenvolvimento e de infraestrutura;

V - permissão para o desenvolvimento compartilhado;

VII - disciplina da plataforma única para os modelos de I.A;

VIII - delimitação dos critérios e serviços para computação em nuvem;

Seus requisitos de dados e documentos:

I - padrões das tabelas unificadas;

II - possibilidade de bases centralizadas ou descentralizadas, sempre uniformes;

III - padrões de dados mínimos para o atendimento da Lei nº 13.709/2018;

IV - padrões de documentos digitais;

V - padrões de assinaturas digitais.

A gestão da PDPJ é baseada em:

• PJe será mantido e aprimorado capitaneando a nova Plataforma;

• Rastreamento proporcional de custos da nuvem nacional.

As formas de participação e colaboração são:

• Quem pode colaborar?

• Como habilitar a instituição como colaboradora?

Quais as formas de colaboração?

• Fornecer pessoal técnico para participar de desenvolvimento de serviços da plataforma;

• Formar equipe interna para desenvolver serviços para a plataforma;

• Juntar-se a outra instituição habilitada para desenvolver soluções para a plataforma;

• Formar equipes de homologação de serviços;

• Formar equipes especializadas em regras de negócio;

Qual o papel do CNJ no desenvolvimento dos projetos?

• Promovendo capacitações e eventos que promovam a integração e nivelamento de conhecimento

• Fornecendo ferramentas de colaboração para gestão e sustentação do desenvolvimento da plataforma

• Gerenciando o processo de designação de equipes e acompanhamento geral do projeto;

• Divulgando as ações e iniciativas em execução no contexto da PDPJ.

Como entregar um serviço?

Contexto dos Processos de Gerenciamento de Projetos

1.1. CICLO DE VIDA

1.1.1. Ciclo de Vida de um Produto

FIGURA 1 – PROJETOS NO CICLO DE VIDA DE UM PRODUTO

Fonte: Alinhado ao PMBOK, 2017

1.1.2. Ciclo de Vida de um Projeto

FIGURA 2 – CAMINHOS DO GERENCIAMENTO DO PROJETO

Fonte: Alinhado ao PMBOK, 2017

FIGURA 3 – ESFORÇO DO GERENCIAMENTO DE PROJETOS EM PROJETOS PEQUENOS