Gerenciamento de Escopo em Projetos FGV

FGV – FUNDAÇÃO GETÚLIO VARGAS

MBA EM GERENCIAMENTO DE
PROJETOS

GERENCIAMENTO DE ESCOPO EM
PROJETOS

Prof. Gutenberg de A. Silveira Ph.D. PMP

gutenberg.silveira@terra.com.br

Versão 4.2 – Abril / 09

MBA em Gerenciamento de Projetos 1 Gerenciamento de Escopo em Projetos

Professor
Prof. Gutenberg de A. Silveira

• Doutor em Administração - FEA-USP
• Mestre em Administração - Mackenzie
• Pós-Graduado em Administração - Mackenzie
• Pós-Graduado em Educação - Mackenzie
• 2 Especializações em Educação - UNICSUL
• Graduado em Análise de Sistemas - FASP
• Certificado pelo PMI® Project Management Institute como PMP® - Project
Management Professional
• Membro do Grupo de Estudos de Maturidade em Gerência de Projetos – PMI SP/RJ
• Certificado pelo ITIL® Information Technology Infrastructure Library
• 21 anos com Docente tendo atuado como Professor, Chefe de Departamento,
Coordenador de Cursos na Graduação e Pós-Graduação
• Professor dos cursos de Pós-graduação: FIAP, USP (FEA, FIA, IPT), FATEC e FGV
• Diretor Acadêmico do Centro de Pós-Graduação da FIAP
• Autor de artigos nacionais e internacionais e Conferencista em Gerência de Projetos
• 3 Pareceres do MEC, autor de vários cursos de Graduação e Pós-Graduação
• 25 anos em Tecnologia da Informação (Hewlett-Packard, CA, Lucent Technologies,
CPM Braxis, Editora Abril, IOB, Banco Noroeste, Borlem)


Citação

“você pode sonhar,
criar e construir a idéia
mais maravilhosa do mundo,
mas são necessárias pessoas
para fazer o sonho virar realidade”

Walt Disney


Plano de Curso

Agenda
Aula 1
O Gerenciamento de Projetos
Gerenciamento do Escopo
Planejamento de Escopo
Aula 2
Definição de Escopo
Aula 3
Criar EAP
Verificação do Escopo
Aula 4
Controle do Escopo


Plano de Curso

Aulas Expositivas
Dinâmicas de Grupo
Apresentação de Ferramenta
Exercícios – Padrão Certificação PMP


O Gerenciamento de Projetos


O Que é um Projeto?
Segundo o PMBOK®, PMI (2004, p. 4), projeto pode ser definido como “um
empreendimento temporário com o objetivo de criar um produto, serviço ou
resultado único”. “Temporário” significa que cada projeto tem um começo e
um fim bem definidos.

No PRINCE2™, projeto é um empreendimento temporário, necessário para
produzir um resultado predefinido ou um resultado num tempo pré-
especificado, usando-se recursos determinados no início.

O Office of Government Commerce, OGC (2005), define projetos como um
conjunto único de atividades coordenadas com duração finita, com
parâmetros de custos e desempenho definidos e claras saídas para sustentar
objetivos específicos de negócios.

um projeto é um empreendimento temporário com
o objetivo de criar um produto ou serviço único


O Que é um Projeto?

um projeto é um empreendimento temporário com
o objetivo de criar um produto ou serviço único


PMI

gerenciar bem projetos é um fator essencial para a
sobrevivência das organizações em nossa sociedade.

não basta apenas gerenciar projetos, isto deve ser feito com
muita competência, e conduzido por profissionais qualificados.

as melhores práticas de gestão de projetos são estabelecidas
pelo PMI.


Gerenciamento de Projetos
Gerenciamento de Projetos é a aplicação de conhecimentos e técnicas para
projetar atividades que visem atingir ou exceder às necessidades e
expectativas das partes envolvidas, por meio do equilíbrio dos vetores: tempo,
custo e qualidade.
A Association for Project Management’s Body of Knowledge (APMBOK®)
define o gerenciamento de projetos como uma disciplina de administração de
projetos de sucesso, a qual implica o alcance dos objetivos dentro do prazo,
custo, aspectos técnicos, qualidade e critérios de desempenho pré-definidos.

Risco Risco

Expectativas Objetivos


Universo de Conhecimentos de Gerência de Projetos

A maior parte do conhecimento necessário para gerenciar
projetos é quase específico da disciplina gerência de
projetos.


Dimensões (Constraints*)

• Mantenha em mente que a satisfação do cliente é o primeiro critério de medição
para o sucesso em projetos (Frame, 1994)
• (*) Segundo o PMI®, significa uma restrição ou limitação que pode afetar o
desempenho do projeto.


Áreas do Conhecimento

Processos requeridos para
CUSTO RECURSOS assegurar que os vários
HUMANOS ESCOPO
elementos do projeto sejam
Processos necessários adequadamente coordenados.
Processos requeridos para

COMUNICAÇÃO
para garantir que o projeto Processos requeridos de maneira mais eficaz
utilizar

CONTRATOS
Processos necessários Processoscom a
irá satisfazer as requeridos para
Processos relacionados para assegurar a o pessoal envolvido nonecessários para
Processos
para assegurar que os análise eas informações
assegurar que
necessidades para qual
identificação, projeto.
conclusão do projeto assegurar que o projeto
custos respostas aos riscos do sejam
do projeto
foi proposto. do projeto INTEGRAÇÃO
nos prazos previstos inclue todo o trabalho
estejam dentro projeto.
doadequadamente coletadas e
orçamento aprovado. disseminadas. necessário, e apenas o
trabalho necessário, para
completar o projeto com
sucesso.
QUALIDADE
ProcessosRISCO
requeridos para TEMPO
aquisição de bens e
contratação de serviços.


Áreas do Conhecimento

CUSTO RECURSOS
HUMANOS ESCOPO

COMUNICAÇÃO
CONTRATOS
INTEGRAÇÃO

QUALIDADE RISCO TEMPO


Constraints vs. Áreas do Conhecimento

