Gestão do Escopo de Projetos - Prof. Luis Augusto dos Santos

Cursos de Pós-Graduação Lato Sensu e MBA

Gestão do Escopo de Projetos
Prof. Luis Augusto dos Santos, PMP
Mês Ano

Prof. Luis Augusto dos Santos, PMP Gestão do Escopo de Projetos

Processos de Grupos de Processos de Gerenciamento de Projetos (42) - PMBOK® 4ª. Edição
Áreas de
Conhecimento INICIAR PLANEJAR EXECUTAR MONITORAR e CONCLUIR
CONTROLAR
4. INTEGRAÇÃO 4.1 Termo de 4.2 Desenvolver plano de 4.3 Dirigir e gerenciar 4.4 Trabalho do 4.6 Encerrar
Abertura Gerenciamento de Projeto a execução do Projeto
projeto 4.5 Controle Integrado
de Mudanças
5. ESCOPO 5.1 Levantar Requisitos 5.4 Verificar
5.2 Definir 5.5 Controlar
5.3 Criar WBS
6. TEMPO 6.1 Definir atividades 6.6 Controlar
6.2 Sequenciar Cronograma
6.3 Estimar recursos
6.4 Estimar duração
6.5 Desenv Cronograma
7. CUSTO 7.1 Estimar 7.3 Controlar Custos
7.2 Determinar Orçamento
8. QUALIDADE 8.1 Planejar a Qualidade 8.2 Assegurar 8.3 Controlar a
Desempenho Execução de
Qualidade
9. RECURSOS 9.1 Plano de RH 9.2 Adquirir equipe
HUMANOS 9.3 Desenvolver
9.4 Gerenciar
10. 10.1 10.2 Plano de 10.3 Distribuir 10.5 Relatar
COMUNICAÇÃO Identificar Comunicações informação Desempenho
Stakeholders 10.4 Ger.
Stakeholders
11. RISCO 11.1 Planejar Ger. Risco 11.6 Monitorar e
11.2 Identificar Controlar os Riscos
11.3 Qualificar
11.4 Quantificar
11.5 Planejar respostas
12. AQUISIÇÃO 12.1 Plano de Aquisição 12.2 Conduzir 12.3 Administrar 12.4 Encerrar
2

© Professor Luis Augusto dos Santos, PMP Gestão do Escopo de Projetos

Gerenciamento do Escopo

• Os processos necessários para assegurar que o projeto
inclua todo o trabalho requerido para completar o projeto
de forma bem sucedida.
• Preocupa-se principalmente com a definição e controle
do que está ou não incluído no projeto.
• Escopo do projeto – o trabalho que deve ser executado a fim de
fornecer um produto com as características e funções
especificadas
• Escopo do produto – as características e funções que devem ser
incluídas no produto ou serviço
3



• Definição do Gerente do Projeto: deve ser feita o
mais cedo possível.
• Restrições: fatores que limitarão as opções da
equipe de gerenciamento. Ex.: Orçamento pré-
definido; Prazo para entrega.
• Premissas: fatores que, para fim de planejamento,
serão considerados reais, verdadeiros ou certos,
geralmente envolvem risco, identificadas nessa fase
ou na identificação de riscos.

4



• Escopo: “A soma de produtos e serviços (entregas) a
serem fornecidos pelo projeto.”
• Planejamento de escopo: “O processo de elaborar e
documentar progressivamente o trabalho do projeto.…”
• Deve ser delineado na fase de início do projeto e deve ser
documentado.
• Processo gradativo de elaboração e documentação do trabalho
a ser realizado.
• A descrição do produto e seus requisitos elabora-se a
Declaração de Escopo.
• Gerenciamento e Mudanças de Escopo devem ser feitos
5
formalmente.

Plano de Gerenciamento do Escopo
Programa: Metodologia de GP Projeto: SDocGP
Elaborado por: las Data:

