Equipe MeuBizu

“Aprenda e aprenda rápido”

Tópicos dessa aula:
3 Gestão de projetos: 3.1 Conceitos básicos. 3.2 Processos do PMBOK. 3.3 Gerenciamento da
integração, do escopo, do tempo, de custos, da qualidade, de recursos humanos, de
comunicações, de riscos, de aquisições, de partes interessadas. 3.4 Metodologias ágeis.
1. PMBOK – Conceitos Básicos
Um conjunto de conhecimentos é indicado, em inglês, pela sigla BOK (Body Of Knowlege). Como
a compilação era para o conjunto de conhecimentos ligados ao gerenciamento de projetos, esse
BOK ficou conhecido como PMBOK (Project Management Body of Knowledge)
O PMBOK, por definição, cobriria todos os conhecimentos de gerenciamento de projetos.
Contudo, o que existe é o chamado “Guia PMBOK”, o qual na verdade trata apenas de parte
desse conhecimento. Na prova e no dia a dia é comum não fazer essa diferenciação. Contudo,
guarde que o Guia PMBOK (ou simplesmente, o PMBOK) registra um subconjunto de
conhecimentos em gerenciamento de projetos, pois registra somente boas práticas.
Boa prática significa que existe um acordo geral de que a aplicação do conhecimento,
habilidades, ferramentas e técnicas podem aumentar as chances de sucesso de muitos projetos
em entregar o valor de negócio e resultados esperados. Boas práticas são aquelas reconhecidas
pela maioria da comunidade de gerenciamento de projetos.
Reconhecimento geral significa que o conhecimento e as práticas descritas são aplicáveis à
maioria dos projetos na maior parte das vezes, e que existe um consenso em relação ao seu
valor e utilidade.
O Guia PMBOK não é uma metodologia. Uma metodologia diz o passo a passo. Ou seja, diz
exatamente como se deve proceder. O Guia PMBOK é apenas descritivo. Ou seja, ele cataloga
boas práticas. Nada que está no guia é obrigatório. Repito. Nada é obrigatório.
O Guia do PMBOK pode ser adotado por qualquer tipo de organização. Ele pode ser adotado
por empresas que visam lucro, por sociedades filantrópicas, por grandes empresas, por
pequenas empresas, por organizações públicas, por organizações privada, etc. Por que? Porque
todas estas empresas possuem projetos e têm interesse em gerenciá-los.
Os diversos conceitos de gerenciamento de projetos podem variar de uma empresa para outra.
Isso gera problemas de comunicação. Por isso, o PMBOK tem um papel unificador. Ele patrocina
o uso de um vocabulário comum. Em outras palavras, o PMBOK cria um jargão padronizado para
a profissão de gerenciamento de projetos.
O PMI publica um Código de Ética e Conduta Profissional que deve ser seguido pelos
professionais certificados. O código também alcança os membros e voluntários do PMI.
Definição de Projeto
Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado
único.
Um projeto é temporário. Isso significa que tem início e fim definidos. Ou seja, tem data para
começar e data para terminar. Contudo, isso não quer dizer que um projeto não possa atrasar.
Aliás, na prática, é comum que os projetos sofram atrasos, pois há muitas variáveis que somente
são desvendadas ao longo do projeto.
A temporalidade é uma característica que diferencia os projetos das operações. As operações
tratam do dia a dia da organização, já os projetos entregaram algo único. Outro ponto
importante é que a natureza temporária não significa necessariamente que o projeto seja de
curta duração. Não há um prazo que determine se um empreendimento é ou não um projeto.
Um projeto pode demorar 1 mês ou 20 anos.
Apesar dos projetos serem temporários, suas entregas podem existir depois do encerramento
do projeto. Por exemplo, um projeto de construção de um monumento nacional (por exemplo,
o cristo no Rio de Janeiro).
O objetivo final de um projeto pode ser resultado (por exemplo, alcance de uma nova posição
no mercado), um produto (por exemplo, um novo modelo de carro em uma empresa de
automóveis) ou serviço (por exemplo, um novo sistema de troca de mensagens).
Conceito de Entrega
Uma entrega é definida como qualquer produto, resultado ou capacidade única e verificável que
deve ser produzido para concluir um processo, fase ou projeto.
Quando um projeto termina ?
Podemos considerar que o final do projeto é alcançado quando ocorrer um ou mais dos fatores
a seguir:

• Os objetivos do projeto foram alcançados;

• Os objetivos não serão ou não poderão ser cumpridos;
• Os recursos estão esgotados ou não estão mais disponíveis para alocação ao projeto;
• A necessidade do projeto não existe mais (por exemplo, o cliente não quer mais o
projeto concluído, uma mudança de estratégia ou prioridade encerram o projeto, o
gerenciamento organizacional fornece uma instrução para terminar o projeto);
• Recursos humanos e físicos não estão mais disponíveis; ou
• O projeto é finalizado por motivo legal ou por conveniência
Operações

Nem só de projetos vive uma organização. Na verdade, grande parte das atividades de uma
organização envolve atividades contínuas e repetitivas. Essas atividades é que mantém a
organização funcionando. São as atividades do dia a dia. Tais atividades são chamadas pelo Guia
PMBOK de operações.
As operações são contínuas (não são temporárias) e repetitivas (não são únicas). Ou seja,
envolvem trabalho recorrente e sem data de término. Além disso, o objetivo das operações é
manter a organização funcionado. Por exemplo, atividade de fazer o pagamento dos salários dos
empregados, ocorre todos os meses, é uma operação e não um projeto.
Elaboração Progressiva
Projetos são complexos e não é possível prever todos os detalhes desde o início. As
características do produto evoluem gradualmente ao longo do tempo, em um processo chamado
de elaboração progressiva (ou Rolling Wave Planning). O gerente de projetos utiliza o Rolling
Wave Planning para refinar o planejamento à medida que o projeto avança.
Stakeholders (Partes Interessadas)
Uma parte interessada é um indivíduo, grupo ou organização que pode afetar, ser
afetada ou sentir-se afetada por uma decisão, atividade ou resultado de um projeto. As
partes interessadas do projeto podem ser internas ou externas ao projeto, e podem
estar envolvidas ativamente ou passivamente, ou não estar cientes do projeto.
Conceito de Gerenciamento de Projetos

Gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas

e técnicas às atividades do projeto a fim de cumprir os seus requisitos. O gerenciamento
de projetos é realizado através da aplicação e integração apropriadas dos processos de
gerenciamento de projetos identificados para o projeto. O gerenciamento de projetos
permite que as organizações executem projetos de forma eficaz e eficiente.
Note que o gerenciamento de projetos é aplicação de 4 componentes: conhecimento,
habilidades, ferramentas e técnicas.
Conceito de Programa
Um programa é definido como um grupo de projetos, programas subsidiários e
atividades de programa relacionados, gerenciados de modo coordenado visando a
obtenção de benefícios que não estariam disponíveis se eles fossem gerenciados
individualmente. Os programas não são projetos de grande porte.
Um programa não é um simples aglomerado de projetos. Tão pouco um projeto de
grande porte. Para ser programa é necessário que essa coordenação em conjunto dos
projetos permita a obtenção de benefícios que não estariam disponíveis se os projetos
fossem gerenciados de forma isolada.
O gerenciamento de projetos foca nas interdependências dentro de um projeto para
determinar a abordagem ideal para gerenciar o projeto. O gerenciamento de programas
foca nas interdependências entre projetos e o nível do programa para determinar a
abordagem ideal para gerenciá-los.
O gerenciamento de programas é definido como a aplicação de conhecimentos,
habilidades e princípios a um programa para atingir os objetivos do programa e obter
benefícios e controle que de outra forma não estariam disponíveis através do
gerenciamento individual dos componentes do programa
Conceito de Portfólio
Um portfólio é definido como projetos, programas, portfólios subsidiários e operações
gerenciados em grupo para alcançar objetivos estratégicos.
Em um portfólio encontramos “tudão”: projetos, programas, portfólios subsidiários e
operações. Note que um ponto que marca a definição de portfólio é que ele está em alto nível.
Ou seja, busca do atingimento de objetivos estratégicos.

Atenção! O gerenciamento de programas e projetos foca em fazer programas e projetos da

maneira “certa”. Já o gerenciamento de portfólios foca em fazer os programas e projetos
“certos”.
Definição de Sucesso

Sucesso de um projeto é medido pela qualidade do produto e do projeto, cumprimento

de prazos, conformidade com o orçamento e grau de satisfação do cliente.
Sucesso de um programa é medido pela capacidade do programa de entregar seus
benefícios esperados para uma organização, e pela eficiência e eficácia do programa
para entregar esses benefícios.
Já o sucesso de um portfólio é medido em termos do desempenho do investimento
agregado e da realização de benefício do portfólio.
Visão comparativa

Gerenciamento de Projetos Organizacionais

Projetos Programas Portfólios

Projeto é um Um programa é um Um portfólio é um

esforço temporário grupo de projetos, conjunto de projetos,
empreendido para programas programas, portfólios
criar um produto, subsidiários e subsidiários e operações
serviço ou atividades de gerenciados em grupo
resultado único programa para alcançar objetivos
relacionados, estratégicos.
Definição
gerenciados de modo
coordenado visando a
obtenção de benefícios
que não estariam
disponíveis se eles
fossem gerenciados
individualmente

Os projetos têm Os programas têm um Os portfólios têm um

objetivos definidos. escopo que abrange os escopo organizacional que
O escopo é escopos dos muda com os objetivos
elaborado componentes do estratégicos da
progressivamente programa. Os organização
ao longo do ciclo de programas produzem
vida do projeto. benefícios para uma
Escopo organização ao
garantir que as saídas
e resultados dos
componentes do
programa sejam
entregues de forma
coordenada e
complementar

Os gerentes de Os programas são Os gerentes de portfólio

projetos esperam gerenciados de uma monitoram continuamente
mudanças e forma que aceita as as mudanças nos
Mudança
implementam mudanças e se adapta ambientes internos e
processos para a eles, conforme externos mais
manter a mudança necessário, para abrangentes.
 gerenciada e otimizar a entrega de
controlada. benefícios à medica
que os componentes
do programa
entregam resultados
e/ou saídas.

Os gerentes do Os programas são Os gerentes de portfólio

projeto elaboram gerenciados usando criam e mantêm os
progressivamente planos de alto nível processos necessários e a
informações de alto que monitoram as comunicação relativa ao
nível em planos interdependências e o portfólio agregado.
detalhados ao progresso dos
Planejamento longo do ciclo de componentes do
vida do projeto. programa. Os planos
de programa também
são usados para
orientar o
planejamento em nível
de componentes

Os gerentes do Os programas são Os gerentes de portfólio

projeto gerenciam gerenciados por podem administrar ou
a equipe do projeto gerentes de programa, coordenar o pessoal de
para cumprir os que garantem que os gerenciamento de
objetivos do benefícios do portfólio, ou o pessoal do
projeto. programa sejam programa e do projeto que
Gerenciamento
entregues conformes tenha responsabilidades
esperado, de prestação de contas
coordenando as sobre o portfólio agregado
atividades dos
componentes de um
programa.

Os gerentes do Os gerentes do Os gerentes de portfólio

projeto monitoram programa monitoram monitoram mudanças
e controlam o o progresso dos estratégicas e agregam
trabalho de componentes do alocação de recursos,
produzir os programa para que resultados de desempenho
produtos, serviços garantir as metas e risco do portfólio.
Monitoramento
ou resultados que o gerais, os
projeto pretendia cronogramas, o
produzir. orçamento e os
benefícios do
programa serão
cumpridos.

O sucesso é O sucesso de um O sucesso é medido em

medido por programa é medido termos do desempenho do
qualidade do pela capacidade do investimento agregado e
produto e do programa de entregar da realização de benefício
Sucesso
projeto, seus benefícios do portfólio.
cumprimento de esperados para uma
prazos, organização, e pela
conformidade com eficiência e eficácia do
 o orçamento e grau programa para
de satisfação do entregar esses
cliente. benefícios.