Escopo
Custo Integração Tempo
Recursos Humanos
Comunicação
Risco
Contratos

Qualidade


Processos Integrados
monitora regularmente o progresso para identificar variações em relação ao plano, para que
possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto.

formaliza a aceitação
define e refina os objetivos e do produto, serviço ou
planeja a ação necessária para resultado e conduz o
alcançar os objetivos e o projeto ou uma fase
escopo para os quais o à um final ordenado.
projeto foi realizado.

define e autoriza o projeto integra pessoas e
ou uma fase do projeto. outros recursos para
realizar o plano de
gerenciamento do projeto

Fonte: PMI- PMBOK (2004) Há sobreposição de atividades nos Grupos de Processos


Processos Integrados

Fonte: PMI - PMBOK (2004)


Por quê os projetos falham?

De acordo com a “Darwin Online”, os projetos falham devido a seis
razões:

Falta de apoio executivo
Expectativa prévia do stakeholder
Definição pobre do escopo e de mudanças de escopo
Expectativas irreais
Falta de cooperação de parceiros de negócios
Comunicação pobre ou desonesta


“Quem falha em planejar, planeja para falhar”


Nível Típico de Custos e Pessoal no Ciclo de Vida



Artigos: PM Network
Um estudo do Standish Group 52,1% das organizações medem o
International mostrou que: resultado do gerenciamento dos
31% dos projetos são cancelados projetos
antes do término. 61,4% dos executivos avaliam o
gerenciamento de projetos como
88% dos projetos ultrapassam o importante
prazo, o custo ou ambos. 14,8% dos gerentes de projetos são
94% dos projetos param e são re- certificados PMP
iniciados. 43,7% das organizações possuem
Escritórios de Gerência de Projetos
Em média, os projetos PMO.
ultrapassam o custo estimado em 41,4% das organizações possuem mais
189% de 50 projetos em andamento.
Em média, os projetos 48,3% dos projetos têm duração
superior a 6 meses.
ultrapassam o prazo estimado em
59,2% dos projetos custam US$
222% 100,000 ou mais.
Fonte: PM Network – Abril/2002


Alguns Dados Estatísticos

Projetos com Sucesso - USA
Alguns dados estatísticos
sobre sucessos / fracassos 78000
em projetos nos USA: 80000

60000

40000 28000

20000

0
1994 2000

Projetos com Fracasso - USA

65000
70000 54000
60000
50000
40000
30000
20000
10000
0
1994 2000



Alguns Dados Estatísticos Brasil

Aspectos mais considerados no planejamento de projetos

Prazo 100%

Escopo 98%

Custo 72%

Recursos Humanos 60%

Qualidade 52%

Aquisições/Contratos 51%

Integração 50%

Comunicação 37%

Riscos 36%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Fonte: Estudo de Benchmarking em Gerenciamento de Projetos 2005/2006



Aspectos mais considerados na identificação de riscos

1 62%
2 50%
3 43%
1 - Técnicos 4 34%
2 - Relativos a tempo
3 - Financeiros 5 29%
4 - Contratuais e legais
5 - Relativos a fornecimento de produtos e/ou
6 25%
serviços 7 18%
6 - Relativos ao compromisso organizacional com o
cliente 8 16%
7 - Nao se aplica
8 - Relacionados a experiência e capacidade da 9 16%
equipe
9 - Políticos 10 13%
10 - Relativos a segurança da equipe
11 - Ambientais
11 10%
12 - Geográficos 12 4%
13 - Culturais
13 4%

0% 10% 20% 30% 40% 50% 60% 70%
Fonte: Estudo de Benchmarking em Gerenciamento de Projetos 2005/2006



Problemas que ocorrem com maior freqüência nos projetos

Fonte: Estudo de Benchmarking em Gerenciamento de Projetos 2007


Problemas que ocorrem com maior freqüência nos projetos



Documentos Existentes nas Metodologias de GP



A Abordagem Histórica do Gerenciamento de Projetos


Dinâmica de Grupo – Projeto #1


Gerenciamento do Escopo*

* PMBOK Capítulo 5


O Escopo


Porque o escopo


Escopo do Produto ou Projeto

Escopo Escopo
do ou do
produto projeto

as características ou funções que devem o trabalho que deve ser executado a fim de
ser incluídas no produto ou serviço fornecer um produto com as características e
funções especificadas

REQUISITOS PLANO
Medido de acordo com os Medido de acordo com o plano.
requisitos estabelecidos.


Projetos x Atividades

Projetos Atividades
Temporário Permanente
Original/Exclusivo Repetitivo
Multifuncional Funcional
Resultado é incerto Resultado
Foco na previsível
integração/sinergia Foco no segmento

Características diferenciadoras:
Atividades são contínuas e repetitivas;
Projetos são temporários e únicos;
Projetos envolvem um grau de incerteza.


Gerenciamento do Escopo - Definição

Contempla os processos necessários para assegurar que o
projeto inclui todo o trabalho requerido, e somente o trabalho
requerido, para concluir o projeto com sucesso.
O gerenciamento do escopo está primariamente preocupado
com a definição e controle do que está ou não incluído no
projeto.


Gerenciamento do Escopo - PMBOK framework
Processos de Planejamento
Planejamento do Escopo (5.1) – defina e gerencia a influência do
sucesso total do projeto.
Definição do Escopo (5.2) – prepara o escopo do projeto detalhado que
é crítico para o sucesso e, define e constrói os maiores entregáveis,
premissas e restrições.
Criar o WBS (5.3) – decomposição hierárquica do trabalho orientado a
entregável para ser executado pela equipe do projeto para atingir seus
objetivos.
Verificação do Escopo (5.4) – processo para obter a aceitação formal
dos stakeholders quanto ao escopo aprovado.

Processos de Monitoramento e Controle
Controle do Escopo (5.5) – avalia os fatores que influenciam mudanças
no escopo do projeto, bem como o seu controle.


Gerenciamento do Escopo - PMBOK framework


Gestão do Escopo (*)
Processo 5.1 – Planejamento do Escopo