Descrição: Gerenciamento e integração das mudanças no Escopo do Projeto. Orientação sobre como o
escopo do projeto será definido, documentado, verificado, gerenciado e controlado.
Definição: Reuniões de trabalho seguindo calendário acordado e com apoio do Plano de
Comunicações. Reuniões com fornecedores e clientes. Reuniões com Atas. (PMO e
Técnica). Apresentações quinzenais executivas.
Documentação: As documentações seguem os definidos no Plano de Comunicação, formato de
documentos, apresentações e locais de armazenamento.
Proj. Simples: AR, TA, DE, EAP, SS, CM, SM, ..., TE, Nome XXXX aaaammdd.xls
Proj. Médio/Complexo: XXXX nnDD aaaammdd.doc
XXXX = Sigla do projeto, nn = número seqüencial do padrão de documentos
DD = código do documento,
Ex.: XXXX 01AR = primeira reunião; XXXX 04EAP, onde aaaammdd = ano mes e dia
Estabilidade Será realizada a avaliação da freqüência e intensidade de mudança, previsão de
esperada do escopo: tempos e quantidades de mudanças.
A estabilidade é definida como a relação entre as SM abertas versus fechadas.
Quanto mais próximas, mais estável é o processo. (KPI ee = SMfechada / SMaberta )
Identificação e As solicitações de mudanças - SM, são identificadas por número seqüencial SM,
classificação das categorizadas em impacto principal no Escopo, Tempo ou Custo. Classificadas em
mudanças: três prioridades 0, 1 e 2 (urgente, necessário e perfectiva).
Integração: Cada SM apresentada deverá ser respondida ao cliente se aprovada ou não pelo
patrocinador, segundo sua prioridade ( "0" no dia; "1" em 2 dias e "2" em 5 dias )
Notas/Comentários Devido a inovação deste, o consultor contratado deverá elaborar relatório semanal da
Adicionais: performance da equipe e estabilidade do processo de mudanças.

Levantamento de Requisitos

• Definir e documentar as necessidades dos
stakeholders para encontrar os objetivos do projeto.
• Documentos de Requisitos
• Plano de Gerenciamento de Requisitos
• Matriz de Rastreabilidade de Requisitos

7


Plano de Gerenciamento de Requisitos
Elaborado por: Data:
Descrição: Informações coletadas dos stakeholders quanto as suas necessidades para
encontrar o objetivo do projeto.
Stakeholders: Estabelecidos no Plano de Comunicação quanto a projeto e produto,
patrocinador, cliente e outros stakeholders
Necessidades: O que é exigido. Proj. Simples: Será utilizado o TA como baseline.
Proj. Médios/Complexos: Matriz de Rastreabilidade (origem) por progresão
faseado (Necessidade, Oportunidades, Metas, Objetivos, EAP, Desenho,
Desenvolvimento, Testes de Cenários e Estratégia)
Expectativas: O que se espera quando da utilização e desempenho do projeto, produto/serviço
entregue.
Técnicas a serem Entrevistas. Grupo Focal. Oficina de Facilitação (JAD e QFD-VOC),
empregadas: Grupo de Criatividade (Brainstorming, Grupo Nominal, Delphi, Mapeamento de
Idéias, Diagrama de Afinidades)
Tomada de Decisões (Unanimidade, Consenso, Maioria, Pluraridade, Autocrática)
Formulários, Questionário e Pesquisa. Observações.
Protótipo.
Requisitos de Relativos ao negócio, gerenciamento, entregas e relatórios.
projeto:
Requisitos de Relativos ao desempenho técnico, treinamento, garantia, segurança, adequação
produto: a normas e/ou legislação regional/nacional/internacional.

Documentação de As documentações seguem os definidos no Plano de Comunicação, formato de
Requisitos: documentos, apresentações e locais de armazenamento.
Serão versionados no formato XXXX_DReq_aaaammdd_Vnn, onde: 8
XXXX = Sigla do projeto, e Vnn é o número da versão autorizada pelo CM.