Escritório de Projetos
O gerenciamento de projetos em uma organização é apoiado pelo Escritório de Gerenciamento
de Projetos (EGP), também conhecido como Project Management Office (PMO) em inglês.
O PMO é uma estrutura centralizada que padroniza processos de governança relacionados a
projetos, compartilhando recursos e metodologias. Existem três tipos principais de PMO: de
suporte, de controle e diretivo. O PMO de suporte fornece consultoria e recursos, mas não
gerencia projetos diretamente. O PMO de controle além de suporte, exige conformidade com
suas práticas. O PMO diretivo assume a gestão direta dos projetos.
É importante lembrar que a presença de um PMO não é obrigatória, mas pode ser útil para
aplicar boas práticas de gerenciamento de projetos na organização. O papel do gerente de
projetos difere do PMO, com o gerente focando no projeto e o PMO tendo uma visão
organizacional.

Gerente de Projeto EGP

Meta Geral Atingir os requisitos do projeto Atingir metas do ponto de vista corporativo

Objetivo Entregar os objetivos Entregar objetivos organizacionais

Recursos Gerentes os recursos do projeto Otimizar os recursos compartilhados

Relatórios Relatórios do projeto Relatórios consolidados

Influências Organizacionais
Projetos são significativamente influenciados pela cultura e estilos organizacionais. A cultura,
formada pelas experiências dos membros da organização, estabelece normas seguidas por todos
e é considerada pelo PMBOK como um fator ambiental empresarial. Além disso, a comunicação
organizacional, que varia entre formal e informal dependendo da organização, impacta o sucesso
dos projetos. Portanto, é essencial que o gerente de projetos compreenda e adapte-se à cultura
e ao estilo de comunicação da organização para gerenciar efetivamente os projetos.
Tipos de Estruturas Organizacionais
Existem três tipos principais de estruturas organizacionais:
• Funcional
• Matricial
• Projetizada
A estrutura escolhida influencia diretamente a gestão do projeto, especialmente no que tange à
autoridade do gerente de projeto. É crucial entender como cada estrutura impacta a gestão do
projeto, conforme resumido no PMBOK.
Uma organização funcional é um modelo clássico e tradicional de estrutura empresarial. Nela, a
organização é dividida em departamentos especializados como engenharia, pessoal,
contabilidade e marketing, cada um liderado por um gerente funcional, conforme o PMBOK.
Caracteriza-se pela especialização dos trabalhadores em áreas específicas e uma hierarquia
clara, com uma cadeia de comando definida onde os funcionários reportam ao chefe do
departamento. Acredita-se que agrupar pessoas com habilidades e experiências semelhantes
facilita a gestão.
A figura a seguir, retirada do PMBOK, mostra uma organização funcional.

Em organizações funcionais, cada funcionário responde a um gerente funcional e, em

projetos, também ao gerente de projetos, criando uma disputa por recursos humanos. Após o
projeto, os funcionários retornam às suas atividades regulares com emprego garantido. Já em
organizações projetizadas, orientadas para projetos, os recursos são alocados especificamente
para projetos sob a coordenação de um gerente de projetos. A figura a seguir, retirada do
PMBOK, mostra uma organização projetizada.

Em organizações projetizadas, os funcionários estão diretamente subordinados a um

gerente de projetos, sem necessidade de responder a dois chefes e sem envolvimento em
atividades fora do projeto. No entanto, ao final do projeto, podem enfrentar insegurança no
emprego, pois não há um departamento regular para retornar.
Nas organizações matriciais, que variam entre fraca, balanceada e forte, a autoridade e
gestão do orçamento diferem. Em matriciais fortes, semelhantes às projetizadas, o gerente de
projetos controla o orçamento. Em matriciais fracas, mais próximas das funcionais, o gerente
funcional tem esse controle. As matriciais balanceadas compartilham características de ambas,
com uma gestão mista do orçamento.
Em estruturas funcionais, o gerente funcional domina, controlando o orçamento e tendo
maior autoridade, enquanto o gerente de projetos atua mais como um funcionário comum, em
um papel parcial. Em contraste, nas estruturas projetizadas, o gerente de projetos possui alta a
quase total autoridade, incluindo o controle do orçamento, atuando em tempo integral.
Ativos de Processos Organizacionais
Ativos de processos organizacionais são os planos, processos, políticas, procedimentos e as
bases de conhecimento específicas da organização e por ela usados.
Fatores ambientais da empresa
Fatores ambientais da empresa se referem às condições fora do controle da equipe do
projeto que influenciam, restringem ou direcionam o projeto. São exemplos de fatores
ambientais: Cultura, estrutura e governança organizacional; Distribuição geográfica de
instalações e recursos; Normas governamentais ou do setor; Infraestrutura; Recursos humanos
existentes ;Administração de pessoal ;Sistemas de autorização de trabalho da empresa;
Condições do mercado; Tolerância a risco das partes interessadas; Clima político; Canais de
comunicação estabelecidos da organização; Bancos de dados comerciais; Sistema de
informações do gerenciamento de projetos.
Equipes de Projeto

As composições básicas de equipes de projeto podem ser de dois tipos:

a) Dedicada: Nesse caso, todos ou a maioria dos membros em regime de tempo integral. Eles
podem trabalhar de forma presencial ou virtualmente. Nessa estrutura, a linha de autoridade é
clara.
b) Tempo parcial: Nesse caso, os membros geralmente não trabalham de forma integral. Parte
da sua jornada dedicam ao projeto e outra parte para responder ao seu gerente funcional. Note
que nesse caso, um membro tem que responder a dois gerentes. Ao seu gerente funcional e ao
gerente de projetos.
Ciclo de vida do Projeto
Uma vez aprovado, o projeto seguirá por diversas fases até a sua conclusão. O ciclo de
vida do projeto são justamente essas fases. Ou seja, o ciclo de vida são as fases pelas quais um
projeto passa, do início até o seu término.
Durante a execução do ciclo de vida, diversos processos são executados. Esses processos
são divididos em cinco grupos de processos de gerenciamento de projetos:
• Iniciação
• Planejamento
• Execução
• Monitoramento e controle
• Encerramento
É preciso memorizar esses cinco grupos de processos. É uma questão muito comum em
prova. Outro ponto importantíssimo é saber que esses grupos não são fases do ciclo de vida.
Anote aí: grupos de processos não são fases. Contudo, algumas bancas confundem isso.
Os projetos variam em tamanho e complexidade. Assim, cada organização deve criar o
ciclo de vida para os seus projetos. Apesar disso, segundo o PMBOK, todos os projetos podem
ser mapeados para a estrutura genérica de ciclo de vida com as seguintes fases:
 • Início do projeto