* PMBOK Capítulo 5


Planejamento do Escopo

1. Fatores ambientais da empresa 1. Plano de gerenciamento do
2. Ativos de processos escopo do projeto
organizacionais
3. Termo de abertura do projeto 1. Opinião especializada
4. Declaração do escopo preliminar 2. Modelos, formulários, normas
do projeto
5. Plano de gerenciamento do
escopo do projeto

Objetivo: Descrever como a equipe irá definir o escopo do projeto,
desenvolver uma declaração detalhada do escopo, documentando a sua
melhor abordagem; definir e construir a estrutura analítica do projeto, bem
como criar instrumentos para verificar e controlar o escopo.


Planejamento do Escopo – Entradas

Fatores ambientais
Fatores e sistemas diversos que influenciam o sucesso do projeto,
exemplos: cultura organizacional, políticas, governo, infraestrutura,
recursos, mercado, acionistas, sistemas de informação (em especial para
Gerência de Projetos) etc.



Ativos de processos organizacionais

Avaliação dos Processos Organizacionais representa o conhecimento e o
aprendizado organizacional a partir de outros projetos. A base de
conhecimento (lições aprendidas) contém informações de grande valia
sobre a definição de atividades em projetos similares.



Termo de abertura do projeto (Project Charter)

É publicado pelo patrocinador do projeto com autoridade formal na
estrutura organizacional;
Reconhece e autoriza formalmente a existência do projeto, dando ao
seu gerente, a autoridade e responsabilidade temporária para sua
execução
Cabe ao patrocinador definir o rumo do projeto
Deve conter:
As justificativas de negócio
Os objetivos, metas e benefícios do projeto com critérios
quantificáveis para a organização
Descrição do produto
As premissas, restrições, fronteiras e interfaces
As principais partes interessadas no projeto, destacando as
devidas responsabilidades e compromissos
Definir os principais marcos-chave do projeto
Descrição das estratégias de condução do projeto (se necessário)



Termo de abertura
do projeto (modelo)

Fonte: Sotille et al.(2007)


Premissas
Cada projeto é concebido e desenvolvido baseado num conjunto de hipóteses
ou premissas. pág. 248
Premissas são fatores que, para propósitos de planejamento, são
considerados por serem verdadeiros, reais ou certos sem prova ou
demonstração. Premissas afetam todos os aspectos do planejamento do
projeto, e são parte da elaboração progressiva do projeto. A equipe de
projetos frequentemente identificam, documentam e validam as premissas
como parte do seu processo de planejamento. Premissas geralmente
envolvem um grau de risco. pág. 352.

Tipos PMBOK (2004)
Disponibilidade de recursos (pessoas)
Disponibilidade de equipamentos
O que deve estar pronto para o inicio do projeto
Local e horário de trabalho
Informações técnicas

Pergunta-Chave
O que é necessário para o meu planejamento ser um sucesso durante a
execução do projeto?

Restrições
O estado, qualidade ou senso de ser restrito para um dado curso e ação ou
sua falta. Uma restrição aplicável ou limitação, interna ou externa ao projeto,
que afetaria o desempenho do projeto ou um processo. pág. 355
Restrições são fatores específicos que podem limitar as opções de
estimativas de custos. Outras restrições podem envolver datas de entregas
requeridas, disponibilidade de recursos especializados e políticas
organizacionais. pág. 183
Restrições são fatores que podem limitar as opções da equipe de
gerenciamento de projetos. pág. 226
PMBOK (2004)
Tipos
Orçamento
Tempo
Escopo
Tecnologias
Recursos

Pergunta-Chave
Quais são os fatores como: Escopo, Custo, Prazo ou outros que limitam o
desenvolvimento do planejamento do projeto?

Objetivo - Exemplo

Exemplo 1:
1.Construção de depósitos para mantimentos (não ideal);

2. Construção de 5 depósitos para mantimentos, em 8 meses, com
previsão de investimento no valor de R$ 60.000,00.

Exemplo 2:

1.Aumento da capacidade de processamento dos servidores de
dados e storage (não ideal);

2.Aumento da capacidade de processamento dos 4 servidores de
dados de 1.2 GHz para 3 GHz e do storage de 1Tb para 2 Tb
até o próximo período de elaboração da folha de pagamento
(set/2009), com inverstimento estimado de R$ 200.000,00.



Declaração do escopo preliminar do projeto

Declaração do Escopo do Projeto implica nos entregavéis, premissas e
restrições documentadas no escopo. Restrições são fatores que limitam as
opções da equipe do projeto. Premissas são fatores que devem ser
consideradas como verdadeiras no desenvolvimento do planejamento.


Planejamento do Escopo – Ferramentas & Técnicas

Opinião especializada
Frequentemente é necessário a avaliação das estimativas de
recursos por profissional ou grupo especializado em
planejamento, a fim de atestar os números.

Modelos, formulários e normas

Utilização de todos tipos de formulários, templates e normas que
possam subsidiar o gerente de projetos no planejamento do
escopo.
O Gerente de projetos pode utilizar a base de conhecimentos da
organização em ordem para elaborar o novo planejamento do
projeto.


Planejamento do Escopo – Saída

Plano de gerenciamento do escopo do projeto

documento que proporciona guia para o planejamento e desenvolvimento
do projeto, mas especificamente nesta fase quanto a Gestão do Escopo.
Alcance deste documento:
– Estabelece os procedimentos necessários para condução do projeto
– Confirmação das expectativas e escopo do projeto
– Definição do plano de comunicação do projeto
– Detalhamento e atualização do Cronograma do projeto
– Plano de análise de riscos do projeto
– Plano para gerenciamento da equipe de trabalho e resolução de
conflitos
– Plano de controle de custos do projeto


Planejamento do Escopo – Saída

PROJECT
CHARTER

RESTRIÇÕES
Planejamento
Iniciação do Escopo
E PREMISSAS

DESCRIÇÃO
DO PRODUTO

PLANEJAMENTO
GERENTE DE PROJETO
IDENTIFICADO