• Termo de Abertura (Project Charter)
• Requisitos e descrição do produto em alto-nível.
• Registro de Stakeholder
• Identificação de quem providencia informações de projeto e
requisitos de produto.
• Documento do Ger. da Comunicação: Processo Identificar
Stakeholders.
• Deve ser utilizado o mais eficientemente possível.
• Devem ser classificados de acordo com seus interesses,
influência e envolvimento, expectativas, importância e influência
no projeto.
• Permite ao gerente de projeto focar nas relações necessárias
para garantir o sucesso do projeto. 9


• Entrevistas
• Perguntas "um-em-um“ aos interessados e especialistas, identifica as
características e funções das entregas.
• Grupo Focal
• Stakeholders pré-qualificados e especialistas para entender ações e
expectativas, mais conversacional que “um-a-um”.
• Oficina de Facilitação
• Sessões multifuncionais, rápida definição de diferenças, cria confiança,
relacionamento, melhora a comunicação, consenso.
• Joint Application Development (Design) - JAD; Quality Function
Deployment - QFD; Voice of the Customer - VOC.
• Questionário e Pesquisa
• Um grande número de respondentes para análise estatística.
• Observações
• Visualização de pessoas no ambiente de como executam o trabalho
(“job shadowing”) para identificar requisitos escondidos.
• Protótipo
• Obter retorno antecipado, experimento, progressiva elaboração, 10
iteração.

• Grupo de Criatividade
• Brainstorming: Gerar e coletar múltiplas idéias.
• Grupo Nominal: Aprimora o brainstorming para priorização.
• Técnica Delphi: Grupo de especialistas respondem
questionários e retornam sobre as respostas, de forma anônima.
• Mapa de Idéias/Pensamento: Brainstorming individuais são
consolidados para refletir entendimento e novas idéias.
• Diagrama de Afinidade: Alto número de idéias para revisão e
análise.
• Grupo de Tomada de Decisões
• Unanimidade: Todos concordam.
• Maioria: Mais de 50%.
• Pluralidade: Maior grupo decide mesmo se a Maioria não
alcançada.
11
• Ditatorial: Um indivíduo toma a decisão.

• Como encontrar as necessidades de negócios.
• Devem ser não ambíguos (mensuráveis e testáveis), rastreáveis,
completos, consistentes e aceitáveis.
• Simples lista de requisitos categorizados (stakeholder e prioridade) até
um sumário executivo, detalhadas descrições e anexos.
• Cria uma linha básica.
• Plano de Ger. de Requisitos
• Como as atividades serão planejadas, controladas e comunicadas,
atividades de Gerenciamento de Configuração em como as mudanças
serão iniciadas, como os impactos serão analisados, níveis de
autorização.
• Tabela que liga requisitos com origem e ciclo de vida.
• Auxilia a adicionar valor ao negócio e projeto.
• Situação, aprovação e entrega.
• Requisitos de necessidades de negócio, oportunidades, metas,
objetivos, objetivos de projeto, escopo, EAP, desenho, 12
desenvolvimento, teste de estratégia e cenários.

Estudo de caso

Exercício 1:
• Leia o Estudo de Caso e responda as questões.

13


Definição do Escopo

• Termo de abertura do projeto (Project Charter)
• se não existir, então um conjunto comparável de informações
precisa ser adquirido ou desenvolvido e usado para desenvolver
a declaração do escopo detalhada do projeto.

• Ativos de processos organizacionais
• Políticas, procedimentos e formulários.
• Arquivos anteriores de projetos.
• Lições aprendidas de fases anteriores ou projetos.
14


• Opinião especializada
• Cada área de aplicação possui especialistas que podem ser
usados para desenvolver partes da declaração do escopo
detalhada do projeto.
• Análise de produtos
• Cada área de aplicação possui um ou mais métodos geralmente
aceitos para transformar os objetivos do projeto em requisitos e
entregas tangíveis.
• Decomposição do produto, análise de sistemas, requisitos,
funcional e engenharia de valor.
• Identificação de alternativas
• Gerar diferentes abordagens para executar e realizar o trabalho.
• Brainstorming e pensamento lateral.
• Oficina de Facilitação
• Joint Application Development (Design) - JAD; Quality Function
15
Deployment - QFD; Voice of the Customer - VOC.