• Organização e preparação
• Execução do trabalho do projeto
• Encerramento do projeto.

A figura a seguir mostra todo ciclo de vida e suas fases. Note que o nível de custo e
pessoal começa baixo e vai subindo. O seu pico ocorre na execução do trabalho, depois volta a
cair de maneira mais rápida.

Um ponto importante de é guardar que quando uma fase termina, ela serve como um
ponto de controle. Nesse momento, é possível, por exemplo, fazer uma avaliação se o projeto
deve continuar ou não. Também é comum que sejam feitas entregas parciais relevantes para o
projeto ao final de cada fase.
É preciso notar que um ciclo de vida proposto pelo PMBOK é geral. Ele oferece uma
estrutura básica para o gerenciamento do projeto, independentemente do projeto no caso
concreto. Além disso, os grupos de processos possuem processos não se confundem com essas
fases. Na verdade, os processos são executados ao longo de todo projeto.
A figura a seguir mostra as interações entre os grupos de processos em um projeto ao
longo do tempo. Em projetos com várias fases, os processos são repetidos em cada fase até que
os critérios para a conclusão das fases sejam cumpridos.

Lembre-se que o PMBOK não é uma metodologia. Contudo, cada organização pode criar
a sua e definir o ciclo de vida dos seus projetos. E este ciclo de vida pode ser documentado em
uma metodologia.
O ciclo de vida apresentado pelo PMBOK tem algumas características que são
apresentadas na figura seguir.
 O primeiro ponto a ser notado é que os riscos e incertezas são maiores no início do
projeto. Com o andamento do projeto, os riscos e incertezas vão diminuindo. Isso vem do fato
que o trabalho do projeto está sendo entregue à medida que o ciclo de vida avança.
Já vimos que os níveis de custo e de pessoal são baixos no início, atingem um valor
máximo na execução e caem rapidamente conforme o projeto é finalizado. Esse padrão faz com
que no início do projeto (quando ainda não se gastou muito), o custo para fazer mudanças no
projeto seja baixo. Contudo, esse custo sobe a medida que o projeto anda. Esse fato também
impacta a capacidade das partes interessadas influenciarem nas características finais do
produto.
Logo no início (quando os custos ainda são baixos), a capacidade de influenciar no
projeto é mais alta e diminui à medida que o projeto caminha para o seu término.
Atenção! A curva de custo e pessoal apresentada pode não se aplicar a todos os
projetos. Um projeto pode exigir, por exemplo, despesas substanciais logo no início do seu ciclo
de vida.
Relação entre as fases de um projeto
Já sabemos que um ciclo de vida se estrutura em fases. Essas fases podem ter uma
relação sequencial. Além disso, essa relação também pode ser de sobreposição.
Em uma relação sequencial, uma fase só inicia depois que a fase anterior terminar.
Segundo o PMBOK, “A natureza passo a passo desta abordagem reduz incertezas, mas pode
eliminar opções de redução do cronograma geral”
Em uma relação sobreposta, uma fase tem início antes do término da anterior. As fases
sobrepostas podem exigir mais recursos, pois temos trabalhos em paralelo sendo executados.
Além disso, podem resultar em retrabalho caso uma fase subsequente avance antes entradas
que viriam da fase anterior estejam prontas.
Podemos ter ainda uma relação iterativa, onde apenas uma fase está planejada e o
planejamento da próxima é feito à medida que o trabalho avança na fase atual e nas entregas.
Tipos de ciclo de vida
Os ciclos de vida previstos, inteiramente planejados ou preditivos são aqueles em que
o escopo do projeto, bem como o tempo e custos exigidos para entregar tal escopo são
determinados o mais cedo possível no ciclo de vida do projeto. Esse tipo de ciclo de vida também
é chamado de cascata. Nesse tipo de ciclo, as fases tipicamente têm atividades diferentes.
Os ciclos de vida iterativos e incrementais são assim chamados pois apresentam essas
duas características. Eles são iterativos, pois cada uma das fases tem diversas atividades
repetidas. Uma fase pode ser vista como um mini-projeto do ponto de vista um ciclo de vida
preditivo. Assim, as iterações propriamente ditas são executadas de maneira sequencial ou
sobreposicional. Durante uma iteração, as atividades de todos os grupos de processos de
gerenciamento de projeto serão executadas. Ser incremental quer dizer que em cada fase uma
parte do produto é entregue. Ou seja, o produto é entregue em incrementos. Esses incrementos
geralmente são funcionais.
Por fim temos os ciclos de vida adaptativos (também conhecidos como direcionados à
mudança ou utilizadores de métodos ágeis). Esse tipo de ciclo foi pensado para ser utilizado em
um ambiente onde ocorrem muitas mudanças. Esse é caso de projetos de pesquisa ou
desenvolvimento de software.
Os ciclos de vida adaptativos são também iterativos e incrementais. E qual seria a
diferença entre eles e os ciclos iterativos e incrementais? A diferença é o tamanho das iterações.
Em ciclos adaptativos, as iterações são muito rápidas. Isso significa que elas duram de 2 a 4
semanas. O tempo e recursos são fixos durante a iteração. Um exemplo prático de
gerenciamento ágil é o adotado pelo Scrum no desenvolvimento de software. O escopo geral
do projeto faz parte uma lista chamada backlog do projeto ou backlog do produto. No início de
cada iteração, a equipe escolhe quais itens do backlog serão executados. No final de cada
iteração, um produto funcional (incremento) deve estar pronto para a análise pelo cliente.
Escopo do Projeto e Escopo do Produto
Quando falamos em escopo devemos pensar naquilo que deve ser entregue. Existem
dois tipos de escopo: do produto e do projeto. O examinador tentará confundir você, fazendo
trocas na prova.
Segundo o PMBOK, “o escopo de projeto é todo o trabalho necessário para entregar um
produto, serviço ou resultado” (grifo nosso)
Note que palavra-chave é trabalho. Ou seja, quando montamos o escopo do projeto
estamos identificando o trabalho que precisa ser feito para chegamos ao produto, serviço ou
resultado do projeto. Normalmente, esse trabalho é acompanhando pelas linhas base de
orçamento e cronograma.
Ao definir o escopo do produto, o PMBOK afirma que: “são as características e
funções que descrevem um produto, serviço ou resultado”
Assim, quando pensar no escopo do produto, as palavras-chave são: características e
funções. Note que o escopo de produto forma uma linha de base que pode ser usada para
comparar se o produto final está concluído. O escopo do produto envolve coisas como:
• Detalhar os requisitos do produto do projeto
• Criando um plano de gerenciamento de escopo do projeto
• Criando uma EAP
Note que escopo do projeto, tem como foco as atividades que serão realizadas. Já o
escopo do produto tem relação com que será entregue ao final do projeto. Ou seja, descreve o
produto, serviço ou resultado esperado.
Termo de Abertura
Para reconhecermos formalmente que um projeto ou fase foi iniciado fazemos uso de
um documento chamado termo de abertura.
Um projeto pode surgir como resultado de uma necessidade, demanda, oportunidade
ou problema. Depois que essas necessidades e demandas são identificadas, o próximo passo
lógico pode incluir a realização de um estudo de viabilidade para determinar a viabilidade do
projeto. De posse dessas informações é criado o termo de abertura.
Segundo o PMBOK, desenvolver o termo de abertura do projeto é o processo de
desenvolver um documento que formalmente autoriza a existência de um projeto e dá ao
gerente do projeto a autoridade necessária para aplicar recursos organizacionais às atividades
do projeto.
Note que termo de abertura tem dois papéis importantes. O primeiro é autorizar de
maneira formal o início do projeto. Antes do projeto começar nós temos diversas atividades.
Essas atividades estão relacionadas à aprovação do projeto. Por isso, é tão importante ter um
documento que marque o início do projeto. Quando o termo de abertura é assinado todos os
envolvidos sabem que o projeto foi iniciado de fato.
Geralmente, o termo de abertura é assinado em uma reunião chamada de reunião de
abertura. Nessa reunião, são apresentadas as principais partes envolvidas no projeto. Um
termo de abertura do projeto também serve para estabelecer acordos internos no âmbito de
uma organização para garantir a entrega nos termos do contrato.
Outro papel importante do termo de abertura é dar poder ao gerente de projeto. Esse
também é um aspecto importantíssimo, basta lembrarmos que o poder do gerente de projetos
varia com a estruturas organizacionais. Sem um documento que formal que autorize o gerente
de projetos a utilizar recursos da organização para a condução do projeto, dificilmente suas
ordens seriam acatadas. Por exemplo, em organizações funcionais o poder é tipicamente do
gerente funcional. Nesse tipo de organização o termo de abertura é ainda mais importante para
que o gerente de projetos consiga atuar.
 Segundo o PMBOK, o gerente de projeto é identificado e designado o mais cedo possível,