Processo 5.2 – Definição do Escopo

* PMBOK Capítulo 5


Definição do Escopo

1. Ativos de processos 1. Declaração do escopo do projeto
organizacionais 2. Mudanças solicitadas
2. Termo de abertura do projeto 1. Análise de produtos 3. Plano de gerenciamento do
3. Declaração do escopo preliminar 2. Identificação de alternativas escopo do projeto (atualizações)
do projeto 3. Opinião especializada
4. Plano de gerenciamento do 4. Análise das partes interessadas
escopo do projeto
5. Solicitações de mudanças
aprovadas

Objetivo: Descrever em detalhes os maiores entregáveis, premissas e
restrições que são documentadas durante a iniciação do projeto. Este
processo procura registrar as necessidades, desejos, expectativas dos
stakeholders, por meio da equipe, as quais são analisadas e convertidas
em requerimentos como a equipe irá definir o escopo do projeto.


Definição do Escopo – Entrada

Solicitações de mudanças aprovadas

Pedidos de Mudanças Aprovados - podem ocorrer de muitas formas —
oral ou escrita, direta ou indireta, externa ou internamente iniciada, e legal
ou opcional. Mudanças podem requerer a ampliação do cronograma ou
podem permitir acelerá-lo.


Definição do Escopo – Entrada

Solicitações de mudanças aprovadas – Modelo de processo


Definição do Escopo – Ferramentas & Técnicas

Análise de produtos

Consiste na busca de um melhor entendimento do produto do projeto, inclui
técnicas tais como:
engenharia de sistemas
engenharia de valor
análise de valor
análise de funções
QFD - Quality Function Deployment
(detalhamento da função qualidade)



Identificação de alternativas

Uso de técnicas, por exemplo: brainstorming
Geração acelerada de sugestões
Proporciona o pensamento lateral, rompendo padrões, evitando críticas
e a repressão de idéias
Gera a criatividade por meio da participação



Análise das partes interessadas
Segundo Buysse e Verbeke (2003) – qualquer indivíduo ou
grupo de pessoas que pode afetar o desempenho do projeto
(organização) ou quem é afetado pelo consecução dos objetivos
do projeto.
Gerente de projetos
Cliente
Parceiros ou fornecedores
Equipe de projeto
Patrocinador
Segundo Silveira (2008) o sucesso de um projeto somente é
possível se as especificações de desempenho técnico,
satisfação dos participantes da equipe e dos demais
stakeholders, missão e organização do projeto forem atendidos.



Análise das partes interessadas



Stakeholders de um Projeto

Lucro,
Interesses Aumento de
Patrimônio

Impostos,
Emprego,
Remuneração,
Acionistas Investimentos,
Políticas
Crescimento
s Governo
ado
r eg
E mp
Clientes
Prazo,
Custo e
Relações Fornecedores Qualidade
comerciais, Comunidades
Lucros

Zelo com
Meio
Ambiente


Mapeamento de Stakeholders

Rabechini Jr. e Carvalho (2003)
classificam o patrocinador como
stakeholder primário - indivíduos
com maior visibilidade - cujas
competências podem variar de
acordo com a tradição da
empresa, natureza do projeto e
estilos gerenciais com
participações distintas ao longo
do ciclo de vida. O stakeholder
secundário depende do âmbito e
abrangência do projeto, o qual
pode envolver o governo e
empresas contratadas.


Stakeholders de um Projeto (Influências)

Stakeholders-Nome/área vinculada/cargo/poder (externa ou interna)
Tipo de interesse
no projeto A B C D E E F G
Qualidade A
Econômico

Legal

Político B
Negócio

Técnico
Conhecimento

Sobrevivência M
Grau de interesse: Grau de Influência:
A - Alto Positivo Negativo Neutro
B - Baixo
M - Médio


Definição do Escopo – Saída

Declaração do escopo do projeto

Interpretação errada do SOW = perda de dinheiro
Exemplo 1

O SOW afirma que sua empresa irá
conduzir um mínimo de quinze testes para
determinar as propriedades de uma nova
substância.
Para ter uma margem de segurança, sua
empresa faz um orçamento prevendo a
execução de 20 testes.
Ao final do décimo quinto teste, o cliente
afirma que os resultados não são
conclusivos e que uma nova bateria de
quinze testes deve ser executada.

Resultado: estouro do orçamento



A Declaração do escopo do projeto ou “statement of work” (SOW) é uma
descrição narrativa do trabalho requerido para o projeto.

Expectativas claramente documentadas e aceitas começam com a
elaboração de um SOW. Ele relaciona os objetivos, restrições e critérios de
sucesso do projeto, definindo assim “As regras do jogo”.

O SOW fornece uma base documental para tomada de decisões futuras
do projeto e, para confirmar e desenvolver um entendimento comum do
escopo do projeto entre os stakeholders.

O conteúdo mínimo do SOW:
1) Declaração de Propósito / Objetivos
2) Declaração de Escopo
3) Deliverables
4) Estimativas de Custo e cronograma
5) Stakeholders



Numa negociação comercial é comum encontrarmos dois tipos de
SOW. Aquele usado em proposta e o documento de contrato Contract
Statement of work (CSOW)

A base do contrato (CSOW) é o SOW da proposta acrescido de:
Cláusulas de propriedade intelectual
Termos e condições gerais
Cláusulas de confidencialidade e não divulgação
Responsabilidade das partes, multas e penalidades
Qualificação das partes
Limitações de responsabilidade
Foro




Exemplo 2

A Marinha concede a sua empresa
um contrato onde o SOW afirma que o
protótipo deve ser testado na “água"
Sua empresa executa o teste do
protótipo em uma piscina.
Infelizmente, a definição de “água” da
Marinha é o Oceano Atlântico.
Resultado: a empresa vai ter gastos
extras para transportar os engenheiros
e equipamentos de testes nas “água”
do Oceano Atlântico.