• Declaração de Escopo de Projeto
• Descreve em detalhes as entregas, seus critérios de aceite e o
trabalho necessário.
• Um entendimento comum do escopo do projeto para as partes
interessadas.
• Exclusões para gerenciar expectativas.
• Habilita a equipe a desenvolver o planejamento e guia a
execução do trabalho.
• Linha básica para avaliar solicitações de mudanças e trabalho
adicional
• Documentos de Projeto (atualizações)
• Registro de Stakeholder.
• Documentos de Requisitos.
• Matriz de Rastreabilidade de Requisitos.
16


Declaração de Escopo
Elaborado por: Data:
Declaração do escopo Informações fornecidas pelo iniciador ou pelo patrocinador. Qual trabalho, o que,
preliminar do projeto deverá ser realizado e quais entregas precisam ser produzidas. Documenta as
características e limites do projeto e seus produtos e serviços associados, além
dos métodos de aceitação e controle do escopo.
Objetivos do projeto: Declaração específica, mensurável, atingível (conquistável), realista e definida no
tempo
Descrição dos Identificar que produtos serão entregues até o término do projeto e pontos de
Produtos: entregas. Descrever o produto de forma o suficiente para possibilitar que a equipe
possa criá-lo e acordar para ser alcançado no prazo.
Processo de Indicar o modo, a forma, que o projeto produzirá o produto.
abordagem: Proj. Simples: seguirá a documentação simplificada de uma Fase.
Proj. Médio: Toda a documentação deverá ser armazenada na área de projetos
por Fases definidas no Planejamento de Escopo.
Proj. Complexo: Deverá ter Análise de Custo Benefício.
Entregas do projeto: Uma lista de sumarizada de sub produtos que serão entregues.
Entrega A, B, C, ....
Requisitos

Medidas de qualidade: Critério que determina a aceitação.

Exclusões conhecidas:
17
17

Estudo de caso

Exercício 2:
• Leia o Estudo de Caso e responda as questões.

18


Criar a EAP ou WBS
• A Estrutura Analítica do Projeto (“Work Breakdown
Structure”) é o principal insumo para todo o
Planejamento
• Divide o escopo do Projeto de maneira hierárquica, de
forma que cada nível descendente representa um maior
detalhamento do trabalho a ser realizado.
• O WBS facilita a Comunicação entre a Equipe de
Gerenciamento e os “stakeholders”
• “Work Package” (Pacote de Trabalho): “deliverable” (entrega)
é o nível mais baixo do WBS. Deverá ser decomposto em
atividades.
• “WBS Dictionary”: contém a descrição dos “Work Packages”
(às vezes indicações de datas, custos e recursos)
19


EAP / WBS
Subdividir o grande problema em problemas menores
“Dividir para Conquistar”
(Júlio César, “De Bello Galico”, séc I AC) Que faremos
primeiro?

Quanto tempo irá
demorar?
O que vamos
Fazer? Quando faremos?

WBS
Quanto irá custar?

Quem irá fazer?
Que será feito
internamente e
externamente? Que qualidade será
necessária?

Como divulgaremos
os resultados?
Que riscos iremos
incorrer? 20


Nível do
Nível do Projeto
Deliverable Sistema de
Veículo Aéreo

Gerenciamento Veículo Equipamento Teste e
Treinamento Dados Facilidades
de Projeto Aéreo de suporte Avaliação

Gerenciamento
Ordens Nível
de Sistemas de Equipamento Construção Simulação
Técnicas Organizacional
Engenharia

Atividades de Dados de Nível Teste
Facilidades Manutenção
Suporte ao GP Engenharia Intermediário Operacional

Dados de Nível Desenvolvimento
Serviços
Gerenciamento Depósito De Teste

Teste

Fuselagem Engenho Comunicação Navegação Controle de fogo