preferivelmente enquanto o termo de abertura está sendo desenvolvido e sempre antes do
início do planejamento
Business Case
Uma necessidade de negócios de uma organização pode surgir devido a diferentes
fatores:
• Demanda de mercado;
• Avanço tecnológico;
• Requisito legal;
• Regulamentação governamental;
• Consideração ambiental.
Uma demanda do mercado pode ser a necessidade de um novo tipo serviço ou produto.
Por exemplo, um software que permita a comunicação remota entre pessoas.
Um avanço tecnológico também pode impulsionar um projeto. Novas descobertas
podem gerar produtos que podem ser usados no dia a dia das pessoas. Por exemplo, serviços
de comunicação a distância puderam ser possíveis após o lançamento de satélites.
Um requisito legal também pode motivar um projeto. Por exemplo, uma indústria pode
ser obrigada a produzir um nível menor de poluentes. Para isso, terá que implantar um novo
sistema de filtragem, por exemplo. No mesmo sentido, regulamentações governamentais ou
restrições ambientais podem levar a criação de novas projetos.
Seja qual for o motivo do projeto, essa necessidade de negócios precisa passar por uma
análise de custo benefício. Essa análise está contida em um documento chamado business case.
Ou seja, é criado para justificar o projeto. Ele para convencer a alta direção de que vale a pena
investir no projeto.
Segundo o PMBOK,

O business case, ou documento semelhante, descreve as informações

necessárias do ponto de vista de negócios, para determinar se o
projeto justifica ou não o seu investimento. Ele é comumente usado
no processo decisório pelos gerentes ou executivos acima do nível do
projeto. Normalmente, a necessidade de negócios e a análise de custo
benefício estão contidas no business case para justificar o projeto e
estabelecer os seus limites, e tal análise é normalmente executada por
um analista de negócios usando diversas informações das partes
interessadas. O patrocinador necessita concordar com o escopo e as
limitações do business case.

O bussines case é um documento usado como entrada para a geração do termo de

