e Book Gerenciamento de Escopo, Tempo e Risco

Volte ao Sumário
Navegue entre os capítulos
GERENCIAMENTO DO
ESCOPO, TEMPO E
RISCO
1
Gerenciamento do Escopo, Tempo e Risco
Volte ao Sumário
Lohmann, Guilherme Garcez, 2020

Gerenciamento do Escopo, Tempo e Risco - Jupiter Press - São Paulo/SP
33 páginas
Palavras Chave: 1. Gerenciamento do Escopo, Tempo e Risco, 2. Gerenciamen-

to de Escopo e Integração, 3.Gestão de Projetos.
1
*
Volte ao Sumário
SUMÁRIO
INTRODUÇÃO...................................................................................................................................................3
1. GERENCIAMENTO DO ESCOPO......................................................................................................5
1.3 COLETA DE REQUISITOS.........................................................................................................6
1.4 PROCESSO DE DEFINIÇÃO DO ESCOPO....................................................................10
s
2. ESTRUTURA ANALÍTICA DO PROJETO (EAP)..........................................................................13
2.1 CRIAR A EAP....................................................................................................................................13
2.2 DECOMPOSIÇÃO DA EAP.....................................................................................................14
2.3 DICIONÁRIO DA EAP.................................................................................................................16
2.4 LINHA BASE DO ESCOPO......................................................................................................16
3. ORGANIZAÇÃO E SEQUENCIAMENTO DAS ATIVIDADES DE UM PROJETO.....17
3.1 O TERMO DE ABERTURA DO PROJETO (TAP)...........................................................19
3.2 DESENVOLVIMENTO DO PLANO DE GERENCIAMENTO DO
PROJETO..................................................................................................................................................21
3.3 EXECUÇÃO E CRONOGRAMA ..........................................................................................23
3.4 MONITORAR E CONTROLAR AS ATIVIDADES..........................................................24
3.5 AS MUDANÇAS E O ENCERRAMENTO DO PROJETO........................................26
4. CONTROLE E VALIDAÇÃO DO ESCOPO ...................................................................................29
4.1 CONTROLE DO ESCOPO DO PROJETO.......................................................................29
4.2 CONTROLE DE MUDANÇAS NO ESCOPO.................................................................30
4.3 VALIDAÇÃO DO ESCOPO......................................................................................................31
4.4 ESTIMATIVA DA DURAÇÃO E OS RECURSOS DAS ATIVIDADES
DO PROJETO.........................................................................................................................................32
5.PLANO DE GERENCIAMENTO DE RISCOS (IDENTIFICAÇÃO, ANÁLISE E
CONTROLE)......................................................................................................................................................33
5.1 ETAPAS DO PLANO DE GERENCIAMENTO DE RISCOS.....................................33
5.2 ANÁLISE QUALITATIVA DOS RISCOS..............................................................................34
5.3 ANÁLISE QUANTITATIVA DOS RISCOS..........................................................................34
5.4 ISO 31.000 - GESTÃO DE RISCOS......................................................................................35
CONSIDERAÇÕES FINAIS.........................................................................................................................36
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................................37
* A navegação deste e-book por meio de botões interativos pode variar de funcionalidade dependendo de cada leitor de PDF.
2
Volte ao Sumário
INTRODUÇÃO
A disciplina de “Gerenciamento do Escopo, Tempo e Risco de Projetos”

representa uma evolução sobre as práticas da gestão de projetos que
remontam a antiguidade, afinal esta atividade acompanha o ser humano desde
os primórdios da nossa civilização. As “Pirâmides de Giza” (2.550 a.C.) e a mais
adiante as “Muralhas da China” (600-206 a.C) são admirados projetos que
ainda permanecem de pé até hoje, mesmo tendo sido erguidos a partir de 4.600
anos atrás. Contudo, ao contemplarmos aquelas maravilhas sentimos falta de
saber exatamente como elas foram feitas, afinal o registro das atividades não
era uma preocupação daquela época. Este aspecto da documentação (não
somente dos princípios construtivos, mas da própria gestão dos projetos em si)
é algo característico das práticas atuais de gestão de projetos, as quais têm se
aprimorado levando em consideração princípios como os do “Gerenciamento
do Escopo, Tempo e Risco”, cujo papel merece destaque dentro daquilo que
conhecemos como a moderna gestão de projetos. A partir do século XIX, com o
surgimento da Escola da Administração Científica (Taylor e Fayol) passou a haver
um esforço para se sistematizar os processos dos projetos. Neste sentido, Henry
Gantt (1861-1919) trouxe muitos avanços nesta área e devido a isto é considerado
o “pai” da gestão de projetos, tendo contribuído com técnicas de planejamento
e de controle destinadas à gerência de projetos. Seus trabalhos são pioneiros e
embasam diversas ferramentas modernas, como o EAP (Estrutura Analítica do
Projeto), que estrutura a forma como os materiais são utilizados num projeto.
Após a publicação dos trabalhos de Gantt três aspectos merecem um destaque
maior nesta área: 1) o PERT (Program Evaluation and Review Technique) que
incluía ferramentas quantitativas complexas na gestão do programa de mísseis
instalados em submarinos (conhecido por projeto “Polaris”, com a participação
da Marinha dos Estados Unidos juntamente com a Lockheed Corporation); 2) o
CPM (Critical Path Method), que foi desenvolvido num esforço conjunto entre a
Du Pont Corp e a Remington Rand Corp, tendo inovado pela gestão de projetos
com ênfase nas decisões críticas na empresa; 3) o PMI (Project Management
Institute) criado em 1969 com o foco de consolidar as práticas de gestão de
projetos e assim sugerir as melhores ferramentas e técnicas para serem utilizadas
por todos os profissionais desta área. Derivado do PMI surgiu em 1996 o PMBOK
(Project Management Body of Knowledge), que é um guia da área, no qual são
registrados os padrões e práticas mais indicadas, a fim de que os profissionais de
gestão de projetos possam se manter atualizados.
Neste contexto, a coordenação de um projeto é exercida pelo Gerente de

Projeto, cujo foco reside na qualidade, no custo, no tempo e no escopo, procurando
3
Volte ao Sumário
minimizar falhas e desvios do planejamento, ao mesmo tempo em que busca

determinar e executar as necessidades dos clientes, aspecto fundamental na
sua função. Deste modo, ele está atento desde o chamado termo de abertura
do projeto (que embasa as fases seguintes e destaca as partes interessadas no
projeto), passando pelo planejamento (onde ele elabora o plano e as ferramentas)
e pelo seu desenvolvimento, até chegar na entrega e aceitação do projeto pelo
cliente.
4
Volte ao Sumário
1. GERENCIAMENTO DO ESCOPO
A palavra escopo compreende todas as atividades que fazem parte de um

determinado projeto, ou seja, tudo o que deve fazer parte de um projeto. De certa
forma isto se relaciona com o foco do projeto, afinal estas referidas atividades
estão direcionadas a um objetivo, a um foco. A gestão (ou o gerenciamento) do
escopo pretende certificar que somente o trabalho necessário à realização do
projeto faça parte do mesmo (PMBOK, 2013).
1.1 ETAPAS DO GERENCIAMENTO DO ESCOPO
O gerenciamento do escopo assegura que o projeto inclui todo o trabalho

necessário, e somente o necessário, para entregar com sucesso o produto final
do projeto. Seu objetivo básico é esclarecer o que está e o que não está incluído
no trabalho do projeto. O gerenciamento do escopo envolve as seguintes etapas:
• 1. Ter os seus requisitos levantados de modo detalhado;
• 2. Fazer a documentação de forma objetiva de todo o escopo do projeto;
• 3. Estruturar o escopo e detalhar a sua decomposição;
• 4. Se certificar que execução obedece com o que foi documentado para o escopo
do projeto;
• 5. Confirmar que as entregas estão sendo validadas pelo cliente;
• 6. Garantir que as mudanças no escopo obedecem aos parâmetros estabelecidos,
com seus impactos no projeto analisados e com os documentos do projeto altera-
dos para representar as alterações aprovadas (SOTILLE, MENEZES, XAVIER, PEREI-
RA, 2006).
A área de conhecimento de Gerenciamento do Escopo do Projeto apresenta

quatro processos de planejamento e dois processos de monitoramento e controle
do projeto. Para o gerenciamento do escopo, o primeiro passo é a elaboração
do Plano de gerenciamento do escopo que estabelece a regra do jogo para
planejar, monitorar e controlar o escopo do projeto, de modo a ficar claro para
diversas partes interessadas o que deve ser feito. A qualidade do planejamento do
escopo decide o sucesso ou o fracasso do projeto (VARGAS, 2003). Para tanto é
necessário:
• Saber qual é o objetivo do gerenciamento do escopo do projeto;
• Conhecer os processos para planejar e controlar o escopo do projeto;
• Entender a importância de coletar os requisitos do projeto;
• Aprender as ferramentas para coleta de requisitos.
1.2 PLANEJAR O GERENCIAMENTO DO ESCOPO

Trata-se do trabalho que visa criar um plano para levar a efeito o gerenciamento
do escopo do projeto. Esse plano documenta como o projeto será definido,
5
Volte ao Sumário
monitorado e controlado pela equipe do projeto e validado pela equipe do cliente.

O benefício da criação de um plano é estabelecer as diretrizes de como o escopo
será gerenciado ao longo do projeto. O Plano de gerenciamento do escopo é um
plano auxiliar do projeto. Para desenvolver o Plano de gerenciamento do escopo
e de seu detalhamento, primeiro inicia-se com a análise das informações contidas
no Termo de abertura do projeto, no Estudo de viabilidade do projeto e das
informações históricas de projetos anteriores do acervo do ativo organizacional.
A criação desse plano reduz o risco de “scope creep”, expressão que reflete
o efeito das mudanças não controladas no projeto (VARGAS, 2003). O Plano
de gerenciamento do escopo é o primeiro e o mais crítico para o sucesso do
projeto, pois subordina todos os demais planos auxiliares do projeto. O Plano de
gerenciamento do escopo contém:
• Processos para preparação e detalhamento do escopo do projeto.