Exemplo 3
Sua empresa ganha um contrato cujo
SOW afirma que as mercadorias devem
ser transportadas pelo país usando
containeres “arejados”
Sua equipe seleciona um container que
é aberto na parte superior, assim o ar
pode circular. Durante o transporte o trem
passa por uma área de chuvas
torrenciais, e as mercadorias são
estragadas. O cliente afirma que queria
containeres “arejados” por baixo.
Resultado: Uma disputa judicial está
decidindo quem deve ser culpado pela má
interpretação da palavra “arejado”.


Diretrizes na preparação de SOW (1)
Várias organizações hoje em dia estão desenvolvendo seu próprio manual a
respeito da elaboração de SOW. Estes trechos foram adaptados do “NASA Sow
Handbook NHB5600.2”:
O gerente de projeto ou sua equipe devem revisar os documentos que autorizam o
projeto e definir seus objetivos, e também revisar contratos e estudos que levaram ao
atual nível de desenvolvimento.
O gerente de projeto deve estabelecer um time de preparação do SOW consistindo de
especialistas nas áreas técnicas envolvidas.
O gerente de projeto deve atribuir tarefas aos membros do time para identificar
especificações a serem seguidas, critérios de projeto e outros requerimentos que devem
ser incluídos no SOW e cuidar para que cada uma deles tenha um responsável
designado para preparação.
O gerente de projeto deve preparar um checklist detalhado mostrando quais itens são
mandatórios e quais itens são opcionais e a maneira com que se aplicam ao corpo ou a
um dos apêndices do SOW
O gerente de projeto deve enfatizar o uso de peças homologadas, projetos de
subsistemas padrões, partes de equipamentos já desenvolvidas e padronizadas, e
tornar essas e outras informações técnicas disponíveis aos engenheiros projetistas para
prevenir o desvio das melhores praticas de projeto.
Estimativas de Custos (Recursos humanos, materiais, software) desenvolvida pelos
especialistas em custos devem ser revisadas por todos os contribuidores do SOW.
Essas revisões irão permitir considerações de custo/benefício na necessidade de
inclusão de requerimentos que não estão diretamente relacionados aos objetivos
técnicos


Diretrizes na preparação de SOW (2)

Os manuais sobre preparação de SOW da NASA também contém diretrizes para
editores e escritores:
Todo SOW que excede duas páginas deve ter um índice:
Descrições claras e precisas são essenciais. O redator do SOW deve levar em conta
que seu trabalho será interpretado por pessoas de formações distintas (tais como
advogados, compradores, engenheiros, auditores, engenheiros de qualidade, finanças)
Sempre deve-se ter em conta o efeito que o trabalho escrito terá no leitor e em sua
interpretação. Assim todo esforço deve ser feito para evitar ambigüidade.
Lembre-se que qualquer disposição que tira o controle do trabalho das mãos do
empreiteiro, mesmo que temporariamente, pode resultar em aliviá-lo de sua
responsabilidade.
Ao especificar requerimentos use voz ativo ao invés de passiva. Afirme que “o
empreiteiro deve conduzir um teste “ ao invés de “um teste deve ser conduzido”.
Limite abreviações ao máximo e aquelas de uso corrente.
Quando decisões imediatas não podem ser tomadas, pode ser possível incluir um
procedimento para tomá-las.
Não faça especificações excessivas. Deixe o fornecedor propor seu melhor método
Não repita requerimentos detalhados. Ao invés , incorpore-os por referência.



Mudanças solicitadas

Escopo - Define o alcance e os trabalhos necessários do Projeto,
relatando os requisitos que devem ser atendidos para se atingir os
resultados tangíveis contratados;

Prazo - Identificação do tempo para execução das atividades
específicas do cronograma que necessitam ser realizadas para produzir
os diversos produtos tangíveis do projeto;

Custo - Administração dos recursos e processos necessários para
assegurar que o projeto será concluído dentro do orçamento aprovado e
contratado.


Processo 5.3 – Criar a EAP

* PMBOK Capítulo 5


Criar EAP

organizacionais (atualizações)
2. Declaração do escopo preliminar 1. Modelos da estrutura analítica do 2. Estrutura analítica do projeto
do projeto projeto 3. Dicionário da EAP
3. Plano de gerenciamento do 2. Decomposição 4. Linha de base do escopo
escopo do projeto 5. Plano de gerenciamento do
4. Solicitações de mudanças escopo do projeto (atualizações)
aprovadas 6. Mudanças solicitadas

Objetivo: Criar uma decomposição hierárquica do trabalho a ser executado
pela equipe para atingir os objetivos do projeto por meio de entregáveis
requeridos e aprovados. A EAP organiza e define o escopo total do projeto
em partes pequenas, gerenciáveis do trabalho, em ordem descendente e
em ondas sucessivas (rolling wave). O trabalho contido no menor nível da
EAP é chamado de work package, o qual pode ser programado, custeado,
monitorado e controlado.


Esrutura Analítica do Projeto (EAP) ou

Work Breakdown Structure (WBS)


O que é uma EAP ?

De acordo com o PMBOK ® Guide, a EAP é:

“uma decomposição hierárquica do trabalho orientada a entregável
para ser executado pela equipe do projeto para atingir os objetivos do
projeto e criar os entregáveis solicitados”. (Project Management
Institute, 2004).

Está definição implica que a EAP possui as seguintes características:
É representativo do trabalho como atividades, e este possuí resultados
tangíveis.
É uma estrutura arranjada na forma hierárquica.
Possui um objetivo ou resultado tangível, que é referenciado como um
deliverable.


EAP - Objetivos

A EAP é usado em projetos para definir o trabalho a ser
realizado em termos de entregáveis e a posterior
decomposição destes entregáveis em componentes.

A EAP possui dois objetivos:

• Assegurar que o projeto inclui todo o trabalho necessário.
• Assegurar que o projeto não inclui trabalho além do necessário (contratado).


EAP - Características

Gerenciável, assim autoridade e
responsabilidade especifica pode ser
atribuída

Independente, as partes podem ser
vistas com um mínimo de conexões e
dependência de outros elementos