abertura. Contudo, essa justificativa pode também estar presente no termo de abertura. Ou
seja, o bussines case, ou parte dele, pode estar repetido em uma sessão do termo de abertura.
EAP
Quando estamos desenvolvendo um projeto, um dos aspectos principais é definir o que
será entregue. A definição do que será entregue compõem o escopo. Já sabemos que há dois
tipos de escopos. O escopo do projeto que envolve o trabalho a ser realizado. E o escopo do
produto que envolve as características do produto, serviço ou resultado a ser entregue. Nesse
momento vamos falar sobre o escopo do projeto em mais detalhes.
Não é fácil nem trivial pensar em todo o escopo do projeto de uma única vez. Por isso,
o PMBOK adota a chamada elaboração progressiva. Na elaboração progressiva à medida que o
projeto avança mais detalhes são conhecidos e com isso é possível fazer um melhor
detalhamento das atividades. Para gerar as atividades do cronograma é preciso saber o que será
entregue. Para ter a visão geral do que será entregue utilizamos uma EAP (Estrutura Analítica
do Projeto).
A EAP provê uma decomposição hierárquica do escopo. O que isso significa? Quando
falamos em decomposição hierárquica estamos querendo dizer que o escopo é pensado de um
nível mais alto para um nível mais baixo. Ou seja, de um nível com menor detalhes para um com
maior detalhes. Vamos pensar em um exemplo. Vamos imaginar que queremos construir um
avião. No nível mais alto da EAP teremos simplesmente isso um avião. Em um nível abaixo
temos que quebrar esse escopo. Nesse nível inferior ao do avião podemos encontrar as partes
que compõem o avião, por exemplo: motor e asas. Cada uma das partes desse nível pode, por
sua vez, ser quebrada em mais partes. Dessa forma temos níveis inferiores que descrevem os
componentes que devem ser entregues para formar o motor e as asas. Esse processo segue até
que chegamos no nível mais baixo da EAP chamado de pacote de trabalho.
Segundo o PMBOK,a EAP é uma decomposição hierárquica do escopo total do trabalho
a ser executado pela equipe do projeto a fim de alcançar os objetivos do projeto e criar as
entregas requeridas. A EAP organiza e define o escopo total do projeto e representa o trabalho
especificado na atual declaração do escopo do projeto aprovada
Dessa forma, criar uma EAP consiste no processo de subdivisão das entregas e do
trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
Pacote de Trabalho
Segundo o PMBOK, um pacote de trabalho pode ser usado para agrupar as atividades
onde o trabalho é agendado, tem seu custo estimado, monitorado e controlado. No contexto da
EAP, o trabalho se refere a produtos de trabalho ou entregas que são o resultado da atividade e
não a atividade propriamente dita.
A figura a seguir, retirada do PMBOK, mostra uma EAP decomposta até o nível de pacote
de trabalho.

Fonte: Guia do PMBOK

Um EAP também pode ser organizada por fases como mostra a figura a seguir, retirada
do PMBOK.
 Fonte: Guia do PMBOK
Além da opção gráfica, uma EAP pode ser apresentada em forma de lista. Na verdade, a
EAP pode assumir qualquer forma que identifique a decomposição hierárquica do escopo.
É preciso notar que a decomposição em detalhes possa não ser possível para uma
determinada entrega. Essa decomposição excessiva e precoce pode causar retrabalho. Logo, ela
só será feita em um momento futuro. Essa técnica é chamada de planejamento em ondas
sucessivas
Um conceito relacionado a EAP importante para sua prova é o de linha de base do
escopo. A linha de base do escopo, além da EAP, é composta pela especificação do escopo do
projeto e do dicionário da EAP.
A especificação do escopo do projeto é composta por:
a) Descrição do escopo do produto: Características do produto, serviço ou resultado
descritos no termo de abertura do projeto e na documentação dos requisitos.
b) Critérios de aceitação: Conjunto de condições a serem satisfeitas antes da aceitação
das entregas.
c) Entregas: Qualquer produto, resultado ou capacidade cuja execução é exigida para
concluir um processo, uma fase ou um projeto.
d) Exclusão do projeto: Identifica de modo geral o que é excluído do projeto. Ou seja,
declarar explicitamente o que está fora do escopo do projeto
e) Restrições: Um fator limitador que afeta a execução de um projeto ou processo. As
restrições identificadas com a declaração do escopo do projeto listam e descrevem
as restrições ou limitações internas e externas específicas associadas com o escopo
do projeto que afetam a execução do mesmo.
f) Premissas: Um fator do processo de planejamento considerado verdadeiro, real ou
certo, desprovido de prova ou demonstração. Também descreve o impacto
potencial desses fatores se forem comprovados como falsos.
O dicionário da EAP é um documento que fornece informações detalhadas (por isso, ele
é chamado de dicionário) sobre entregas, atividades e agendamento de cada componente da
estrutura analítica do projeto (EAP). Um dicionário da EAP pode conter as seguintes
informações:
• Código de identificador da conta
• Descrição do trabalho;
• Premissas e restrições;
• Organização responsável;
• Marcos do cronograma;
• Atividades do cronograma associadas;
• Recursos necessários;
 • Estimativa de custos;
• Requisitos de qualidade;
• Critérios de aceitação;
• Referências técnicas; e
• Informações sobre acordos.
Tripla restrição
Durante o gerenciamento do projeto é necessário balancear as demandas
conflitantes de escopo, tempo e custo. Estas demandas formam a chamada tripla restrição. Na
verdade, muitos autores incluem um quarto componente: a qualidade. Também é importante
notar que as demandas conflitantes podem ser influenciadas (positivamente ou negativamente)
pelo risco. Como a tripla restrição funciona?
Ao definir um escopo, a consequência imediata é a definição de um custo associado e
do tempo necessário para terminar o projeto. Se o equilíbrio for mantido o projeto é entregue
com qualidade. Por outro lado, se o prazo, por exemplo, for reduzido sem aumento do custo ou
redução de escopo a qualidade será afetada. De forma geral, a alteração de qualquer um dos
componentes da tripla restrição afeta os demais
A restrição “tempo” também pode ser chamada de cronograma e a restrição “custo” de
orçamento. No PMBOK, podemos notar seis restrições: Escopo, Cronograma, Orçamento,
Qualidade, Recursos e Risco.
Existem autores que incluem ainda o atendimento ao cliente como uma restrição.

Estimativa de Custos

Estimar os custos é o processo de estimativa do valor necessários para executar as

atividades do projeto. Por exemplo, mão de obra, materiais, equipamentos, serviços, etc.
Esses custos geralmente são expressos em unidades de moeda (dólares, reais, euros, etc.).
Contudo, em alguns casos, outras unidades de medida são possíveis, por exemplo, homem hora.
Essa abordagem pode ser útil para facilitar as comparações e abstrair os efeitos das flutuações
das moedas.
As estimativas de custos são melhoradas à medida que o projeto é executado. Isso é
natural, pois mais informações estarão disponíveis e algumas premissas que
foram assumidas tornaram-se verdades ou não. Segundo o PMBOK,