• Processos que permitam criar a estrutura analítica do projeto.
• Processos que especifiquem como as entregas serão controladas.
• Processos que estabeleçam como a aceitação das entregas ocorrerá.
• Processos que definem como as mudanças do escopo serão processadas.
O Plano de gerenciamento do escopo pode ser formal ou informal, detalhado

e simplificado. Tudo depende das características do gerenciamento do projeto.
Além do Plano de gerenciamento do escopo, outro produto do trabalho inicial
do planejamento do escopo é o plano de gerenciamento dos requisitos. Esse
plano auxiliar descreve como os requisitos serão analisados, documentados e
gerenciados. Em geral, os componentes desse plano apresentam:
• Como serão planejadas e reportadas as atividades para coleta dos requisitos.
• Como os requisitos serão priorizados.
• Como as mudanças dos produtos serão iniciadas.
• Como os impactos serão analisados e reportados.
• Quais são os níveis de competência para aprovar as mudanças.
• Quais serão as métricas utilizadas.
• Como será a estrutura para permitir a rastreabilidade dos requisitos.
• Quais serão os atributos dos requisitos que serão registrados na Matriz de rastreabi-
lidade de requisitos (VARGAS, 2003).
Assim, são criados dois documentos para coleta e acompanhamento dos

requisitos do projeto:
• Documentação dos requisitos.
• Matriz de rastreabilidade dos requisitos (acompanha os requisitos).
1.3 COLETA DE REQUISITOS
Coletar os requisitos visa definir e documentar as funções e funcionalidades do

projeto e do produto do projeto para atendimento das necessidades e expectativas
6
Volte ao Sumário
quantificadas e documentadas do cliente e demais partes interessadas do projeto

(PMBOK, 2013). O sucesso do projeto depende da execução deste trabalho
de coleta. Os requisitos precisam ser detalhados o suficiente para permitir sua
medição durante a execução do projeto.
Os requisitos formam a base das informações para a criação da EAP –

Estrutura Analítica do Projeto. Os planejamentos do cronograma, do orçamento
e da qualidade tomam por base os requisitos levantados no planejamento do
escopo do projeto. O trabalho para coleta de requisitos começa com a análise das
informações contidas no Termo de abertura do projeto e no Registro das partes
interessadas, os quais foram desenvolvidos na iniciação do projeto. Os requisitos
de alto nível já foram registrados no Termo de abertura. Agora é necessário
detalhar e ampliar as informações das partes interessadas. Os requisitos podem
ser classificados em:
• •Requisitos do projeto.
• •Requisitos do produto.
Os requisitos do projeto envolvem os levantamentos de necessidades

do trabalho do projeto, como o gerenciamento do projeto e das entregas.
Os requisitos do produto envolvem as informações do produto, tais como os
requisitos técnicos, funcionalidades e seu desempenho. Os requisitos do produto
podem ser:
• Funcionais: o que o produto deve fazer;
• Não funcionais: uma qualidade que o produto deve ter.
De acordo com Vargas (2003) os requisitos não funcionais são:

• Requisitos sensoriais: aparência.
• Requisitos de usabilidade: baseados nos hábitos dos usuários.
• Requisitos operacionais: ambiente operacional para o produto.
• Requisitos de desempenho: quão rápido, preciso, seguro, confiável.
• Requisitos de segurança: segurança, confidencialidade e integridade do produto.
• Requisitos de “manutenibilidade” e portabilidade: quão mutável ou atualizável, bem
como portátil o produto precisa ser.
• Requisitos legais ou de padronização: de conformidade com leis ou padrões aplicá-
veis.
Para a coleta dos requisitos e do produto do projeto são utilizadas diversas

técnicas. O gerente de projetos deve utilizar a técnica mais apropriada para
cada parte interessada. Neste ponto devemos ficar alertas, pois um requisito não
identificado nesta fase pode exigir mudanças e criar conflitos durante a execução
do projeto. Trataremos de técnicas e ferramentas que ajudam na identificação dos
7
Volte ao Sumário
requisitos (as quais posteriormente também são utilizadas no aspecto da Análise

Qualitativa de Riscos). Deste modo estas técnicas são:
- Entrevistas - entrevistas individuais feitas com cada parte interessada.

Geralmente, parte-se de um questionário inicial enviado com antecedência para o
entrevistado; à medida que ele dá as informações, novas perguntas podem surgir.
Na maior parte das vezes, são individuais, mas podem envolver também grupos. É
importante entrevistar partes interessadas no projeto como o cliente, especialistas
da área e profissionais experientes em projetos semelhantes. Isso dará o suporte
necessário para identificar e definir que funções e itens são importantes para o
projeto. Percebe-se que o cliente é mais objetivo, mas pode perder perspectiva,
ou pode não conhecer algum aspecto importante ou não notar uma consequência
de um requisito. Por isso, é necessário levantar e comparar os requisitos fornecidos
pelas diversas partes interessadas (XAVIER, 2008).
- Grupos focais - o objetivo do grupo focal é reunir as diversas partes

interessadas e especialistas de uma área para entender as expectativas e
percepções sobre um aspecto do projeto. Para ser eficiente, uma pessoa de fora
da discussão deve assumir o papel de facilitador para promover uma discussão
interativa sobre o assunto. Diferente da entrevista, o foco se volta mais para uma
conversa. A ideia é economizar tempo, pois, às vezes, em entrevistas individuais,
os interessados têm pontos de vista divergentes.
- Workshops facilitados - são sessões que trazem profissionais de

áreas funcionais para definir os requisitos. É uma técnica muito utilizada para
rapidamente definir requisitos que transpassam diversas áreas da organização e
conciliar as diferenças. Com estas sessões, podem ser descobertas incoerências
nos requisitos para que sejam analisadas. Abaixo, temos uma ideia de como esses
workshops acontecem:
•Os grupos de partes interessadas mais importantes, de preferência todos,

são convidados a comparecer e juntos acompanhar o problema que o projeto
deverá resolver e produzir.
•Todas as cartas são postas na mesa objetivamente, de forma a poupar tempo.
•Assim, pode-se efetuar uma identificação completa dos problemas (causa e
efeito) e encontrar as soluções certas.
•Uma imagem comum e estruturada daquilo que o projeto irá construir é
obtida.
•Erros e conflitos são evitados durante a execução (VARGAS, 2003).
8
Volte ao Sumário
- Técnicas criativas de grupo - são atividades em grupo que podem ser

usadas para identificar requisitos do projeto e do produto a ser criado, ou mesmo
formas alternativas de solução. Seguem alguns exemplos:
Brainstorming: Todos os participantes apresentam qualquer coisa sobre o

projeto e produto que lhe vem à mente. A ideia não é tolher as ideias, e sim anotar
todas, para que a criatividade possa fluir. Depois os participantes votam nas
melhores ideias, para que sejam priorizadas.
Mapa mental – trata-se de um diagrama de ideias para gerar, classificar e

registrar informações.
Diagrama de afinidade – as ideias geradas por qualquer outra técnica são

classificadas de acordo com sua semelhança (VARGAS, 2003).
Técnicas de tomada de decisão - visam facilitar a tomada de decisão em

grupo, como numa votação. O resultado pode ser escolhido por unanimidade
(consenso), por maioria absoluta, pelo grupo maior ou mesmo por decisão de
uma pessoa do grupo.
Questionários e pesquisas - auxiliam na tomada de decisões específicas,

mais apropriados para grandes públicos. O questionário deve ser preparado para
obter respostas objetivas e parametrizáveis.
Protótipos - uma forma de obter o feedback dos interessados criando algo

que eles possam experimentar. Muito usado em manufatura e em sistemas,
quando as telas são mostradas sem executar funções, ou executando funções
simuladas. Protótipos são úteis para a coleta de requisitos porque os usuários
podem experimentar o produto pronto e mostrar os pontos fortes e fracos. Há
algo concreto para criticar.
Observações - as pessoas geralmente acham difícil descrever o que fazer. Às

vezes, a melhor forma de entendê-las é observá-las, mesmo que o processo esteja
documentado. Os processos reais de trabalho geralmente diferem daqueles
processos formalmente descritos. A ideia é observar os indivíduos e como eles
executam seu trabalho. O observador pode assumir o papel de “sombra” da pessoa
que está sendo observada, o que provoca pouca interferência. Alternativamente,
9
Volte ao Sumário
pode o observador executar o trabalho junto com a pessoa observada, para

confirmar o entendimento (VARGAS, 2003).
Técnica Delphi - Inicialmente podemos dizer que ela é uma técnica de

obtenção de informações. A circunstância na qual ela é indicada é onde existe
certo grau de confronto nas informações, desse modo a expressão direta de uma
das partes tenderia a causar constrangimento e melindre na outra. Exemplo:
Numa reunião de “brainstorming” se alguém diz que “fulano de tal” é o causador
de problemas devido a “tal e tal aspecto”, o que tenderia a gerar problemas de
relacionamento na empresa, atritos, etc. Nesse sentido, muitas vezes as pessoas
não se manifestam na frente da outra (causadora do problema) justamente para
evitar esta situação do tipo “saia justa” e a empresa fica sem debater como resolver
aquela situação. E como a técnica Delphi pode ajudar em problemas como este?
Na técnica Delphi os relatos de situações como esta são protegidos pelo