Nível do Work Package
21


Como e porque da EAP / WBS
• Estrutura sobre a qual a equipe pode se basear para:
• Atribuir responsabilidades; Criar os relatórios de status e
performance do projeto; Controle de Custos.
• Pensar em entregas (deliverables), e não em atividades
• Listar de marcos (milestones), todos podem saber quando foi
entregue.
• Definir uma equipe, uma pessoa ou terceiro como responsável
pela entrega (não pode existir responsabilidades compartilhada).
• Ter uma clara a visão do resultado final do projeto.
• Pensar no resultado como um todo, dividindo-o
hierarquicamente.
• Estabelecer fases, podem ser o primeiro nível do WBS.
• Não há necessidade de que os ramos tenham o mesmo número
de níveis.
• Mudanças de escopo sempre mudam a WBS!
22


Criar EAP ou WBS
• Premissas:
• Deve ser vista como uma lista de “milestones”, portanto todos
devem poder saber quando esses foram cumpridos
• Não é necessário que todos os ramos tenham o mesmo número
de níveis
• Deve sempre ser possível definir uma equipe ou uma pessoa
como responsável pelo “deliverable” (não pode existir
recobrimento de responsabilidades)

• Não deve ser confundida com outros tipos de estruturas
analíticas, usadas para apresentar as informações do
projeto. Outras estruturas usadas em algumas áreas de
aplicação ou em outras áreas de conhecimento incluem:
• Organograma (ORG ou OBS)
• Lista de preço de materiais (LPM ou BOM)
• Estrutura analítica dos riscos (EAR ou RBS)
• Estrutura analítica dos recursos (EAR ou RBS) 23


Criar a EAP
• Estrutura Analítica do Projeto
• O principal documento gerado pelo processo Criar a EAP é a própria
EAP.
• Identificador exclusivo de um código de contas a cada componente da
EAP, ao pacote de trabalho e às contas de controle dentro de uma
EAP. Fornecem uma estrutura para a somatória hierárquica dos custos,
cronograma e informações de recursos.
• Dicionário da EAP
• Detalhamento da definição de escopo do projeto e é usado para
verificar se as entregas produzidas e aceitas estão incluídas no escopo
aprovado do projeto.
• Linha de base do escopo
• Declaração de Escopo do Projeto; EAP e Dicionário EAP.
• A criação da EAP pode implicar mudanças (se aprovadas) na
documentação de requisitos.
24


Estudo de caso

Exercício 3:
• Criar a EAP.

25


Estudo de caso

Exercício 4:
• Criar mais uma EAP.

26


Verificar o Escopo

• Processo de Controle que trata da aceitação formal das
entregas (“deliverables”) do Projeto
• Revisão de “deliverables” e resultados do trabalho para
assegurar que todos foram completados corretamente e
satisfatoriamente.
• Já o Controle de Qualidade implica na precisão, exatidão
(“correctness”) da qualidade dos requisitos, executado antes de
Verificar o Escopo (o aceite das entregas).
• Se o projeto for terminado mais cedo que o esperado, o
processo de verificação deve estabelecer e documentar
o nível e a extensão do que foi feito 27


Verificar o Escopo
• Plano de Gerenciamento do projeto
• Linha de Base de Escopo; Declaração de Escopo do Projeto;
EAP e Dicionário EAP.
• Entregas Validadas
• Completadas e verificadas quanto a precisão/exatidão
(“correctness”) pelo Controle de Executar a Qualidade.
• Inspeção
• Determina se os resultados estão em conformidade com os
requisitos.
• Podem ser testes, medições ou exames.
• Chamadas de revisões, revisões de produto, “walkthroughs”,
certificações, auditorias, etc.. 28


Verificar o Escopo
• Entregas Aceitas
• Documenta as entregas que encontraram os critérios de aceite e
formalmente aceitas (“signed off”).
• Documento enviado ao Encerramento do Projeto.
• Solicitação de Mudanças
• Entregas terminadas que não foram aceitas são documentadas,
juntamente com as razões da não conformidade.
• Podem requerer reparo de defeito.
• São processadas para revisão e destinação pelo processo
Controle integrado de mudanças.
• Documentos de Projeto (atualização)
• Definição do produto ou relatório de situação 29