Um projeto na fase inicial poderia ter uma ordem de grandeza (ROM

– Rough order of magnitude) estimada na faixa de -25% a +75%. Mais
tarde, conforme mais informações são conhecidas, as estimativas
podem estreitar para uma faixa de precisão de -5% para +10%. (grifo
nosso)

O que você deve levar para prova é que a estima ROM é uma estimativa grosseira, pois
não temos muito detalhes. À medida que você tem mais informações a sua estimativa melhora
de precisão.

Métodos de seleção de projetos

Existem vários métodos de seleção de projetos. Eles são úteis ao processo de tomada
de decisão. Usando tais métodos as organizações podem decidir entre dois projetos
alternativos, por exemplo. Essa decisão é baseada em benefícios tangíveis. Esses métodos
também podem ser usados escolher entre formas alternativas de implementar um determinado
projeto. Ao aplicar os métodos de seleção de projeto, pode-se usar um ou vários métodos de
medição de benefícios isoladamente ou em combinação para chegar a uma decisão de seleção.
De forma geral, os métodos de seleção de projetos podem ser divididos em dois grandes
grupos:

• Modelos matemáticos (ou métodos de otimização restrita)

 • Métodos de medição de benefícios (ou modelos de decisão)

Os modelos matemáticos, também conhecidos como métodos de otimização restrita, usam

algoritmos matemáticos para a seleção dos projetos. Esses algoritmos são dos seguintes tipos:

• Linear
• Dinâmico
• Inteiro
• Não linear
• Programação multi-objetivo
Os métodos de medição de benefícios, também conhecidos como modelos de decisão,
empregam formas comparativas de abordagens para tomar decisões de projeto. Esses métodos
incluem:

• Análise de custo-benefício
• Modelos de pontuação
• Análise de fluxo de caixa

A análise de custo-benefício, também conhecida como análise de custo ou análise de

benefícios, compara o custo para produzir o produto, serviço ou resultado do projeto com o
benefício que a organização receberá como resultado da execução do projeto.
Nos modelos de pontuação ponderada, são definidos vários critérios, os quais possuem
um determinado peso. Cada projeto recebe uma nota baseado nesses critérios.
Para seleção dos projetos, também pode ser usada técnicas de análise de fluxo de caixa
que inclui:
• Período de retorno
• Fluxos de caixa descontados
• Valor presente líquido
• Taxa interna de retorno
• Período de retorno

Onda de Gerenciamento de Projetos

Historicamente podemos dividir o gerenciamento de projetos em três ondas. Segundo
Márcio Hervé,

A visão do gerente de projetos como um profissional diferenciado,

com um corpo de conhecimentos próprio (consolidado pelo próprio
PMI, alguns anos depois, no PMBoK, Project Management Body of
Knowledge), constituiu um marco histórico. E gerou o que eu chamo
de primeira onda, caracterizada pelo reconhecimento da importância
da figura do gerente de projetos, busca de capacitação e certificações,
e a certeza de que um gerente qualificado e certificado era a garantia
para o sucesso de um projeto. (grifo nosso)

Para Carvalho,

A primeira onda, desenvolvida a partir das décadas de 1980-1990,

focada na busca de boas práticas de gerenciamento de projetos com
foco na eficiência, ou seja, a primeira onda era voltada para o melhor
uso possível das ferramentas específicas para gerenciar as restrições
de um projeto. (grifo nosso)

Assim, sintetizando, na primeira onda:

• Buscou-se a aplicação das práticas de gerenciamento de projetos.
 • Foi a onda de eficiência
• Ocorreu a consolidação de guias como o PMBOK
• Tinha foco no projeto
• Surgiu a partir dos anos 80
Em relação a segunda onda, Márcio Hervé ensina:

Considero que a segunda onda se caracterizou por uma visão mais

complexa da gestão de projetos, mas ainda focada em ferramentas.
Neste momento tivemos, entre outras coisas, uma diversificação de
certificações, a utilização de modelos de maturidade, além de
conceitos novos como PMO, métodos ágeis, Canvas e outros. Esta
onda começou no final dos anos 90 e está por aí até agora. É
importante notar que ela de forma alguma cancelou a anterior; o
PMBOK e a certificação PMP continuam como referências
importantes, mas ficou claro que era necessário ir mais fundo na
questão. (grifo nosso)

Para Carvalho,

A segunda onda, focada na organização, entendendo modelos de

maturidade e os impactos estratégicos do gerenciamento por
projetos, programas e portfolios. Voltada para a eficácia, ou seja, para
os resultados. (grifo nosso)

Assim, sintetizando, na segunda onda temos:

• Utilização de modelos de maturidade
• Foco Organizacional
• Busca-se o alinhamento estratégico e uso de portfólio de projetos.
• Voltada para eficácia
• Uma visão mais complexa da gestão de projetos
• Tem seu início no final dos anos 90 e está até hoje.
Para Márcio Hervé, ainda há uma terceira onda:

A base desta terceira onda é entender que projetos são atividades

humanas, e não há como melhorar resultados sem colocar o ser
humano no centro da ação. Esta nova onda não tem ferramentas
computacionais (pelo menos até agora), mas baseia-se em estudos,
experiência e visão sobre três assuntos que me parecem os mais
importantes, hoje; Gestão de Mudanças, Gestão de Talentos e Gestão
do Conhecimento. Como pano de fundo, ficam os aspectos culturais,
que sempre influenciam o comportamento humano, para o bem e
para o mal. Resumindo tudo em um só conceito, Gerenciamento de
Pessoas. (grifo nosso)

Assim, sintetizando, na terceira onda temos:

• Foco na atividade Humana/Gerenciamento de pessoas
• Foco na gestão de mudanças, talentos e conhecimento
 • Será o foco do futuro do gerenciamento de projetos

Ciclo de Vida do Produto