anonimato, ou seja, ninguém fica sabendo quem expressou aquela opinião e
como tudo fica impessoal é mais fácil se evoluir para a solução do problema. Em
primeiro lugar, esta técnica define o escopo do que se vai analisar, ou seja, o assunto
é restringido para se obter objetividade. Então é definido um “facilitador”, que é
a pessoa que irá compilar as informações. É elaborado um roteiro / questionário
para nortear as discussões e o grupo de pessoas que será entrevistado. Após
preenchidos os questionários são devolvidos e eles devem ser compilados de
modo a assegurar o anonimato (às vezes apenas pela maneira como a pessoa se
expressa todos já o identificam, então esta compilação deve preservar a ideia, mas
não a forma). Na próxima fase esta compilação é distribuída para os entrevistados,
a fim de que a pessoa tenha condições de reavaliar a sua opção, mudar de ideia,
complementar a sua resposta (VARGAS, 2003).
Em seguida as perguntas vão sendo mais e mais focadas, sendo que este
processo que compilar e redistribuir é feito diversas vezes, até que se obtém um
nível razoável de consenso (não de unanimidade), ou seja, se percebe que caso
se faça uma nova rodada o nível de respostas irá ser basicamente o mesmo. Nesta
fase é compilado e analisado o resultado final. Note que ela é uma técnica que
toma tempo, porém consegue aprofundar questões que afligem a organização
e que dificilmente seriam endereçadas se não fosse pela Delphi, ou seja, ela tem
uma grande valia em determinadas situações.
1.4 PROCESSO DE DEFINIÇÃO DO ESCOPO

O processo de definir o escopo trata da elaboração da descrição detalhada do
trabalho do projeto e do seu produto. É crítico para o adequado desenvolvimento
10
Volte ao Sumário
do projeto. Trata-se de um trabalho elaborado progressivamente, à medida que

as informações sobre o projeto se tornam conhecidas pela equipe. Documentar
o trabalho que irá gerar o produto do projeto. Para tanto, cria o documento
denominado declaração do escopo do projeto, que fará parte de decisões futuras
do projeto (XAVIER, 2008)
1.4.1 Declaração do escopo
A Declaração do escopo do projeto descreve em detalhes as entregas do

projeto e o trabalho necessário para criar essas entregas. Também especifica
claramente o que não está no projeto, para nivelar as expectativas das partes
interessadas. Esse documento é uma das bases para se avaliar, mais à frente, as
solicitações de mudança. Quanto mais clara a Declaração, mais claro fica averiguar
se algum pedido está dentro ou fora do escopo acordado do projeto.
Não se deve avançar no desenvolvimento do planejamento do projeto

sem conhecer muito bem seu produto. Para tanto, é importante fazer a análise
do produto com o intuito de conhecer os objetivos e a descrição definidos pelo
cliente e transformá-los em entregas tangíveis.
Também há necessidade de verificar se há alternativas para executar o

trabalho do projeto. Escolha a melhor abordagem e, eventualmente, selecione
uma de menor custo. A Declaração do escopo do projeto é diferente da
Documentação dos requisitos, pois a abordagem é do ponto de vista do projeto
e a Documentação dos requisitos do ponto de vista do cliente. A Declaração do
escopo deve ser escrita com clareza, de modo que diferentes partes interessadas
do projeto tenham o mesmo entendimento do que deve ser feito (SOTILLE,
MENEZES, XAVIER, PEREIRA, 2006).
1.4.2 Elementos da Declaração do Escopo

A Declaração do Escopo é composta dos seguintes elementos:
-Descrição do escopo do produto – define as características do produto
final do projeto. Sua elaboração é progressiva e toma por base as informações do
Termo de abertura e a Documentação dos requisitos.
-Critérios de aceitação do produto - estabelece o processo/critério de
aceitação para que as entregas sejam consideradas concluídas. É o critério pelo
qual o cliente concorda em aceitar a entrega. Pode incluir requisitos técnicos, de
qualidade e de tempo. Cada requisito deve ser específico, mensurável e atingível.
O mais importante é que o cliente e o gerente concordem sobre o significado
dos critérios de aceitação, para que não haja dúvida sobre a aceitação ou não da
11
Volte ao Sumário
entrega. Exemplo: medir o tempo de resposta ao atendimento no horário entre

8h e 17h dos dias úteis. Critério de aceitação acordado: tempo de resposta <= 2
min (XAVIER, 2008).
-Entregas do projeto – representam o que deve ser obrigatoriamente
produzido para a execução do projeto. São as entregas que compõem o produto
do projeto propriamente dito. Contemplam também os resultados auxiliares, tais
como os documentos de gerenciamento de projeto, como a EAP, o cronograma
e orçamento. Devem ser mensuráveis e verificáveis.
-Exclusões do projeto – identificam o que o projeto não irá fazer. Informa
explicitamente o que está fora do escopo, de modo a nivelar as expectativas das
partes interessadas. É a maneira contrária de definir o escopo, pois explicita o que
não será feito pelo projeto.
-Premissas do projeto – são hipóteses consideradas verdadeiras, para fins de
planejamento do projeto, criadas pela sua equipe. Podem estar certas ou erradas,
ou seja, são riscos para o projeto. As premissas são documentadas porque, caso
alguma se revele falsa, existe um acordo tácito que haja um replanejamento
(SOTILLE, MENEZES, XAVIER, PEREIRA, 2006).
-Restrições do projeto – são limites impostos ao projeto, que restringem as
opções de planejamento da equipe. São de origens externas ao projeto.
Conforme Vargas (2003) as restrições podem ser:

•Restrições de tempo - qualquer limitação ou condição colocada em
relação ao cronograma do projeto que afeta o momento em que uma atividade
do cronograma pode ser agendada. Geralmente está na forma de datas impostas.
•Restrições de custo - qualquer limitação ou condição colocada em relação
ao orçamento do projeto, como financiamentos disponíveis ao longo do tempo.
•Restrições de recursos - qualquer limitação ou condição colocada em
relação à utilização de recursos, como habilidades ou conhecimentos específicos
e quantidades disponíveis em um determinado período do projeto.
12
Volte ao Sumário
2. ESTRUTURA ANALÍTICA DO PROJETO (EAP)
EAP significa Estrutura Analítica do Projeto (na língua inglesa é conhecida

como WBS – Work Breakdown Structure).
A EAP é a “alma” do projeto e representa todo o trabalho do projeto, permitindo
uma visão completa do trabalho. Sem ela, é muito provável que algo possa ser
esquecido (PMBOK, 2013).
O que não estiver representado na EAP, não está no escopo do projeto. Um
projeto, seja grande ou pequeno, complexo ou simples, sem o suporte da EAP
dificilmente está sendo bem gerenciado.
2.1 CRIAR A EAP
O processo de Criar a EAP consiste em decompor as entregas e o trabalho

do projeto em componentes menores e mais facilmente gerenciáveis (VARGAS,
2003). A EAP - Estrutura Analítica do Projeto é mais usualmente representada
por um diagrama, mas também pode ser representada por lista estruturada.
A EAP é:
•Uma imagem gráfica da hierarquia do escopo do projeto.

•Criada pela equipe do projeto com a eventual participação de partes
interessadas.
•Estruturada de acordo com a forma que o trabalho será realizado e
controlado.
•Crítica ao planejamento de demais áreas de conhecimento (XAVIER, 2008).
A EAP tem como objetivo o gerenciamento do projeto. Segundo Vargas

(2003) ela especificamente, objetiva:
•Mostrar graficamente o escopo do projeto.

•Tornar claro para a equipe do projeto qual é o trabalho a ser feito, de acordo
com o especificado na Declaração do escopo do projeto.
•Permitir a visualização de todo escopo do projeto pelas partes interessadas
e conferência de que nada está faltando.
•Permitir apontar responsabilidades.
13
Volte ao Sumário
•Permitir estimativas mais precisas.

•Servir de base para a criação do cronograma e orçamento.
•Permitir maior controle do escopo, de modo a assegurar que o escopo do
projeto está completo ao terminar o trabalho representado no gráfico.
Os benefícios da criação da EAP são:

•Redução de solicitações de mudança, já que a estruturação do escopo ajuda
a enxergar melhor o produto do projeto.
•Aumento do comprometimento da equipe do projeto, já que a equipe
elabora e detalha a EAP, permitindo que qualquer membro da equipe entenda a
parte que lhe cabe no trabalho.
•Facilitação da comunicação interna da equipe do projeto e externa com as
partes interessadas (XAVIER, 2008).
2.2 DECOMPOSIÇÃO DA EAP
A decomposição da EAP é um processo hierárquico de cima para baixo.

Cada nível descendente da EAP detalha com maior clareza o trabalho planejado
do elemento superior (SOTILLE, MENEZES, XAVIER, PEREIRA, 2006).
A decomposição da EAP é orientada para as entregas, que são elementos

tangíveis e mensuráveis do projeto, mas também deve incorporar o trabalho
auxiliar, como o Plano de gerenciamento do projeto (VARGAS, 2003).
As entregas são resultados dos esforços da equipe de projeto e não devem

ser confundidas com as atividades, que são os esforços associados às construções
das entregas.A EAP não representa relações de dependências de execução, mas
sim o que deve ser executado (XAVIER, 2008).
Até onde decompor é uma questão em aberto para cada projeto. Um

detalhamento excessivo é um esforço gerencial grande e por vezes desnecessário.
Por outro lado, poucos níveis de decomposição podem dificultar o trabalho
de gerenciamento do projeto. Os níveis mais baixos dos ramos da EAP são
denominados pacotes de trabalho. Um pacote de trabalho é uma entrega que
não é mais subdivida. Nela é possível elaborar listas de atividade do cronograma,
estimativas de recursos de pessoal, estimativas de custos, avaliação da qualidade,
avaliação de comunicações, do engajamento das partes interessadas, identificação
de riscos e necessidade de aquisições.
14
Volte ao Sumário
Os níveis e os elementos da EAP são numerados para permitir sua pronta