Integrável de maneira que o todo
possa ser vislumbrado

Mensurável em termos de
progresso


EAP - Níveis

Nível Descrição

Níveis
1 •Programa total
2 •Projeto
Gerenciais 3 •Deliverable
4 •Sub-Deliverable
Níveis 5 •Work package
técnicos 6 •Atividades


EAP - Níveis

Nível do
Projeto
Nível do
Deliverable

Nível do Work Package


EAP - Níveis

Estrutura Analítica do Projeto A EAP é um método conveniente para:
1.0 ___________________ Dividir o projeto em pequenos pacotes de trabalho,
1.1 _________________ tarefas ou atividades
1.2 _________________
Objetiva assegurar que todas as atividades requeridas do
2.0 ___________________
3.0 ___________________ projeto estão logicamente identificadas e relacionadas
3.1 _________________ É a melhor forma de estruturar itens tangíveis
3.2 _________________
(entregáveis).
3.3 _________________

Duas formas de representações: estrutura de árvore ou
tabular

Uso principal da EAP
Determinar o escopo baseline
1.0 2.0 3.0 Orientação a entregáveis

1.1 1.2 3.1 3.2 3.3


Work Package

Não deve durar mais que 80 horas (regra das 80
horas)
Ter Premissas e Restrições
Ter seu Escopo definido
Ter Critério de Aceite
Ter identificado os Recursos Humanos/Materiais
necessários para sua execução

EM RESUMO: É UM PACOTE GERENCIÁVEL!


Checklist para uma EAP
O SOW é detalhado o suficiente para permitir que um
profissional faça a tabulação do esforço necessário para
atender a cada elemento?

Estão todas as obrigações específicas do contratado
claramente listadas? O cliente consegue julgar se o
contratado atendeu as especificações?

ears
neck
Todas as partes do SOW estão claras quanto e quando deve
feet ser entregue conforme o contrato?

Quando é necessário referenciar outros documentos, essa
referência foi bem detalhada?

As instruções estão claramente diferenciadas de
informações gerais?

Cada deliverable tem seus requerimentos faseados no
tempo? A duração usada especifica dias úteis ou calendário?


Dez mandamentos da EAP

I. Cobiçarás a EAP do próximo
II. Explicitarás todos os subprodutos, inclusive os necessários ao
gerenciamento do projeto
III. Não usarás os nomes em vão
IV. Guardarás a descrição dos pacotes de trabalho no Dicionário da
EAP.
V. Decomporás até o nível de detalhe (pacote de trabalho) que permita o
planejamento e controle do trabalho necessário para a entrega do
subproduto.
VI. Não decomporás em demasia, de forma a que o custo / tempo de
planejamento e controle não traga o benefício correspondente.
VII. Honrarás o pai
VIII. Decomporás de forma que a soma dos subprodutos dos elementos
componentes (filhos) corresponda ao subproduto do elemento pai
(Mandamento dos 100%).
IX. Não decomporás em somente um subproduto.
X. Não repetirás o mesmo elemento como componente de mais de um
subproduto.


EAP – a estrutura central


Valor da EAP

O programa total pode ser descrito e subdividido em elementos gerenciados
Planejamento pode ser realizado
Custos e orçamento podem ser estabelecidos
Objetivos podem ser conectados aos recursos da empresa de forma lógica
Cronogramas e relatórios de medições podem ser estabelecidos
Construção da rede PERT, planejamento e controle podem ser estabelecidos
A designação da responsabilidade de cada elemento pode ser estabelecido


Matriz de Responsabilidade vs. EAP

WBS

Organização
do Projeto

A I
A A A
A I
R,S I,R
A I I,R
I P
S
P I,R P A A

R,S S S R,S

P = Participant
A = Accountable
R = Review required
I = Input required
S = Sign-off required


Ciclo de Planejamento e Controle em Projetos


O problema do escopo, tempo e custos em projetos

1. DEFINE THE WORK
CONTRACT BUDGET BASE
$$ Mgmt Reserve

2. SCHEDULE THE WORK

e
in
el
as
tB
en
m
re
su
ea
M
3. ALLOCATE BUDGETS

ce
100

an
rm
40

rfo
60

Pe
15
25
30
30


Criar EAP – Saída

Dicionário da EAP
Apresenta o conteúdo detalhado dos seguintes componentes:

work packages estimativas de custos
códigos de identificador de data final
contas
Interdependências
declaração do escopo
descrição do produto responsabilidade
organizacional,
critérios de aceitação
lista de milestones
Entregas
premissas e restrições lista de recursos associados
duração informação contratual


Processo 5.4 – Verificação do Escopo

* PMBOK Capítulo 5


Verificação do Escopo

1. Declaração do escopo do projeto 1. Entregáveis aceitos
2. Dicionário da EAP 2. Mudanças solicitadas
3. Plano de gerenciamento do 3. Ações corretivas recomendadas
escopo do projeto
4. Entregáveis 1. Inspeção

Objetivo: Processo de formalização da aceitação formal do escopo total e
os seus entregáveis pelos stakeholders. A verificação do escopo, inclui a
revisão dos entregáveis para assegurar que cada um deles está concluído
satisfatoriamente. Este processo difere do controle de qualidade, pois
preocupa-se primariamente com a aceitação dos entregáveis. O controle de
qualidade preocupa-se primariamente em reunir os requerimentos
especificados para cada entregável.


Verificação do Escopo - Ferramentas & Técnicas

Inspeção

Inclui as atividades de medição, exame, teste e verificação para
determinar se o trabalho e os entregáveis reúnem os requerimentos e
os critérios de aceitação definidos no plano.

Inspeções são conhecidas como revisão, revisão de produtos, walk-
through e auditorias, as quais dependem do tipo de organização,
exemplos: revisão de qualidade ou garantia da qualidade.


Verificação do Escopo - Saída

Entregáveis aceitos

Processo que documenta os entregáveis que foram aceitos. Caso
não seja aceito, deve explicitar formalmente as suas razões.

Este processo objetiva documentar todas as evidências que foram
base para a composição do escopo do projeto.