Estudo de caso

Exercício 5:
• Verificar o escopo.

30


Controlar o Escopo
• Monitora a situação do projeto e escopo do produto e mudanças na
linha de base.
• Ocorre junto aos outros processos de Controle Integrado de
Mudanças.
• Assegura que todas as Solicitações de Mudanças e recomendadas
ações corretivas e preventivas sejam tratadas.
• Mudanças não controladas são referidas como “Scope Creep”
• Esticamento do escopo ou escopo arrastado.
• Mudanças são inevitáveis, é da natureza dos Projetos:
• O Cliente quer uma nova “feature”, premissas válidas no início tornam-
se falsas, o planejamento não estimou corretamente custo ou prazo. 31


Controlar o Escopo
• Plano de Gerenciamento do Projeto
• Linha de base do escopo. Plano de Ger. do Escopo. Plano de
Ger. de Mudanças. Plano de Ger. de Configuração. Plano de
Ger. de Requisitos.
• Informações sobre o Desempenho do Projeto
• Progresso como quais entregas foram iniciadas e finalizadas.
• Ativos de processos organizacionais
• Formal e informal políticas de controle de escopo,
procedimentos e guias,
• Métodos de monitoramento e relatórios. 32


Controlar o Escopo
• Análise da variação
• As medições de desempenho são usadas para avaliar a
extensão da variação em relação à linha de base original.
• Determinar a causa e o grau da variação e decidir se são
necessárias ações corretivas ou preventivas.

• Ações Corretivas
• para que o desempenho do projeto fique de acordo com o
plano de gerenciamento do projeto
• Ações Preventivas
• para reduzir a probabilidade de possíveis conseqüências
negativas

33


Controlar o Escopo
• Medições sobre Desempenho do Trabalho
• Planejado versus real, documentada e comunicada.
• Ativos de processos organizacionais (atualizações)
• Causas das variações.
• Razões que motivaram as ações corretivas.
• Lições aprendidas do controle de mudanças do escopo do
projeto.
• Solicitações de Mudanças
• Podem resultar em mudança na linha de base do escopo.
• Podem incluir ações corretivas ou preventivas, ainda reparo de
defeito.
• Plano de ger. do projeto (atualizações)
• Se mudanças aprovadas: a linha de base do escopo, declaração
de escopo, EAP e dicionário, linha de base de custo e
cronograma.
• Documentos de Requisitos e Matriz de Rastreabilidade de
34
Requisitos

SCM – System Control Management ou
CCB – Change Control Board
• Embora estejamos falando de Controle de Mudanças do
Escopo é importante ter uma visão integrada de
Mudanças
• É importante definir:
• Um “Sistema (Integrado) de Controle de Mudanças”
• E dentro do SCM um “Comitê de Controle de Mudanças” (ou
CCB – “Change Control Board”), ou seja, quem, dentro do OBS
do Projeto terá alçada para aprovar ou reprovar mudanças
propostas.
35


Ciclo de Vida de Solicitação de Mudança
solicitante CCM equipe solicitante

SM
SM
SM
SM SM SM
SM
aprovada situação

?
Recusada Confirmada

Adiada

36


Estudo de caso

Exercício 6:
• Controlar o escopo.

37


.

Obrigado.
Luis Augusto dos Santos, PMP


Gestão do Escopo de Projetos - Prof. Luis Augusto dos Santos

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Gestão do Escopo de Projetos - Prof. Luis Augusto dos Santos

Semelhante a Gestão do Escopo de Projetos - Prof. Luis Augusto dos Santos (20)

Mais de Sustentare Escola de Negócios

Mais de Sustentare Escola de Negócios (20)

Gestão do Escopo de Projetos - Prof. Luis Augusto dos Santos