identificação. Essa estrutura de código de conta permite o somatório de custos
e recursos em uma determinada conta de controle. Por exemplo, a entrega 3.2
é obtida pela soma das entregas 3.2.1 e 3.2.2. (VARGAS, 2003). A EAP do projeto
pode ser baseada na EAP de projetos semelhantes realizados. Segundo Xavier
(2008) a decomposição da EAP segue a regra:
• nível 1 - o nome do projeto.

• nível 2 - fases do ciclo de vida do projeto.
• nível 3 – principais entregas das fases.
• nível 4 - entregas necessárias para concluir as principais entregas das fases.
• nível 5 – entregas menores até que os pacotes de trabalho estejam definidos em de-
talhe suficiente para verificar se as estimativas de custo e tempo, assim como a iden-
tificação de riscos, podem ser desenvolvidas neste nível de detalhe e se é possível
atribuir a responsabilidade para a execução do mesmo.
A decomposição chega a um nível adequado quando:

• Permite estimar com confiança.
• Não pode ser logicamente mais decomposta.
• Tem uma conclusão lógica e uma entrega tangível.
• Pode ser concluída sem interrupções.
• Pode ser executada sem a necessidade de mais informações.
• Pode ser terceirizada.
• Pode ser delegado um responsável (XAVIER, 2008).
Após conclusão da decomposição é necessário verificar o trabalho, pois

ocorrem duas situações:
Situação 1 - Faltam pacotes de trabalho. Neste caso: Existem partes do escopo

que precisam ainda de decomposição para permitir o adequado gerenciamento.
Situação 2 - Existem pacotes de trabalho demais. Neste caso: EAP se tornou

um conjunto de pequenas entregas que se confundem com as atividades do
cronograma. Assim, é necessário reavaliar (VARGAS, 2003).
De modo a facilitar o controle, há uma regra prática para decomposição de

um pacote de trabalho que recomenda que a duração prevista não seja menor
que 8 horas (um dia de trabalho) ou maior que 80 horas (uma quinzena).
15
Volte ao Sumário
2.3 DICIONÁRIO DA EAP
Os nomes dos elementos da EAP, com suas expressões curtas, por vezes, não
permitem o adequado entendimento da entrega. Essa dificuldade é superada
com o Dicionário da EAP, que fornece descrições dos trabalhos que devem ser
feitos nos pacotes de trabalho. Assim, o Dicionário da EAP é um facilitador para
a equipe e evita esforços desnecessários. Na fase de execução do projeto, ele
pode ser usado para as emissões das Ordens de Serviço - OS, com informações
tais como, as datas de início e fim das atividades e a relação dos recursos a serem
mobilizados. Além da obrigatoriedade do código identificador e da descrição da
entrega, as informações do Dicionário da EAP podem ser:
• Código identificador (obrigatória)
• Descrição da entrega (obrigatória)
• Recursos envolvidos
• Responsável pelo trabalho
• Datas importantes
• Requisitos de qualidade
• Referências técnicas
• Lista de atividades
• Estimativa de custos (VARGAS, 2003).
2.4 LINHA BASE DO ESCOPO
A Linha de base do escopo é composta pela Declaração do Escopo do Projeto,

EAP e Dicionário da EAP. Ela compõe o Plano de gerenciamento do projeto. O
desempenho do projeto, bem como do gerente do projeto, está associado ao
atendimento da Linha de base de seu escopo (XAVIER, 2008).
16
Volte ao Sumário
3. ORGANIZAÇÃO E SEQUENCIAMENTO DAS

ATIVIDADES DE UM PROJETO
Organizar e sequenciar um projeto significa tomar decisões sobre a forma e

a ordem de como os seus recursos serão alocados, bem como a avaliação dos
possíveis impactos que mudanças no plano do projeto poderão ter sobre o projeto
como um todo. Além disso, o produto do projeto também precisa ser integrado
às necessidades operacionais da empresa. Isto significa que, por exemplo, que a
área operacional que sentirá o impacto do projeto precise da ajuda da equipe de
projetos por algum tempo, assim que o produto final for entregue para a área de
operações (XAVIER, 2008).
Quando nos referimos a organização e ao sequenciamento de um projeto

ficamos com a impressão inicial de que existe um limite claro entre os diferentes
processos a serem integrados, contudo a realidade é um pouco diferente disto.
Muitos destes processos se sobrepõem e para distingui-los é necessário o
conhecimento do Gerente de Projeto e de sua equipe.
Quando pensamos em na determinação do escopo, este processo tem

origem na determinação das linhas gerais de um projeto, o qual deve ter clara
uma orientação quanto a sua execução e gestão, a fim de que isto posteriormente
possa ser verificado e controlado, para, no caso de todos os aspectos terem
sido devidamente executados, o projeto em questão possa ser devidamente
encerrado. Esta questão que acabamos de pontuar também é denominada de
gerenciamento da integração (VARGAS, 2003).
Conforme Xavier (2008) e no quadro a seguir, os processos de gerenciamento

são organizados e sequenciados em cinco grupos: 1) processos na iniciação (termo
de abertura do projeto), 2) processos no planejamento (do gerenciamento do
projeto), 3) processos na execução (definir o trabalho do projeto), 4) processos
no monitoramento e controle (controlar o trabalho e integrar as mudanças), 5)
processos no encerramento (de uma fase ou do projeto em si).
17
Volte ao Sumário
Fonte: “Organização e Sequenciamento das Etapas de um Projeto” (Adaptado de Xavier, 2008)
Iniciação ou termo de abertura do projeto - DIz respeito ao desenvolvimento

de uma documentação formal que permite que o projeto (ou uma de suas fases)
se inicie e deixa devidamente registrado todos os requisitos que irão atender aos
interessados no projeto.
Planejamento (ou plano) do gerenciamento do projeto - Etapa onde é

confeccionada a documentação que contém as ações que irão definir, integrar
e supervisionar os chamados planos auxiliares do projeto, o que ocasiona no
Planejamento de gerenciamento do projeto, que é a maior fonte de dados sobre o
modo com que o projeto será planejado, posto em prática, verificado, controlado
e encerrado.
Execução - Esta etapa é fundamental para que o projeto cumpra os seus

objetivos e norteia a forma como as atividades planejadas serão postas em
prática vis-à-vis às diferentes interfaces que existem com os aspectos técnicos e
organizacionais.
Monitoramento e controle - Etapa que monitora os progressos do projeto na

direção das suas metas definidas no planejamento do gerenciamento do projeto
e efetua controles para manter o projeto dentro dos parâmetros estabelecidos.
Deste processo fazem parte relatórios com as medições versus o que foi planejado/
orçado para cada uma das áreas envolvidas. Outra questão importante neste
processo é a análise e aprovação de mudanças do projeto, as quais precisam ser
avaliadas tendo em vista as entregas previstas no planejamento.
Encerramento - Neste processo todas as atividades do gerenciamento de

projetos são formalmente encerradas.
18
Volte ao Sumário
3.1 O TERMO DE ABERTURA DO PROJETO (TAP)
Do ponto de vista prático, o TAP é o documento que dá origem ao projeto e

autoriza o seu início (SOTILLE, MENEZES, XAVIER, PEREIRA, 2006).
Ele pode ter um teor mais simplificado ou mais detalhado dependendo

do nível de informações disponíveis quando da sua emissão pelo Patrocinador
do Projeto, sendo que neste momento, o Estudo de Viabilidade do Projeto
geralmente é consultado (sendo algo praticamente mandatório em empresas de
grande porte).
Durante quase todo o ciclo de vida de um projeto o TAP é consultado para

que possam ser devidamente avaliadas as mudanças propostas. Sempre é
recomendado que o Gerente do Projeto participe da sua elaboração.
Somente o Patrocinador do Projeto pode alterar o TAP, conforme haja a

necessidade pela situação em que o negócio se encontra, para corrigir alguma
falha ou mesmo para poder se aproveitar de uma oportunidade.
O TAP possui os seguintes elementos:
• Nome do projeto;
• Objetivos do projeto;
• Produto do projeto;
• Cronograma;
• Orçamento;
• Riscos relevantes,
• Gerente do Projeto e sua autoridade;
• Cliente;
• Patrocinador (VARGAS, 2003).
O nome do projeto é o chamariz de marketing para “vender” o projeto,

portanto ele deve de forma direta remeter à organização do que se trata o projeto,
sendo que a identidade visual pode ajudar neste conceito (VARGAS, 2003).
Os objetivos do projeto precisam ter uma conotação estratégica à organização,

de algum aspecto que será atendido por meio daquele projeto. Isto facilita a
posição do patrocinador e também motiva a equipe a buscar aquele objetivo.
Em outras palavras, todos precisam saber claramente qual o motivo de estarem
ali trabalhando. O embasamento para aqueles objetivos geralmente advém do
Estudo de Viabilidade, que aponta as oportunidades e estabelece o foco, o qual,
19
Volte ao Sumário
por sua vez, precisa ser algo mensurável (exemplo: aumentar a produtividade em
10% em doze meses).
O(s) produto(s) do projeto necessita atingir as especificações (de natureza

interna, ou contratual). As expectativas do cliente, do patrocinador e dos
interessados precisam estar refletidas no produto. Os níveis de desempenho, as
condições técnicas, de qualidade, de tempo precisam ser atingidas, deste modo
o gerente do projeto e o cliente devem estar sempre próximos discutindo os
critérios para aceitação para aquele produto.
O cronograma estima a ocorrência das etapas e eventos, sendo que