A organização ou os gerentes de projetos podem dividir projetos em fases para oferecer
melhor controle gerencial com ligações adequadas com as operações em andamento da
organização executora. Coletivamente, essas fases são conhecidas como o ciclo de vida do
projeto.
O ciclo de vida do projeto não se confunde com ciclo de vida do produto. Tipicamente
um ou mais projetos fazem parte do ciclo de vida do produto. Além disso, outros aspectos fazem
parte do ciclo de vida do produto como a elaboração do plano de negócios e operações de venda
do produto. Em síntese, o ciclo do produto é mais amplo, pois envolve um ou mais projetos.
O ciclo de vida do produto é um conceito mais amplo que pode envolver um ou mais
projetos. Nada impede que um dos projetos do ciclo do produto tenha como produto outro
projeto. Não há que se confundir o produto de um projeto, com o produto (de forma global) que
se deseja produzir.
Vamos imaginar a produção de um carro. Esse produto tem um ciclo vida. O ciclo de vida
do produto (carro) pode ser composto de vários projetos, planos de negócio, etc. Ela vai desde
sua concepção até sua retirada do mercado. Note que, por exemplo, um dos projetos do ciclo
de vida desse produto pode ser um estudo para decidir pela execução de projeto A ou B do
carro. Assim, esse estudo (que é um projeto) tem como saída outro projeto. Note que isso não
faz os conceitos de ciclo de vida de produto e ciclo de vida do projeto se igualarem. Por isso, o
item está incorreto.
Metodologias ágeis
As metodologias ágeis são mais adaptáveis a mudanças em comparação com o
gerenciamento de projetos tradicional, como o PMBOK. Isso ocorre porque as abordagens ágeis
enfatizam ciclos de desenvolvimento curtos e iterativos, permitindo revisões e ajustes
frequentes baseados em feedback constante. Enquanto o gerenciamento tradicional segue um
plano linear e mais rígido, com mudanças muitas vezes vistas como disruptivas, as metodologias
ágeis tratam as mudanças como uma parte natural e contínua do processo de desenvolvimento,
facilitando a sua incorporação rápida e eficiente.
As metodologias ágeis são abordagens de gestão de projetos e desenvolvimento de
software que enfatizam a flexibilidade, a colaboração da equipe, a satisfação do cliente e a
entrega contínua de produtos funcionais. Elas se contrapõem aos métodos tradicionais, mais
rígidos e sequenciais, como o modelo cascata. Principais características incluem:
• Iterações Curtas: Desenvolvimento em ciclos curtos (sprints), permitindo
ajustes frequentes com base no feedback.
• Colaboração Intensa: Trabalho em equipe com comunicação constante entre
desenvolvedores, gerentes e clientes.
• Adaptação Rápida: Capacidade de responder rapidamente a mudanças no
projeto ou no mercado.
• Entrega Incremental: Lançamento de versões incrementais do produto final,
permitindo melhorias contínuas.
• Foco no Cliente: Priorização das necessidades do cliente para garantir satisfação
e valor.
• Simplicidade e Eficiência: Redução de processos desnecessários e foco naquilo
que realmente agrega valor.
Exemplos populares incluem Scrum, Kanban e Extreme Programming (XP).
Scrum
Scrum é uma metodologia ágil focada na gestão e no planejamento de projetos de software.
Suas principais definições incluem:
• Sprints: Ciclos de desenvolvimento curtos e time-boxed, geralmente de duas a quatro
semanas, para entrega de partes do produto.
• Scrum Master: Facilitador para a equipe, assegurando a aderência aos princípios e
práticas do Scrum.
• Product Owner: Representa os stakeholders e é responsável por maximizar o valor do
produto, gerenciando o Product Backlog.
• Equipe de Desenvolvimento: Grupo cross-funcional responsável pela entrega do
incremento do produto ao final de cada Sprint.
• Reuniões Diárias (Daily Stand-ups): Encontros curtos diários para alinhamento e
planejamento das atividades do dia.
• Product Backlog: Lista priorizada de requisitos e funcionalidades do produto.
• Revisão do Sprint: Reunião ao final de cada Sprint para apresentar o trabalho concluído
e receber feedback.
• Retrospectiva do Sprint: Discussão sobre o que foi bem e o que pode ser melhorado no
próximo Sprint.
XP
Extreme Programming (XP) é uma metodologia ágil para desenvolvimento de software que
enfatiza a eficiência e a flexibilidade. Suas principais características são:
• Programação em Pares: Dois programadores trabalham juntos no mesmo código,
aumentando a qualidade e reduzindo os erros.
• Desenvolvimento Orientado a Testes: Escrever testes antes do código real para garantir
a funcionalidade desde o início.
• Refatoração Contínua: Melhoria e simplificação constante do código para aumentar a
eficiência e reduzir a complexidade.
• Integração Contínua: Integração e teste frequente de mudanças no código para
identificar problemas rapidamente.
• Lançamentos Pequenos e Frequentes: Entrega regular de versões do produto para obter
feedback rápido e fazer ajustes.
• Cliente On-Site: Ter um representante do cliente disponível permanentemente para
decisões rápidas e esclarecimento de dúvidas.
• Padrões de Codificação: Adesão a padrões consistentes para facilitar a leitura e a
manutenção do código por toda a equipe
• Propriedade Coletiva do Código: O código pertence a todos na equipe, permitindo que
qualquer um possa melhorá-lo conforme necessário.
Kanban
Kanban é uma metodologia ágil focada na gestão visual de fluxos de trabalho. Suas
principais características incluem:
• Quadro Kanban: Uma ferramenta visual para rastrear o trabalho através de várias fases
(como "A fazer", "Em andamento", "Concluído").
• Limites de Trabalho em Andamento (WIP): Restringir o número de tarefas em
determinada fase para evitar sobrecarga e garantir eficiência.
• Fluxo Contínuo: Em vez de trabalhar em sprints, o trabalho flui continuamente, com
ênfase na conclusão gradual das tarefas.
• Visualização do Trabalho: Destaca o progresso, os gargalos e as pendências de forma
clara para toda a equipe.
• Melhoria Contínua: Foco constante em identificar e implementar melhorias no
processo.
• Flexibilidade: Permite mudanças rápidas e adaptação às necessidades do projeto sem a
estrutura rígida de sprints.