gestão do escopo de projetos - prof. luis augusto dos santos

Gestão do Escopo de Projetos

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

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

Prof. Luis Augusto dos Santos, PMP

Mês Ano

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

2

Processos de Áreas de Conhecimento

Grupos de Processos de Gerenciamento de Projetos (42) - PMBOK® 4ª. Edição

INICIAR PLANEJAR EXECUTAR MONITORAR e CONTROLAR

CONCLUIR

4. INTEGRAÇÃO 4.1 Termo de Abertura

4.2 Desenvolver plano de Gerenciamento de Projeto

4.3 Dirigir e gerenciar a execução do projeto

4.4 Trabalho do Projeto 4.5 Controle Integrado de Mudanças

4.6 Encerrar

5. ESCOPO 5.1 Levantar Requisitos 5.2 Definir 5.3 Criar WBS

5.4 Verificar 5.5 Controlar

6. TEMPO 6.1 Definir atividades 6.2 Sequenciar 6.3 Estimar recursos 6.4 Estimar duração 6.5 Desenv Cronograma

6.6 Controlar Cronograma

7. CUSTO 7.1 Estimar 7.2 Determinar Orçamento

7.3 Controlar Custos

8. QUALIDADE 8.1 Planejar a Qualidade 8.2 Assegurar Desempenho

8.3 Controlar a Execução de Qualidade

9. RECURSOS HUMANOS

9.1 Plano de RH 9.2 Adquirir equipe 9.3 Desenvolver 9.4 Gerenciar

10. COMUNICAÇÃO

10.1 Identificar Stakeholders

10.2 Plano de Comunicações

10.3 Distribuir informação 10.4 Ger. Stakeholders

10.5 Relatar Desempenho

11. RISCO 11.1 Planejar Ger. Risco 11.2 Identificar 11.3 Qualificar 11.4 Quantificar 11.5 Planejar respostas

11.6 Monitorar e Controlar os Riscos

12. AQUISIÇÃO 12.1 Plano de Aquisição 12.2 Conduzir 12.3 Administrar 12.4 Encerrar


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

formalmente.

5


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

esperada do escopo: Será realizada a avaliação da freqüência e intensidade de mudança, previsão de

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

classificação das

mudanças:

As solicitações de mudanças - SM, são identificadas por número seqüencial SM,

categorizadas em impacto principal no Escopo, Tempo ou Custo. Classificadas em

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

Adicionais:

Devido a inovação deste, o consultor contratado deverá elaborar relatório semanal da

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


8

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

empregadas:

Entrevistas. Grupo Focal. Oficina de Facilitação (JAD e QFD-VOC),

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

projeto:

Relativos ao negócio, gerenciamento, entregas e relatórios.

Requisitos de

produto:

Relativos ao desempenho técnico, treinamento, garantia, segurança, adequação

a normas e/ou legislação regional/nacional/internacional.

Documentação de

Requisitos:

As documentações seguem os definidos no Plano de Comunicação, formato de

documentos, apresentações e locais de armazenamento.

Serão versionados no formato XXXX_DReq_aaaammdd_Vnn, onde:

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


Levantamento de Requisitos • 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,

iteração.

10



• 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.

• Ditatorial: Um indivíduo toma a decisão. 11


Levantamento de Requisitos • Documentos de Requisitos

• 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.

• Matriz de Rastreabilidade de Requisitos • 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, desenvolvimento, teste de estratégia e cenários.

12


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

Deployment - QFD; Voice of the Customer - VOC. 15



• 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


17 17

Declaração de Escopo


Elaborado por: Data:

Declaração do escopo

preliminar do projeto Informações fornecidas pelo iniciador ou pelo patrocinador. Qual trabalho, o que,

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

Produtos:

Identificar que produtos serão entregues até o término do projeto e pontos de 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

abordagem:

Indicar o modo, a forma, que o projeto produzirá o produto.

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:


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)

20

O que vamos

Fazer?

WBS

Quando faremos?

Quem irá fazer?

Que faremos

primeiro?

Como divulgaremos

os resultados?

Que qualidade será

necessária?

Que riscos iremos

incorrer?

Que será feito

internamente e

externamente?

Quanto tempo irá

demorar?

Quanto irá custar?


21

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

Equipamento

Facilidades

Serviços

Gerenciamento de Sistemas de

Engenharia

Atividades de Suporte ao GP

Ordens Técnicas

Dados de Engenharia

Dados de Gerenciamento

Construção

Manutenção

Nível Organizacional

Nível Intermediário

Nível Depósito

Simulação

Teste Operacional

Desenvolvimento De Teste

Teste

Treinamento Gerenciamento

de Projeto Dados Facilidades

Equipamento

de suporte

Teste e

Avaliação

Veículo

Aéreo

Sistema de

Veículo Aéreo

Nível do Projeto Nível do

Deliverable

Nível do Work Package


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.

• Documentos de Projeto (atualizações)

• 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 Projeto (atualizações) • Documentos de Requisitos e Matriz de Rastreabilidade de

Requisitos

34


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


36

Ciclo de Vida de Solicitação de Mudança

SM SM

situação

SM SM

SM SM

aprovada

solicitante CCM equipe solicitante

?

Adiada

Recusada Confirmada

SM


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

Documents