geralmente os prazos são calculados a partir do andamento de projetos
semelhantes.
O orçamento insere uma ordem de grandeza para os custos, contudo quanto

mais novo (e desconhecido) for um projeto maior deve ser o nível de tolerância
quanto aos custos. Na medida em que o projeto avança o orçamento começa a se
tornar mais preciso, o que é ainda potencializado caso se possa compará-lo com
outros projetos semelhantes (XAVIER, 2008).
A questão dos riscos relevantes é muito importante, afinal quanto maior o

nível de conhecimento com relação aos riscos, maior podem ser as ações tomadas
para preveni-los. Estes riscos devem ser sempre compartilhados com as partes
interessadas, a fim do nivelamento das expectativas.
O Gerente do Projeto (e sua autoridade) corresponde a um aspecto

estratégico, afinal ele é o responsável pelo sucesso ou pelo fracasso de um projeto.
Deste modo, quanto antes ele puder ser escolhido melhor será para o projeto
como um todo. Além disso, o nível de autoridade do Gerente de Projetos precisa
ser formalizado e ser compatível com o nível de responsabilidade que ele tem (ele
dificilmente tem plena liberdade para fazer o que bem entender, ao contrário, ele
precisa ter as suas ideias aprovadas primeiro).
Já o Patrocinador é a interface do projeto junto à alta administração da

empresa, deste modo ele defende e aprova internamente o orçamento daquele
projeto, portanto o quanto mais politicamente forte for o patrocinador melhor
será para o projeto (SOTILLE, MENEZES, XAVIER, PEREIRA, 2006).
20
Volte ao Sumário
3.2 DESENVOLVIMENTO DO PLANO DE GERENCIAMENTO DO

PROJETO
O Plano de Gerenciamento do Projeto permite conhecer como o projeto

será planejado, executado, monitorado, controlado e encerrado. Tomará
conhecimento dos diversos planos auxiliares que compõem este Plano. A ideia
aqui pode ser compreendida a partir da analogia de uma partida de futebol, na
qual não haveria regras definidas, assim ela precisaria ser interrompida várias vezes
para se analisar as diferentes situações (exemplo: quando a bola bate na trave isto
pode ser considerado gol…?). Justamente para questões deste tipo é que serve o
Plano de Gerenciamento do Projeto! Tendo em mente esta perspectiva, se deve
conhecer o objetivo do plano de gerenciamento de projeto, saber quais são os
seus planos auxiliares, se aprender sobre linhas de base do projeto, se conhecer a
sequência para a elaboração do plano do projeto.
Este processo será a fonte principal de informações sobre como desenvolver o

projeto e é realizado pela equipe de gerenciamento do projeto com a participação
de diversas partes interessadas, cujas especializações são necessárias para a
adequação do trabalho. A definição da participação das partes interessadas é feita
pelo gerente de projetos. É um documento composto de diversos planos auxiliares.
Sua elaboração é progressiva, à medida que há um melhor entendimento do que
deve ser executado pelo projeto. Durante todo ciclo de vida do projeto, este Plano
pode e deve ser atualizado, à medida que as mudanças vão ocorrendo (XAVIER,
2008).
A infraestrutura de TI e de comunicações, sua estrutura de governança,

padrões existentes na organização ou na área de aplicação do projeto, informações
históricas, entre outros aspectos, influenciam no desenvolvimento do plano do
projeto. Neste ponto, é importante que você considere que a única certeza que
se tem em relação ao plano é que dificilmente será implantado exatamente como
planejado (SOTILLE, MENEZES, XAVIER, PEREIRA, 2006).
A sequência inicial para o trabalho de planejamento do projeto é rígida:

Escopo, Tempo, e Custo. Depois seguem, de acordo com as características do
projeto, sem a mesma rigidez as áreas de conhecimento: Qualidade, Recursos
Humanos, Comunicações, Engajamento das Partes Interessadas, Riscos e
Aquisições. Apesar da sequência lógica, é um trabalho iterativo. Por exemplo,
durante o planejamento das aquisições, você pode ser surpreendido por uma
informação do mercado fornecedor sobre os prazos e custos dos fornecimentos
diferentes dos inicialmente previstos. Neste caso, os planejamentos já concluídos
21
Volte ao Sumário
devem ser novamente refeitos. É assim mesmo, fazer e refazer, até se chegar a um
consenso. Talvez a fase de planejamento seja a mais importante de um projeto.
O Plano de gerenciamento do projeto integra e consolida todos os planos

auxiliares de gerenciamento de projetos. Cada plano auxiliar é detalhado de
acordo com as necessidades da área de conhecimento envolvida no projeto,
conforme o nível de aplicação de cada processo selecionado (XAVIER, 2008).
O Plano de gerenciamento do projeto é também denominado Plano do Projeto.
Segundo Vargas (2003) os Planos Auxiliares são os seguintes,:
•Plano de gerenciamento dos requisitos - Define como os requisitos serão

analisados, documentados e gerenciados durante todo o projeto.
•Plano de gerenciamento do escopo - Orienta como o escopo será definido,

documentado, verificado, gerenciado e controlado.
•Plano de gerenciamento do cronograma - Documentar os processos de

gerenciamento do tempo e suas ferramentas e técnicas que serão utilizadas.
•Plano de gerenciamento dos custos - Estabelece as atividades e os critérios

de planejamento, estruturação, estimativa e controle dos custos do projeto.
•Plano de gerenciamento da qualidade - Descreve como as políticas de

qualidade na organização serão aplicadas e define os procedimentos de controle
e garantia de qualidade e o processo de melhoria contínua para o projeto.
•Plano de melhorias no processo - Descreve as etapas de análise das

atividades de valor dos processos objetivando a exclusão ou eliminação de
desperdícios e ineficiências.
•Plano de gerenciamento dos recursos humanos - Documenta como os

recursos humanos devem ser definidos, aplicados e gerenciados.
•Plano de gerenciamento das comunicações - Registra as necessidades

das partes interessadas, os meios e métodos de comunicação e a frequência que
deverão ocorrer.
22
Volte ao Sumário
•Plano de gerenciamento dos riscos - Documentar como será estruturado

o gerenciamento dos riscos ao longo do projeto.
•Plano de gerenciamento das aquisições - Descreve como os processos

de aquisição serão gerenciados de acordo com as necessidades do projeto.
•Plano de gerenciamento de configurações - Aquele que registra como

a documentação do projeto deve ser identificada e controlada e suas revisões
tratadas. Também deve fazer parte dele os procedimentos de como será feita a
análise e aprovação das mudanças solicitadas durante a execução do projeto.
É importante definir um sistema claro de gerenciamento de mudanças. Todo

projeto deve possuir uma sistemática que estabeleça como as mudanças serão
solicitadas, quem deverá aprovar as mudanças e como elas serão comunicadas às
partes interessadas (VARGAS, 2003).
O Plano do Projeto é composto por duas partes. O plano propriamente dito

e as linhas de base, pelas quais o desempenho do projeto será avaliado. As linhas
de base do projeto são:
• a) Linha de base do escopo (Declaração do Escopo, Estrutura Analítica do Projeto e
Dicionário da EAP);
• b) Linha de base do cronograma (cronograma);
• c) Linha de base do desempenho de custos (orçamento).
Durante a fase de execução, estas linhas de base são dinâmicas e com a

utilização da técnica de gerenciamento de valor agregado, essas três linhas
combinadas formam a linha de base de desempenho do projeto.
3.3 EXECUÇÃO E CRONOGRAMA
A execução do trabalho e atividades definidas dentro do cronograma

planejado do projeto e das solicitações de mudança é essencial para se atingir os
objetivos do projeto (SOTILLE, MENEZES, XAVIER, PEREIRA, 2006).
Os tipos de atividades são:
• Executar as atividades para realizar os objetivos do projeto.

• Criar as entregas do projeto.
• Formar, treinar e gerenciar os membros da equipe do projeto.
• Obter, gerenciar e usar os recursos humanos, equipamentos, instalações, materiais e
23
Volte ao Sumário
ferramentas.
• Implementar os padrões e os métodos planejados.
• Implantar atividades de melhoria nos processos.
• Estabelecer e gerenciar os canais internos e externos de comunicação do projeto.
• Gerar dados do projeto, tais como custos, cronograma, progresso técnico e informa-
ções sobre o ndamento do projeto.
• Emitir solicitações de mudança.
• Adaptar as mudanças aprovadas.
• Gerenciar os riscos e implantar as atividades de resposta a riscos.
• Gerenciar fornecedores.
• Coletar e documentar as lições aprendidas (XAVIER, 2008).
Os trabalhos de orientar e gerenciar são as principais atividades do gerente

do projeto. É preciso garantir o entendimento comum do trabalho do projeto.
Para tanto, por exemplo, é importante:
• Garantir que o Plano de comunicação seja seguido pela equipe do projeto.
• Garantir que as partes interessadas tenham consciência de como serão afetadas
pelo projeto.
• Garantir o entendimento das exclusões do escopo do projeto.
• Garantir que os setores da organização que estão disponibilizando recursos para
o projeto tenham a última versão do cronograma e de que o mesmo efetivamente
atenda aos parâmetros descritos no planejamento (VARGAS, 2003).
• Confirmar que os gerentes estão cientes dos relatórios emitidos pelo projeto.
Gerenciar é lidar com pessoas. Para tanto, é preciso:

• a) Circular as informações do projeto entre os membros da equipe.
• b) Facilitar as discussões para seleção de opções.
• c) Interceder junto aos setores da organização na superação de barreiras.
• d) Trabalhar na solução de problemas da equipe.
3.4 MONITORAR E CONTROLAR AS ATIVIDADES
Este é o processo de acompanhar, revisar e avaliar o andamento do projeto