Processo 5.5 – Controle do Escopo

* PMBOK Capítulo 5


Controle do Escopo

1. Declaração do escopo do projeto 1. Declaração do escopo do projeto
2. EAP (atualizações)
3. Dicionário da EAP 1. Sistema de controle de 2. Estrutura analítica do projeto
4. Plano de gerenciamento do mudanças (atualizações)
escopo do projeto 2. Análises de variância 3. Dicionário da EAP
5. Relatórios de desempenho 3. Replanejamento (atualizações)
6. Solicitações de mudanças 4. Sistema de gerenciamento da 4. Linha de base do escopo
aprovadas configuração (atualizações)
7. Informações do desempenho do 5. Mudanças solicitadas
trabalho 6. Ações corretivas recomendadas
7. Ativos de processos
projeto (atualizações)

Objetivo: Controlar os fatores que afetem o escopo do projeto. Controlar o
escopo assegurando que todas as mudanças solicitadas e as ações
corretivas recomendadas são executadas por meio de um processo
integrado.


Controle do Escopo - Entrada

Relatórios de desempenho

proporcionam informações sobre o desempenho do projeto. Relatórios de
desempenho podem também alertar a Equipe do Projeto para questões que
podem causar problemas no futuro.


Controle do Escopo - Ferramentas & Técnicas

Sistema de Controle de Mudança
Análise de Variância
Replanejamento
Sistema de Gerenciamento da Configuração


Diferenças PMBOK
(2004 – 2008)


Processo 5.1

1. Fatores ambientais da empresa
organizacionais
3. Termo de abertura do projeto 1. Plano de gerenciamento do
Planejamento do Escopo escopo do projeto
4. Declaração do escopo preliminar
do projeto
escopo do projeto

1. Documentação dos requerimentos
1. Termo de abertura do projeto 2. Plano de gerenciamento dos
2. Registros dos stakeholders Coletar os Requisitos requerimentos
3. Matriz de rastreabilidade dos
requerimentos


Processo 5.2

organizacionais
2. Termo de abertura do projeto 1. Declaração do escopo do projeto
3. Declaração do escopo preliminar 2. Mudanças solicitadas
Definição do Escopo
do projeto 3. Plano de gerenciamento do
4. Plano de gerenciamento do escopo do projeto (atualizações)
escopo do projeto
5. Solicitações de mudanças
aprovadas

1. Declaração do escopo do projeto
1. Termo de abertura do projeto Definição do Escopo 2. Atualização na documentação dos
2. Documentação dos requerimentos
requerimentos
organizacionais


Processo 5.3

2. Declaração do escopo preliminar 2. Estrutura analítica do projeto
do projeto 3. Dicionário da EAP
Criar EAP
3. Plano de gerenciamento do 4. Linha de base do escopo
escopo do projeto 5. Plano de gerenciamento do
4. Solicitações de mudanças escopo do projeto (atualizações)
aprovadas 6. Mudanças solicitadas

1. Declaração do escopo
do projeto 1. Estrutura analítica do projeto
2. Documentação dos 2. Dicionário da EAP
requerimentos 3. Linha de base do escopo
Criar EAP
3. Ativos de processos 4. Atualizações dos documentos
organizacionais do projeto


Exercícios


Questões

1. O processo de escolha e documentação da melhor abordagem para
se alcançar os objetivos do projeto é parte do processo de:
( ) A. Iniciação (autorização)
( ) B. Verificação do escopo
( ) C. Definição do escopo
( ) D. Planejamento do escopo

2. Bons objetivos de projeto devem ser:
( ) A. Gerais ao invés de específicos
( ) B. Estabelecidos sem considerar limitações de recursos
( ) C. Realistas e atingíveis
( ) D. Extremamente complexos


Questões

3. O project charter contempla:
( ) A. Resumo das condições de origem que definem o projeto
( ) B. Relações organizacionais, de autoridade e de
responsabilidade
( ) C. Cronograma de requerimento de recursos, incluindo
estimativas de tempo
( ) D. Todas as alternativas anteriores

4. Lições aprendidas são frequentemente baseadas em registros
históricos do projeto. Lições aprendidas podem ser usadas para:
( ) A. Ver quais erros foram cometidos previamente
( ) B. Ver como os problemas foram resolvidos previamente
( ) C. Prever tendências, ressaltar problemas e identificar
alternativas
( ) D. Todas as alternativas anteriores


Questões

5. De todas as decisões que os sponsors executivos têm que
considerar em uma reunião de revisão de fim-de-fase, a mais difícil
é:
( ) A. Cancelar o projeto
( ) B. Autorizar mudanças de escopo para fase seguinte
( ) C. Autorizar aumento de orçamento para fase seguinte baseado
em mudanças de escopo
( ) D. Alocar orçamento para a fase seguinte

6. Ir do Nível 3 para o Nível 4 na estrutura analítica pode resultar em:
( ) A. Menor precisão de estimativa
( ) B. Melhor controle do projeto
( ) C. Menores custos de relatórios de status
( ) D. Uma maior probabilidade de que alguma coisa irá falhar


Questões

7. Pode-se esperar mudança no escopo de um projeto se:
( ) A. O gerente de projeto fizer estimativas de custo sem ter uma
concepção do projeto
( ) B. Houver supersimplificação (subestimativa) da natureza do trabalho a
ser executado
( ) C. O gerente do projeto for escolhido após o projeto ter sido definido e o
custo e prazo já tiverem sido aprovados
( ) D. Todas as alternativas anteriores são possíveis, de acordo com a
situação

8. Uma boa definição de sucesso de um projeto é ter o projeto finalizado:
( ) A. Dentro do prazo previsto
( ) B. Dentro do prazo e custo previstos
( ) C. Dentro do prazo, custo e requisitos de performance técnica previstos
( ) D. Dentro do prazo, custo e desempenho previstos, e aceito pelo
cliente/usuário


Questões