para atender aos objetivos de desempenho definidos no plano de gerenciamento
do projeto. Inclui a coleta, a medição e a distribuição das informações sobre o
desempenho e a avaliação das medições e tendências para efetuar melhorias no
processo.
Os desdobramentos do processo de monitoramento e controle do projeto

são:
• a) Comparar o desempenho real do projeto com o planejado.
• b) Avaliar o desempenho para determinar a necessidade de ações corretivas ou pre-
ventivas.
• c) Fornecer informações para suporte aos relatórios de progresso.
• d) Monitorar a implantação das mudanças aprovadas (VARGAS, 2003).
24
Volte ao Sumário
Da mesma forma que as batidas do coração são medidas por um aparelho,

o monitoramento contínuo do andamento do projeto permite que a equipe de
gerenciamento do projeto tenha uma visão clara da saúde do projeto e identifique
as áreas que exigem atenção especial. Nos projetos de grande porte, o gerente de
projetos não consegue participar de todas as frentes de trabalho do projeto. Por
outro lado, ele é responsável por emitir solicitações de mudanças para efetivar os
ajustes no andamento do projeto, bem como atualizar o plano do projeto (XAVIER,
2008).
Esse trabalho também contempla o acompanhamento dos indicadores de

desempenho criados para o projeto. O resultado do trabalho de monitoramento e
o controle do trabalho do projeto são as solicitações de mudanças e atualizações
no plano do projeto. As solicitações de mudanças envolvem:
• Ações corretivas
• Ações preventivas
• Reparos de defeitos
As ações corretivas são tomadas para trazer de volta o desempenho do

projeto de acordo com o planejado (de volta às linhas de base). Lidam com desvios
já ocorridos. As ações corretivas são baseadas em:
• Contínua medição dos processos;
• Saber quando o projeto saiu dos trilhos;
• Habilidade de achar a causa-raiz do problema e não sua consequência.
As ações preventivas são tomadas para evitar que o projeto se distancie da

linha de base. Elas lidam com desvios de desempenho que podem vir a acontecer.
Requerem mais experiência da equipe do que cálculos. São exemplos de ações
preventivas:
• Ações para evitar que o problema se repita;
• Troca de um recurso motivado quando a entrega por ele realizada não atingiu o cri-
tério de aceitação;
• Treinamento para um profissional para que ele possa se tornar um backup de um
recurso-chave.
O reparo de defeito é o mesmo que retrabalho. Ocorre quando um

componente do projeto não atende às especificações. São exemplos de reparos
de defeitos:
• Rejeição de uma entrega pelo cliente por falta de qualidade.
• Rejeição de uma entrega pelo controle de qualidade do projeto.
• Entrega com escopo incompleto.
25
Volte ao Sumário
Outro fator crítico para o adequado monitoramento e controle é a definição

da frequência do ciclo de controle. A frequência pode ser diária, semanal, mensal,
tudo depende das características do projeto e do tipo de trabalho que está
sendo desenvolvido. Quando o ciclo é muito frequente redunda num esforço
desnecessário de gestão. Quando muito espaçado, não permite que as ações
de ajuste sejam tempestivamente implementadas. A definição da frequência
depende da experiência e sensibilidade do gerente de projetos (VARGAS, 2003).
Durante a confecção do plano de gerenciamento do projeto, foram definidos

os processos de controle de mudanças. Porém, é comum que o gerente queira
agradar o cliente e deixe passar alguma mudança sem a devida avaliação e
autorização. Neste caso, mesmo que essa mudança não cause nenhum impacto
importante ao projeto, será aberta uma brecha para que o cliente busque cada
vez mais pela implantação de alterações e sem o processo de gerenciamento de
mudanças.
Normalmente, o principal interesse do cliente não é o controle do projeto,

e sim os benefícios do produto final. Assim, ele pressionará para obter o máximo
possível do projeto, independente da avaliação do impacto da mudança. Apesar
de ser natural, trata-se de um jogo de “me engana que eu gosto”, já que mesmo
sem avaliação, o impacto da mudança ocorrerá. As ações corretivas, preventivas e
os reparos de defeito que alterem contratações vigentes e componentes do plano
do projeto, tais como as linhas de base, o escopo do projeto, o escopo do produto
e procedimentos exigem, necessariamente, uma solicitação de mudança formal
e somente devem ser implantadas, após analisadas, com eventual aprovação pelo
processo de realizar o controle integrado de mudanças (VARGAS, 2003)
3.5 AS MUDANÇAS E O ENCERRAMENTO DO PROJETO
Mudanças no projeto são algo sempre presente no dia-a-dia dos projetos,

porém existem regras que estabelecem como elas devem ser feitas e inclusive
quais os níveis de autoridade para tanto, o que deve ser sempre seguido pelo
Gerente de Projetos desde o início até o momento do encerramento do projeto.
3.5.1 Controle Integrado de Mudanças
O Controle Integrado de Mudanças é o trabalho definido no plano do projeto

para avaliação de mudanças propostas e que possui atividades que seguem a
seguinte sequência:
• Recebimento do pedido de mudança pela equipe do projeto;
26
Volte ao Sumário
• Análise e entendimento da mudança;

• Análise dos impactos da mudança nos objetivos do projeto;
• Criação de eventuais opções;
• Documentação do impacto das mudanças solicitadas;
• Aprovação ou rejeição da mudança;
• Comunicação do resultado às partes interessadas;
• Gerenciamento das expectativas das partes interessadas;
• Controle de atualização do escopo, custo, orçamento, cronograma e requisitos da
qualidade a partir das mudanças aprovadas;
• Garantia de que somente as mudanças aprovadas sejam implementadas;
• Gerenciamento das mudanças aprovadas (andamento/conclusão);
• Identificação se a mudança ocorre outras vezes;
• Avaliação da eficácia das ações da mudança (XAVIER, 2008).
3.5.2 O “CCB” (Comitê Integrado de Controle de Mudanças)
O CCB vem do inglês “Change Control Board - CCB”, sendo que assim como
o Conselho de Administração é a instância máxima de decisão de uma empresa,
o CCB é a maior instância de decisão dentro de um projeto. O CCB controla
o Gerente de Projetos que por sua vez controla o projeto. Toda a decisão que se
encontre fora da alçada do Gerente de Projetos precisa ser tomada no CCB.
Uma pergunta quase que imediata diz respeito aos participantes do CCB. Ele
é uma instância formalizada, que sempre conta com a participação do Gerente de
Projetos e possivelmente do Patrocinador, sendo que além deles devem existir
mais 3 membros para direcionarem decisões como: trocar um grande fornecedor
do projeto, ou adiar a execução do projeto, ou até mesmo parar o projeto por
alguma razão (VARGAS, 2003).
O CCB deve ter plena autonomia (ou “empowerment”) para decisões

desta envergadura. Mais do que a tomada de decisão errada, talvez o que mais
conduza um projeto ao fracasso seja a ausência da tomada de decisão e o CCB
tem a obrigação de tomar as decisões mais estratégicas. O CCB precisa se reunir
periodicamente para analisar as questões da empresa, porém qual deve ser esta
periodicidade...?
Normalmente se calcula isto da seguinte forma: inicialmente se divide por dez

a duração do projeto, sendo que se esta fração for inferior a um dia a periodicidade
deve ser diária, mas se esta fração for maior que um mês, a periodicidade deve ser
mensal. Caso a duração seja por exemplo de 100 dias (100/10=10 dias) ela deve
ocorrer semana sim, semana não (VARGAS, 2003). Deve ser objetiva (status,
discussão, decisão, aprovação).
27
Volte ao Sumário
3.5.3 Lições Aprendidas
As “Lições Aprendidas” são uma garantia que o aprendizado proporcionado

por um projeto não ficará apenas com os profissionais que dele participaram, pois
é feito um registro permanente num acervo disponibilizado aos profissionais do
setor como forma de aprimoramento contínuo. A importância de se documentar
as lições aprendidas no projeto:
1. Evitar os erros do passado – com a documentação adequada, o gestor pode identi-
ficar as causas dos insucessos aumentando as chances dos próximos projetos serem
entregues no prazo, dentro do orçamento e conforme com os requisitos especifica-
dos (XAVIER, 2008).
2. Prevenir riscos em outras situações – Os projetos muitas vezes são únicos, assim
muitos gestores acreditam que não devem documentar as lições aprendidas, pois
não irão poder aplicá-las de novo. Contudo isto não é inteiramente verdade, pois
muitos projetos possuem elementos em comum e dessa forma estas lições apren-
didas e documentadas podem ter grande valia, inclusive para prevenir ou mitigar
riscos de um novo projeto (SOTILLE, MENEZES, XAVIER, PEREIRA, 2006).
3. Gestão do conhecimento (e o consenso sobre práticas gerais) – A maioria dos
projetos envolve momentos difíceis e de discordância entre os seus participantes.
Após a conclusão do projeto pode-se analisar determinadas decisões e produzir
consensos sobre elas com vistas a futuras situações semelhantes.
4. Aumento da competência do gestor – Estudo dos projetos concluídos aumenta a
capacidade do gestor para os projetos futuros, a chamada gestão do conhecimento.
5. Repensar a estratégia – as vantagens das lições tendem a superar a sua execução,
pois fomentam a reavaliação das estratégias do portfólio de projetos (VARGAS,
2003).
3.5.4 Encerramento do projeto (ou de uma fase)
Representa a finalização formal das atividades de todos os grupos de

processos de gerenciamento de projetos (XAVIER, 2008). Nele estão abrangidas
as seguintes atividade:
• Confirmar que todo trabalho planejado foi realizado;
• Garantir que o projeto atendeu aos critérios de aceitação;
• Terminar aos relatórios de acompanhamento;
• Coordenar a transição do produto do projeto para o cliente;
• Coletar os dados técnicos do projeto;
• Consolidar o registro das lições aprendidas;
• Arquivar a documentação técnica do projeto;
• Arquivar a documentação administrativa do projeto;
• Arquivar a documentação financeira do projeto;
• Obter o aceite do cliente do produto final (VARGAS, 2003).
Se houver o cancelamento do projeto a documentação deverá indicar a

razão disto ter ocorrido e haverá a formalização das entregas finalizadas ou em
andamento ao cliente.
28
Volte ao Sumário
4. CONTROLE E VALIDAÇÃO DO ESCOPO
A importância do controle do andamento do escopo e visto como conferir

se o que foi criado está de acordo com o planejado. Também será apresentada
a relação entre os processos de controlar o escopo, bem como as mudanças no
escopo do projeto.
4.1 CONTROLE DO ESCOPO DO PROJETO
O controle do escopo do projeto trata de influenciar os fatores que criam

mudanças no escopo do projeto e de controlar o impacto dessas mudanças. O
controle do escopo garante que todas as mudanças solicitadas e ações corretivas
recomendadas sejam processadas por meio do processo de controle integrado
de mudanças do projeto. O controle do escopo do projeto também é usado para
gerenciar as mudanças no momento em que efetivamente ocorrem e é integrado
a outros processos de controle. A mudança é inevitável e, portanto, exige algum
tipo de processo de controle de mudança (PMBOK, 2013).
O processo de controlar o escopo consiste em:

• •Medir o progresso de trabalho de elaboração do escopo do projeto e de seu pro-
duto.
• •Gerenciar as solicitações de mudança, de modo a garantir que somente as mudan-
ças aprovadas sejam implementadas.
• •É um trabalho que exige proatividade do gerente do projeto. Ele deve agir para
evitar problemas futuros e se antecipar em eliminar as causas capazes de alterar o
projeto (XAVIER, 2008).
Para controlar o escopo, toma-se como referência as informações contidas

na:
• Linha de base do escopo do projeto, para conhecer a magnitude das variações.
• Documentação dos requisitos, para conhecer as necessidades e expectativas regis-
tradas das partes interessadas.
• Matriz de rastreabilidade dos requisitos, para saber as origens desses requisitos
(VARGAS, 2003).
O controle do escopo faz a coleta informações a respeito do progresso do

projeto, tais como:
• Entregas iniciadas.
• Entregas concluídas.
• Progresso das entregas em andamento.
• Causas que provocaram as variações.
29
Volte ao Sumário
4.2 CONTROLE DE MUDANÇAS NO ESCOPO
As mudanças no escopo são frequentes em projetos e exigem gerenciamento.

Quando ocorre o descontrole, leva o projeto ao fracasso. As origens das mudanças
são:
• Falta de detalhamento do escopo nas fases de planejamento.
• Interferências de partes interessadas.
• Mudanças no negócio.
• Requisitos da fronteira de domínio da aplicação.
• Requisitos “implícitos” sem documentação.
• Entusiasmo da equipe em exceder as expectativas (SOTILLE, MENEZES, XAVIER,
PEREIRA, 2006).
Nos projetos gerenciados inadequadamente, são observados:

• Absorção das mudanças pela equipe sem registro e revisão da documentação do
projeto.
• Requisições informais não notificadas ao gerente.
O trabalho de controle de mudanças contempla:

• Determinar as causas das variações ocorridas.
• Verificar o que pode ser feito para eliminar as causas que provocaram as variações.
• Assegurar que as mudanças, ações corretivas e ações preventivas estão obedecen-
do aos procedimentos estabelecidos no Plano de gerenciamento de configurações,
notadamente quanto à realização da análise dos impactos nos diversos componen-
tes do projeto e quanto aos itens que requerem controle formal de mudanças (XA-
VIER, 2008).
O trabalho do controle das mudanças do escopo segue as etapas:

• Medição dos resultados reais de desempenho.
• Comparação dos resultados reais das medições com o planejado.
• Análise das variações.
• Avaliação da necessidade de mudança, ação corretiva ou ação preventiva.
• Identificação e ação sobre as causas.
• Verificação da necessidade de alterações na Linha de base do escopo.
• Emissão de solicitação de mudanças pela equipe de gerenciamento do projeto,
caso necessário (VARGAS, 2003).
É comum que partes interessadas tentem acrescentar melhorias no escopo

do projeto, seja lógico ou não.
O gerente de projeto é responsável por gerenciar o projeto de acordo com o

seu Plano. Ele não pode deixar que o escopo seja:
30
Volte ao Sumário
• Alterado desnecessariamente.
• Aumentado ou mudado sem que o processo formal de mudança tenha sido seguido
(XAVIER, 2008).
Há diversas ações em que o gerente de projetos pode adotar para reduzir os

problemas de mudança do escopo, entre elas:
• Promover o engajamento das partes interessadas como membros assistentes da
equipe de projeto.
• Agendar reuniões periódicas.
• Formalizar o processo de aprovação dos requisitos do projeto.
4.3 VALIDAÇÃO DO ESCOPO
O processo de validar o escopo do projeto visa formalizar a aceitação das

entregas concluídas pelo cliente. Esse trabalho pode ocorrer no final de uma fase
do projeto ou durante qualquer momento na fase de execução.
O trabalho de validar o escopo envolve:

• Reuniões frequentes e programadas de revisões com o cliente para garantir que as
entregas foram concluídas satisfatoriamente.
• Obtenção do aceite formal do cliente das entregas concluídas.
O trabalho de validação do escopo envolve as atividades de inspeção, exame

e verificação para confirmar que as entregas concluídas atendem os critérios
de aceitação estabelecidos no Plano do projeto (SOTILLE, MENEZES, XAVIER,
PEREIRA, 2006).
Os resultados do trabalho de validação são:

• Entregas concluídas aceitas, de acordo com os critérios de aceitação previamente
definidos, formalmente registradas e assinadas.
• Entregas não aceitas pelo cliente, documentadas com as razões da rejeição. São
motivos de solicitações de mudança de reparo de defeitos.
Há grande diferença entre a validação do escopo e o controle de qualidade.

Enquanto a validação trata do aceite das entregas concluídas pelo cliente, o
controle de qualidade trata da precisão das entregas, atendimento às tolerâncias
e dos requisitos de qualidade do Plano do projeto (VARGAS, 2003).
O processo de controle de qualidade deve ser feito usualmente antes da

validação das entregas, mas por vezes, ocorre simultaneamente.
31
Volte ao Sumário
4.4 ESTIMATIVA DA DURAÇÃO E OS RECURSOS DAS ATIVIDADES

DO PROJETO
Conforme o PMBOK (2013), apesar de precisarem ser feitas, as durações das

atividades são difíceis de serem estimadas devido aos vários fatores que podem
influenciá-las, como níveis ou produtividade de recursos, por exemplo.
Apesar disso, deve-se sempre considerar a opinião especializada, como

informações fornecidas pelos colaboradores do projeto sobre estimativa de
duração das atividades ou sobre durações máximas recomendadas das atividades
a partir de projetos anteriormente executados. Se essa especialização não estiver
disponível, as estimativas de duração serão mais arriscadas e incertas. Barcaui et
al (2006) complementa que existem algumas outras técnicas a serem utilizadas
para obtenção de boas estimativas, dentre as quais:
• Utilizar os dados históricos e documentar seu registro;
• Opinião de especialista e inferir pela similaridade a outras atividades;
• Aplicar a técnica Delphi e estimativas paramétricas;
• Considerar o uso de reservas (“gorduras”)
Estimar durações de atividades é um desafio. O gerente e sua equipe podem

estar familiarizados com as atividades, o que traz maior segurança nas estimativas.
Fonte: “Relação entre número de recursos e sua duração” (O autor, 2020)
Conforme ilustra o gráfico é possível verificar que cada atividade possui uma
relação particular entre a duração e número de recursos, que é determinada pela
produtividade. “O aumento da quantidade de recursos influencia a duração de
forma a diminuí-la, porém não necessariamente de forma proporcional. Ou seja,
ao dobrarmos a quantidade de recursos em uma atividade, não necessariamente
sua duração cairá pela metade. Existem outros fatores que influenciam essa
relação, como a produtividade” (BARCAUI et al, 2006 p.55).
32
Volte ao Sumário
5.PLANO DE GERENCIAMENTO DE RISCOS

(IDENTIFICAÇÃO, ANÁLISE E CONTROLE)
Os riscos são inerentes a todo projeto, porém precisam ter uma atenção
específica, afinal eles têm o potencial de drenar a saúde e a própria viabilidade
dos projetos (VARGAS, 2003). Neste sentido é fundamental que eles sejam
devidamente identificados e posteriormente analisados e controlados (SOTILLE,
MENEZES, XAVIER, PEREIRA, 2006).
5.1 ETAPAS DO PLANO DE GERENCIAMENTO DE RISCOS
As etapas do Plano de Gerenciamento de Riscos são:

• a.Planejamento do gerenciamento de riscos;
• b.Identificação dos riscos;
• c.Realização da análise qualitativa dos riscos;
• d.Realização da análise quantitativa dos riscos;
• e.Planejamento de resposta aos riscos (XAVIER, 2008).
Na etapa do planejamento do gerenciamento de riscos é definido um

calendário de reuniões com toda a equipe do projeto para a elaboração do plano
de gerenciamento de riscos.
Numa primeira reunião são discutidas quais ferramentas seriam utilizadas

para a identificação e análise dos riscos, além de definir os membros da equipe
que seriam responsáveis por apresentar aos demais membros nas reuniões
agendadas os primeiros passos de cada etapa do planejamento. A seleção das
atribuições de cada membro da equipe geralmente é baseada no conhecimento
e habilidade dos mesmos.
Numa etapa seguinte é definido o uso de análise documental para avaliar o