9. O documento do projeto é um documento preparado pelo(s)
_________ que fornece ao gerente do projeto a autoridade para
utilizar recursos organizacionais.
( ) A. Gerente do projeto
( ) B. Gerentes funcionais
( ) C. Gerência sênior/patrocinador do projeto
( ) D. Cliente

10. O documento inicial que reconhece formalmente a existência de
um projeto é o(a) ________.
( ) A. Linha de base do escopo
( ) B. Plano de gerenciamento
( ) C. Project Charter
( ) D. Relatório de controle de configuração


Questões

11. Qual dos processos a seguir não é um processo de gerenciamento
de escopo?
( ) A. Relatório do escopo
( ) B. Planejamento do escopo
( ) C. Definição do escopo
( ) D. Verificação do escopo

12. O detalhamento progressivo de um plano de projeto ou dos
componentes de um plano (ex. a EAP ) é normalmente chamado
___________.
( ) A. Planejamento “rolling wave”
( ) B. Planejamento contínuo
( ) C. Planejamento “subset”
( ) D. Planejamento detalhado


Questões

13. No mínimo, o project charter deveria ___________.
( ) A. Descrever as responsabilidades e autoridade do gerente de projeto
( ) B. Discutir os riscos e restrições do projeto
( ) C. Designar a estrutura organizacional do projeto
( ) D. Apresentar os objetivos do negócio e a sua organização

14. O principal objetivo do gerenciamento de stakeholder é ___________.
( ) A. Identificar todos os potenciais usuários do projeto para assegurar a
análise completa de requerimentos
( ) B. Evitar as críticas do projeto por meio de lista das principais
preocupações dos stakeholder conhecidos
( ) C. Ser proativo na identificação e mapeamento dos stakeholders
identificando possíveis problemas que possam afetar o projeto
( ) D. Construir controle efetivo para evitar estouros de custos e prazos


Questões

15. Durante a decomposição, o gerente de projetos deveria
___________.
( ) A. Identificar os maiores elementos do projeto
( ) B. Identificar os elementos constituintes do entregável
( ) C. Verificar o correto detalhamento do entregável
( ) D. Todas as respostas acima

16. Um work package é ___________.
( ) A. Um entregável no menor nível da EAP
( ) B. Uma tarefa com um único identificador
( ) C. Uma descrição dos procedimentos do trabalho
( ) D. Um nível requerido de relatório


Questões

17. A regra de 80 horas diz que ___________.
( ) A. Uma duração de atividade de uma tarefa não seria mais do
que 80 horas
( ) B. Cada tarefa deveria ser quebrada em work packages que
necessitem não mais do que 80 horas de trabalho para ser
concluída
( ) C. Ninguém deveria ser alocado para o projeto que não fosse
capaz de trabalhar no mínimo 80 horas
( ) D. O orçamento deveria ser estabelecido para qualquer tarefa de
80 horas ou mais

(Fonte: Project Management IQ, International Institute for Learning, 2004)


Monitore os riscos quanto ao seu escopo


Plano Realístico
Não coloque escopo e prazos ambiciosos, mas realistas!

Siga corretamente todos processos (escopo, tempo e riscos) para determinação
das estimativas dos projetos.

O que é acordado não sai “caro“
Prazo final é prazo final!


Outras Bibliografias
BENNATAN, E.M. On Time Within Budget: Software Project Management
Practices and Techniques. USA: John Wiley & Sons, 2000
CHARVAT, Jason. Project Management Nation: Tools, Techniques, and Goals
for the New and Practicing IT Project Manager. USA: John Wiley & Sons, 2002
CHARVAT, Jason. Project Management Nation: Tools, Techniques, and Goals
for the New and Practicing IT Project Manager. USA: John Wiley & Sons, 2002
FRAME, J. Davidson. The value of PMP certification. Upper Darby, Pa. EUA:
Project Management Institute, 1994.
HALLOWS, Jolyon. Information Systems Project Management. USA:
AMACOM, 1998
HELDMAN, Kim. PMP: Project Management Professional Study Guide. USA:
Sybex, 2002
HELDMAN, Kim. PMP: Project Management Professional Study Guide. USA:
Sybex, 2002
KERZNER, Harold. Project management - a systems approach to planning,
scheduling, and controlling, 8. ed. EUA: John Wiley & Sons, 2001.


Outras Bibliografias
KERZNER, Harold. Using the project management maturity model – strategic
planning for project management. EUA: John Wiley & Sons, 2005.
OGC. Commom causes of project failure. London: OGC. 2005.
PMBOK, Project Management Body Knowledge. USA: PMI, 2004.
PMBOK, Project Management Body Knowledge (versão preliminar). USA: PMI,
2008.
PMI. Project Management Institute. Organizational project management maturity
model (OPM3) – knowledge foundation. USA: PMI, 2003.
RABECHINI JR. Roque. CARVALHO, Marly Monteiro de. Perfil das competências em
equipes de projetos. São Paulo: RAE-eletrônica, 2003.
RAD, Parviz F. The Advanced Project Management Office - A Comprehensive Look at
Function and Implementation. USA: St. Lucie Press, 2002
SILVEIRA, Gutenberg A. Fatores contribuintes para a maturidade em
gerenciamento de projetos: um estudo em empresas brasileiras. Tese de doutorado.
São Paulo: Universidade de S. Paulo. 2008
SODHI, Jag. IT Project Management Handbook. USA: Management Concepts, 2001.
SOTILLE, Mauro. et al. Gerenciamento do escopo em projetos. R. Jnaeiro: FGV
Editora. 2007.


Copyright © 2009 Prof. Dr. Gutenberg de A. Silveira.

Todos direitos reservados. Reprodução ou divulgação total ou
parcial deste documento é expressamente proíbido sem o
consentimento formal, por escrito, do Professor (autor).

Obrigado.

Mantenha contato!!

Gutenberg.silveira@terra.com.br


Gerenciamento de Escopo em Projetos FGV

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Gerenciamento de Escopo em Projetos FGV

Similar to Gerenciamento de Escopo em Projetos FGV (20)

Gerenciamento de Escopo em Projetos FGV