histórico de identificação de riscos e planos de respostas em projetos semelhantes
executados anteriormente na empresa (VARGAS, 2003).
Na reunião para identificação dos riscos geralmente já são trazidos alguns

possíveis riscos já identificados na pesquisa documental, os quais são debatidos
quanto a sua pertinência e decisões são tomadas a partir daí (seja para mitigá-los
ou relegá-los a um segundo plano).
Além desta ferramenta, fez-se uso também de brainstorming para

33
Volte ao Sumário
identificação de outros possíveis riscos para o projeto. A fim de obter um maior

número possível de riscos identificados, utilizou-se também como ferramenta
a Estrutura Analítica de Riscos - EAR, para guiar o processo de identificação
dos riscos e da análise geral sobre os mesmos. Nela os riscos são agrupados e
organizados por categorias, as quais, por sua vez, são divididas em níveis (os quais
detalham a fonte dos riscos para o projeto como um todo e para a atividade em si).
Deste modo os riscos ficam melhor mapeados e a resposta irá priorizar aqueles de
maior impacto (XAVIER, 2008).
5.2 ANÁLISE QUALITATIVA DOS RISCOS

Vimos que devemos ter ferramentas para definir o grau dos riscos e priorizá-
los. Uma destas ferramentas é a análise qualitativa, na qual a equipe de projeto
deve atribuir uma classificação à probabilidade e impacto ao risco, como por
exemplo: baixa, se o risco nunca ocorreu na organização; média, se o risco já
ocorreu uma ou duas vezes; e alta se ocorreu mais de três vezes. Conforme já
descrito anteriormente esta análise é realizada de maneira subjetiva, com base
em especialistas, entrevistas, técnica de Delphi, etc
5.3 ANÁLISE QUANTITATIVA DOS RISCOS

Os riscos devem ser avaliados sob o aspecto da probabilidade de ocorrência
e gravidade das consequências (VARGAS, 2003). Para isso, utiliza-se o conceito
do Valor Monetário Esperado (Earned Monetary Value - EMV). O EMV é dado
pela multiplicação destes dois aspectos de risco, conforme mostra a figura abaixo.
Aquele risco que obtiver evento de maior impacto, ou seja, EMV = 1, terá maior
prioridade na resposta. Isto é uma forma de se focar nos riscos com maior impacto
potencial para uma atividade, para o projeto e à empresa.
Fonte: Probabilidade de ocorrência de risco/EMV (O autor, 2020)
34
Volte ao Sumário
5.4 ISO 31.000 - GESTÃO DE RISCOS
A norma ABNT ISO 31.000 (2009) aborda justamente o aspecto da Gestão

de Riscos. Segundo ela, todas as atividades de uma organização envolvem risco
e este modelo apresenta os princípios e diretrizes genéricos sobre sua gestão.
Conforme a figura a seguir, as organizações gerenciam o risco, identificando-o,
analisando-o e, em seguida, considerando seu apetite ao risco, avaliam se o risco
deve ser mitigado ou não. Durante este processo, as organizações comunicam e
consultam os envolvidos, além de monitorar e analisar o risco e os controles que o
modificam, dessa forma procura-se assegurar que nenhum tratamento adicional
seja necessário (VARGAS, 2003).
Fonte: Modelo de referência de gestão de risco da ISO (ISO 31.000)
35
Volte ao Sumário
CONSIDERAÇÕES FINAIS
No primeiro tópico desta disciplina pudemos analisar a importância do

Gerenciamento do Escopo na eficácia de um projeto, assim como compreender
as suas etapas, planejamento e coleta de requisitos. Também vimos o processo
de Definição do Escopo e a questão da Declaração do Escopo. Na sequência nos
dedicamos aos conceitos que iniciam na Estrutura Analítica do Projeto e terminam
na Linha base do Escopo, passando pelo aspecto da Integração do Projeto, o
Controle Integrado de Mudanças, o CCB e o encerramento do projeto. Logo
em seguida vimos as questões do Controle e da Validação do Escopo, além do
Plano de Gerenciamento de Riscos. Tudo isto nos permite fazermos uma reflexão
acerca da relevância destes temas especialmente no contexto prático da Gestão
de Projetos.
36
Volte ao Sumário
REFERÊNCIAS BIBLIOGRÁFICAS
BARCAUI, A. et al. Gerenciamento de tempo em projetos. 2.ed.Rio de

Janeiro: FGV, 2006.
PROJECT MANAGEMENT INSTITUTE – PMI. Guia PMBOK: Um guia de

conjunto de conhecimentos do gerenciamento de projetos. Pennsylvania: Project
Management Institute. 2013.
SOTILLE, M.; MENEZES, L.; XAVIER, L.; PEREIRA, M. Gerenciamento de

escopo em projetos. 3. ed. Rio de Janeiro: FGV, 2006.
VARGAS, R. Gerenciamento de projetos: estabelecendo diferenciais

competitivos. Rio de Janeiro: Brasport, 2003.
XAVIER, C. Gerenciamento de projetos: como definir e controlar o escopo

do projeto. São Paulo: Saraiva, 2008.
37
Volte ao Sumário
Desenho Instrucional: Veronica Ribeiro

Design editorial/gráfico: Darlan Conrado
Revisão pedagógica: Melyssa Romão
Revisão ortográfica: Adriana Morais
2020
38

e Book Gerenciamento de Escopo, Tempo e Risco

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

e Book Gerenciamento de Escopo, Tempo e Risco

Enviado por

Direitos autorais:

Formatos disponíveis

Volte ao Sumário

Navegue entre os capítulos

Lohmann, Guilherme Garcez, 2020

Palavras Chave: 1. Gerenciamento do Escopo, Tempo e Risco, 2. Gerenciamen-

A disciplina de “Gerenciamento do Escopo, Tempo e Risco de Projetos”

Neste contexto, a coordenação de um projeto é exercida pelo Gerente de

minimizar falhas e desvios do planejamento, ao mesmo tempo em que busca

A palavra escopo compreende todas as atividades que fazem parte de um

1.1 ETAPAS DO GERENCIAMENTO DO ESCOPO

O gerenciamento do escopo assegura que o projeto inclui todo o trabalho

A área de conhecimento de Gerenciamento do Escopo do Projeto apresenta

1.2 PLANEJAR O GERENCIAMENTO DO ESCOPO

monitorado e controlado pela equipe do projeto e validado pela equipe do cliente.

• Processos para preparação e detalhamento do escopo do projeto.

O Plano de gerenciamento do escopo pode ser formal ou informal, detalhado

Assim, são criados dois documentos para coleta e acompanhamento dos

1.3 COLETA DE REQUISITOS

Coletar os requisitos visa definir e documentar as funções e funcionalidades do

quantificadas e documentadas do cliente e demais partes interessadas do projeto

Os requisitos formam a base das informações para a criação da EAP –

Os requisitos do projeto envolvem os levantamentos de necessidades

De acordo com Vargas (2003) os requisitos não funcionais são:

Para a coleta dos requisitos e do produto do projeto são utilizadas diversas

requisitos (as quais posteriormente também são utilizadas no aspecto da Análise

- Entrevistas - entrevistas individuais feitas com cada parte interessada.

- Grupos focais - o objetivo do grupo focal é reunir as diversas partes

- Workshops facilitados - são sessões que trazem profissionais de

•Os grupos de partes interessadas mais importantes, de preferência todos,

- Técnicas criativas de grupo - são atividades em grupo que podem ser

Brainstorming: Todos os participantes apresentam qualquer coisa sobre o

Mapa mental – trata-se de um diagrama de ideias para gerar, classificar e

Diagrama de afinidade – as ideias geradas por qualquer outra técnica são

Técnicas de tomada de decisão - visam facilitar a tomada de decisão em

Questionários e pesquisas - auxiliam na tomada de decisões específicas,

Protótipos - uma forma de obter o feedback dos interessados criando algo

Observações - as pessoas geralmente acham difícil descrever o que fazer. Às

pode o observador executar o trabalho junto com a pessoa observada, para

Técnica Delphi - Inicialmente podemos dizer que ela é uma técnica de

Na técnica Delphi os relatos de situações como esta são protegidos pelo

1.4 PROCESSO DE DEFINIÇÃO DO ESCOPO

do projeto. Trata-se de um trabalho elaborado progressivamente, à medida que

1.4.1 Declaração do escopo

A Declaração do escopo do projeto descreve em detalhes as entregas do

Não se deve avançar no desenvolvimento do planejamento do projeto

Também há necessidade de verificar se há alternativas para executar o

1.4.2 Elementos da Declaração do Escopo

entrega. Exemplo: medir o tempo de resposta ao atendimento no horário entre

Conforme Vargas (2003) as restrições podem ser:

2. ESTRUTURA ANALÍTICA DO PROJETO (EAP)

EAP significa Estrutura Analítica do Projeto (na língua inglesa é conhecida

2.1 CRIAR A EAP

O processo de Criar a EAP consiste em decompor as entregas e o trabalho

•Uma imagem gráfica da hierarquia do escopo do projeto.

A EAP tem como objetivo o gerenciamento do projeto. Segundo Vargas

•Mostrar graficamente o escopo do projeto.

•Permitir estimativas mais precisas.

Os benefícios da criação da EAP são:

2.2 DECOMPOSIÇÃO DA EAP

A decomposição da EAP é um processo hierárquico de cima para baixo.

A decomposição da EAP é orientada para as entregas, que são elementos

As entregas são resultados dos esforços da equipe de projeto e não devem

Até onde decompor é uma questão em aberto para cada projeto. Um

Os níveis e os elementos da EAP são numerados para permitir sua pronta