Livro gerenciamento de escopo

GERENCIAMENTO DE ESCOPO

Kadu Chaves Anastรกcio

APRESENTAÇÃO Gerenciamento de Escopo Esta disciplina tem o intuito de fornecer um entendimento nas práticas de gerenciamento de escopo, compreendendo a coleta de informações, definição de uma documentação, criação de uma estrutura analítica, verificação e controle.

UNIDADE 1 Caracterização Objetivos da aula • Traçar as características do gerenciamento de escopo; • Introduzir conceitos sobre o gerenciamento de escopo; • Apresentar características sobre o gerenciamento de escopo; Temos, no mundo de hoje, uma grande dificuldade na definição do escopo. Diversos são os fatores que influenciam nesta realidade, alguns deles são: • Número de envolvidos; • Alinhamento de expectativas; • Ruídos na comunicação; • Falta de clareza em expressar o que se deseja; • Falta de capacidade de entendimento do que foi passado; • Falhas na documentação dos requisitos levantados; • Problemas na transcrição e estruturação dos requisitos coletados; • Falta de uma validação com os entrevistados; Um exemplo bem claro é este: “Eu sei que você acredita que entendeu o que você pensa que eu disse, mas eu não estou certo que você compreendeu que o que você ouviu não é o que eu quis dizer.” (autor anônimo) Essa dificuldade acarreta em uma cascata de problemas nos projetos, já que o escopo é a base para o planejamento de todas as outras áreas de processos de projetos. Sendo assim, um escopo mal feito, com certeza, trará para o projeto uma grande chance de problemas e até de fracasso, e um escopo bem feito aumenta muito as chances de sucesso.

Precisamos sempre medir a eficiência e a eficácia de um escopo para que, consequentemente, todo o projeto seja direcionado a esta definição. Mas para isso é muito importante entender a diferença entre eficiência e eficácia.

Gerenciamento do Escopo

Eficiência = Eficácia =

Re sultados obtidos Re cursos consumidos

Re sultados obtidos Re cursos pretendidos

Limitações do escopo do PMBOK® • Se limita ao gerenciamento de um projeto isoladamente; • Projetos bem sucedidos para o gerente de projetos nem sempre são bem sucedidos para a organização; • Não se preocupa com o produto depois de entregue, mas sim em atender as necessidades que deram origem ao projeto; • Não gerencia recursos compartilhados em vários projetos.

E quais são as soluções para isto, respectivamente 1. Gestão de portfólio e programas; 2. Alinhamento com o planejamento estratégico; 3. Gestão de produto e marketing; 4. Gestão centralizada de recursos.

Problemas mais comuns no gerenciamento de projetos 67.3%

Problemas de comunicação Falta de alcance das datas finais

64.5%

Escopo não definido adequadamente

60.9%

Mudanças de escopo constantes Recursos humanos insificiêntes Riscos mal estimados Competição entre o dia-a-dia e as rotinas do projeto Mudanças constantes de prioridades

56.8% 52.7% 50.2% 44.5% 41.6% 41.6%

Desvios de orçamento 33.0%

Estimativas incorretas 29.1%

Problemas com fornecedores 24.8%

Retrabalhos sobre a qualidade do produto

24.3%

Responsabilidades e funções indefinidas

22.7%

Falta de suporte do patrocinador

20.2%

Falta de competência no gerenciamento Proibida a reprodução – © UniSEB Interativo

Falta de metodologia

19.1%

Falta de ferramentas de suporte Cliente não satisfeito

17.0% 13.2%

Falta de conhecimento técnico na área Outros Não temos problemas

9.5% 6.4% 1.6%

% das organizações que citaram cada item

Imagem: http://PMSOURVEY.ORG/ – 2012 6

Caracterização – Unidade 1

Aspectos mais considerados na gestão de projetos Apectos mais considerados na gestão de projetos Tempo

93.2%

Escopo

91.7%

Custo

79.2%

Comunicação

65.7%

Riscos

63.8%

Qualidade

60.4%

Recursos Humanos

57.5%

Integração

56.5%

Aquisições Govenrnância

49.0%

13.0%

Imagem: http://PMSOURVEY.ORG/ – 2012

Referências bibliográficas BARCAUI, André B., Gerente Também é Gente... Um Romance sobre Gerência de Projetos. Rio de Janeiro. Brasport, 2006.

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

7

Proibida a reprodução – © UniSEB Interativo

Gerenciamento do Escopo

8

UNIDADE 2 Definições Objetivos da aula • Explicar o que é a coleta de requisitos; • Apresentar técnicas de coleta de requisitos; • Enfatizar o foco nas necessidades e alinhamento de expectativas; • Exibir técnicas de qualidade de escopo; • Passar dicas para coleta de requisitos; O que é o gerenciamento do escopo do projeto?

“O gerenciamento do escopo do projeto inclui os processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas o necessário, para terminar o projeto com sucesso. Esse gerenciamento está relacionado principalmente com a definição e controle do que está e do que não está incluso no projeto”. Project Management Institute. A guide to the Project Management Body of Knowledge (PMBOK® Guide). Pennsylvania: PMI, 2008, capítulo 5, pag. 92.

Objetivos do projeto Incluem critérios mensuráveis do sucesso do projeto (objetivos técnicos, de negócios, custo, cronograma e qualidade). Podem incluir metas (custo, cronograma e qualidade). Cada objetivo deve ser mensurável.

Escopo do produto O escopo do produto consiste nas características e funções que descrevem um produto, serviço ou resultado a ser alcançado pelo projeto.

Exemplo: cor, tamanho, forma de funcionamento, etc.

Gerenciamento do Escopo

Escopo do projeto Já o escopo do projeto trata-se do trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas. Exemplo: reuniões, relatórios, planejamento, fabricação, etc.

Requisitos São as necessidades e expectativas dos interessados no projeto, principalmente do cliente. Nele estão descritas as características do produto, serviço ou resultado, assim como das entregas da gestão do projeto.

Premissas Segundo o PMBOK®4ª Edição: “São fatores associados ao escopo do projeto que, para fins de planejamento, são assumidos como verdadeiros, reais ou certos sem a necessidade de prova ou demonstração”. A equipe do projeto depende desses fatores para dar andamento aos trabalhos.

Exemplo: nivelamento do terreno pelo fornecedor.

Restrições São fatores, que podem ser internos ou externos, sempre associados ao escopo do projeto, em geral obrigatórios e impostos pelo cliente ou organização executora. Esses fatores restringem a atuação da equipe do projeto.

Proibida a reprodução – © UniSEB Interativo

Requisito, premissa ou restrição?

Um problema comum no planejamento do escopo de um projeto é a dificuldade em identificar, mediante a cada informação levantada, se a mesma se trata de um requisito, uma premissa ou uma restrição.

Então, sugerimos a aplicação de três perguntas para cada informação levantada, de forma que possamos identificar o tipo de informação que se trata. São elas:

10

Definições – Unidade 2

Informação Descreve o produto, serviço ou resultado final?

Sim

Requisito

Sim

Premissa

Sim

Restrição

Não A equipe do projeto depende disso para trabalhar?

Não Restringe a atuação da equipe do projeto?

Imagem 2.1 Fonte: Autor.

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Exemplos de informações e sua classificação em um projeto de criação de um bicicleta artesanal: • Material do quadro: REQUISITO • 1 mês para terminar: RESTRIÇÃO • Tipo do pneu: REQUISITO • Finalização do desenho pelo projetista: RESTRIÇÃO (se o projetista é um membro da equipe do projeto) ou PREMISSA (se o projetista não faz parte da equipe do projeto, ou seja, é um fornecedor externo) • Tipo do sistema de suspensão: REQUISITO • Entrega da tinta pelo fornecedor: PREMISSA Partes interessadas (stakeholders) São organizações, grupos ou indivíduos que possuem algum tipo de interesse no projeto. Os principais tipos de stakeholders do projeto são: gerente de projeto, cliente, patrocinador, usuário final, especialista, fornecedor, etc.

Processos de gerenciamento do escopo do projeto A área de processos de gerenciamento de escopo do projeto possui cinco processos, sendo eles: • 5.1 – Coletar requisitos: fase de planejamento 11

Gerenciamento do Escopo

• 5.2 – Definir o espoco: fase de planejamento • 5.3 – Criar a EAP: fase de planejamento • 5.4 – Verificar o escopo: fase de controle • 5.5 – Controlar o escopo: fase de controle Esses processos interagem entre eles mesmos, assim como possuem interação com processos de outras áreas. Essas interações podem ser vistas no diagrama abaixo.

Mudanças aprovadas

Termo de abertura do peojeto

Coletar os requisitos

Controlar o escopo

Escopo do cliente

Linha de base ajustada

Definir escopo Declaração do do projeto escopo do projeto

Criar a EAP

EAP + Dicionário

Entregas

Verificar o escopo

Entregas aceitas

Imagem 2.2 http://www.mundopm.com.br/download/artigo_demo02_ed22.pdf

Referências bibliográficas

Proibida a reprodução – © UniSEB Interativo

PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos“ – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004

12

UNIDADE 3 Processo 5.1 – Coletar os Requisitos Objetivos da aula • Apresentar a forma de definição de escopo do projeto; • Ressaltar o ciclo de vida do produto e do projeto; • Exibir as formas de planejamento de processos do produto e projeto; • Delinear as informações possíveis para uma declaração de escopo; O processo de coleta de requisitos faz parte da fase de planejamento do ciclo de vida de um projeto. A coleta de requisitos é o processo de definir e documentar a funções e funcionalidades do projeto e do produto necessárias para atender às expectativas das partes interessadas.

Entender a necessidade do cliente é fundamental, portanto a coleta de requisitos torna-se um processo importante para que o projeto atenda as expectativas.

Entradas

–

1. Termo de abertura do projeto 2. Registro das partes interessadas 1. Entrevistas 2. Dinâmicas de grupo

5.1 – Coletar os requisitos

Ferramentas

–

3. Oficinas 4. Técnicas de criatividade em grupo 5. Técnicas de tomadas de decisão em grupo 6. Questinonários e pesquisa

7. Observações 8. Protótipos

Saídas

–

1. Documentação dos requisitos 2. Plano de gerenciamento dos requisitos 3. Matriz de rastreabilidade dos requisitos

Imagem 3.1.

Fonte: Autor.

É de suma importância para o sucesso do projeto que o que foi pedido, informado e combinado na coleta de informações seja bem do-

Gerenciamento do Escopo

Proibida a reprodução – © UniSEB Interativo

cumentado. Para projetos onde haja necessidade de uma formalização do trabalho a ser realizado, um documento deve ser emitido descrevendo essas informações e é recomendado que sejam coletadas assinaturas dos envolvidos para obtenção de comprometimento de todos. É preciso que na documentação do escopo constem características do produto, serviço ou resultado a ser produzido, assim como as características inerentes ao gerenciamento do projeto, como reuniões, atividades de planejamento, controle, etc.

Uma questão que dificulta a coleta de requisitos o fato de que nem sempre a pessoa ou grupo que é entrevistado sabe claramente o que quer, ou até sabe o que quer, mas não sabe como transmitir essa informação de forma clara para o entrevistado. Então se faz necessário a aplicação de técnicas de levantamento de informações, assim como validações sistemáticas feitas durante as entrevistas.

Mesmo vencida a questão destacada acima, ainda existe uma outra característica muitas vezes oculta na coleta de requisitos: a expectativa dos envolvidos pode ir muito além da real necessidade. Aí sim cabe a habilidade do gerente de projetos em estabelecer um limite entre necessário e esperado. Talvez envolvidos mais importantes ou influentes possam ser mais considerados em expectativas, ou até o projeto tem margem para que todas as expectativas sejam objetivo do projeto.

POR QUE? – Necessidade ≠ Expectativa © http://dicasgp.com.br/bloggp/wp-content/uploads/2010/05/tirinha-projetos1.jpg 14

Processo 5.1 – Coletar os Requisitos – Unidade 3

© Cory Thoman, © Cory Thoman, © Aleksandr Volodin, © Robert Wisdom | Dreamstime.com

Portanto é muito importante que se faça um bom alinhamento de expectativas, onde define-se onde o requerente gostaria de chegar com o projeto.

Cliente

GP

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Imagem 3.3

Ferramentas para coleta de requisitos Existem várias formas de se coletar os requisitos do projeto junto aos fornecedores de requisitos. Abaixo trazemos as definições do próprio PMBOK® de algumas ferramentas e técnicas que podem ser utilizadas: 1 Entrevistas: Uma entrevista é um meio formal ou informal de se descobrir informações das partes interessadas através de conversas diretas com as mesmas. Normalmente é feita através de perguntas preparadas ou espontâneas e do registro das respostas. São frequentemente conduzidas individualmente, mas podem envolver múltiplos entrevistadores e/ou entrevistados.

Entrevistar participantes experientes, partes interessadas e especialistas no assunto do projeto pode auxiliar na identificação e definição das características e funções das entregas desejadas.

2. Dinâmicas de grupo: As dinâmicas de grupo unem as partes interessadas pré-qualificadas e especialistas no assunto para aprender a respeito das suas expectativas e atitudes sobre um produto, serviço ou resultado proposto. Um moderador treinado 15

Gerenciamento do Escopo

Proibida a reprodução – © UniSEB Interativo

guia o grupo através de uma discussão interativa, planejada para ser mais informal do que uma entrevista individual.

3. Oficinas: Oficinas são sessões focadas que unem as partes interessadas multifuncionais para definir os requisitos do produto. É considerada uma técnica primária para definir rapidamente requisitos multifuncionais e de reconciliar as diferenças entre as partes interessadas. Por causa da sua natureza de grupo interativa, sessões bem dirigidas podem gerar confiança, desenvolver relações e aprimorar a comunicação entre os participantes, o que pode levar ao consenso entre as partes interessadas. Outro benefício dessa técnica é que problemas podem ser descobertos e resolvidos mais rapidamente do que em sessões individuais.

Por exemplo, oficinas chamadas de sessões de Joint Application Design (JAD) são usadas na indústria de desenvolvimento de software. Essas são focadas em unir os usuários e a equipe de desenvolvimento para aperfeiçoar o processo de desenvolvimento do software. Na indústria de manufatura, o Desdobramento da Função de Qualidade (QFD) é um exemplo de outra técnica de oficina que ajuda na determinação de características críticas para o desenvolvimento de um novo produto. A QFD começa com a coleta das necessidades do cliente, também conhecida como a Voz do Cliente (VOC). Essas necessidades são então objetivamente classificadas e priorizadas e as metas para alcançá-las são estabelecidas.

4. Técnicas de criatividade em grupo: Muitas atividades em grupo podem ser organizadas para identificar os requisitos do projeto e do produto. Algumas das técnicas de criatividade em grupo que podem ser usadas são: a) Brainstorming. Uma técnica usada para gerar e coletar múltiplas ideias relacionadas aos requisitos do projeto e do produto. b) Técnica de grupo nominal. Essa técnica amplia o brainstorming adicionando um processo de votação para ordenar as melhores ideias e as levando para um brainstorming adicional ou priorização. c) A técnica Delphi. Um seleto grupo de especialistas responde questionários e fornece comentários a respeito das respostas de cada rodada de coleta de requisitos. Para 16

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Processo 5.1 – Coletar os Requisitos – Unidade 3

manter o anonimato, as respostas só ficam disponíveis ao facilitador. d) Mapas mentais. Ideias criadas através de brainstorming individuais são consolidadas num único mapa mental que reflete a existência de atributos comuns e diferenças de entendimento, além de gerar novas ideias. e) Diagrama de afinidade. Essa técnica permite que um grande número de ideias seja organizado em grupos para revisão e análise.

5. Técnicas de tomada de decisão em grupo: A tomada de decisões em grupo é um processo de avaliação de múltiplas alternativas onde uma resolução com ações futuras é esperada.

Essas podem ser utilizadas para gerar, classificar e priorizar os requisitos do produto. Existem muitos métodos para se chegar a uma decisão em grupo, por exemplo: a. Unanimidade. Todos concordam com uma única solução. b. Maioria Suporte de mais de 50% dos membros do grupo. c. Pluralidade. O maior bloco no grupo decide, mesmo que a maioria não seja alcançada. d. Ditadura. Um indivíduo decide pelo grupo. e. Quase todos os métodos descritos previamente podem ser aplicados às técnicas de grupo usadas no processo Coletar os requisitos.

6. Questionários e Pesquisas: são conjuntos escritos de questões projetadas para acumular rapidamente informações a partir de um amplo número de entrevistados. Questionários e/ou pesquisas são mais apropriados para grandes audiências, quando uma resposta rápida é necessária e quando uma análise estatística é apropriada.

7. Observações: As observações fornecem uma maneira direta de se examinar indivíduos em seu ambiente e como desempenham o seu trabalho ou tarefas e executam processos. É particularmente útil para processos detalhados quando as pessoas que usam o produto têm dificuldade ou relutam em expressar os seus requisitos. A observação, também chamada em Inglês de “job shadowing” é normalmente feita externamente pelo observador examinando o usuário executando o seu trabalho. Também pode ser feita por um “observador participante” que de fato re17

Gerenciamento do Escopo

aliza um processo ou procedimento para experimentar como o mesmo é feito e descobrir requisitos escondidos.

8. Protótipos: Construir um protótipo é um método para se obter respostas iniciais sobre os requisitos através de um modelo funcional do produto esperado, antes de construí-lo. Já que protótipos são tangíveis, eles permitem que as partes interessadas façam experiências com um modelo do seu produto final ao invés de somente discutirem representações abstratas dos seus requisitos. Protótipos suportam o conceito de elaboração progressiva, pois são usados em ciclos iterativos de criação de modelos em tamanho natural, experimentos de usuário, geração de opiniões e revisão do protótipo. Quando suficientes ciclos de coletas de feedback forem realizados, os requisitos obtidos do mesmo estarão completos para se partir para a fase de concepção ou construção.

Proibida a reprodução – © UniSEB Interativo

Técnica SMART Utilizada para avaliar a qualidade dos requisitos a fim de sabermos se os mesmos possuem certas características que são essenciais para uma boa definição do escopo. Essas características são: • Específico (Specific): os requisitos devem ser os mais claros possíveis, sem ambiguidades e sem possibilidade de interpretação ambígua (dupla); • Mensurável (Measurable): deve-se haver uma forma de medir se o requisito possibilidade de atingimento, ou seja, se o mesmo pode ou não ser alcançado segundo a regras mais diversas desde a possibilidade física ou química, até as possibilidades em relação as regras legais, da organização executora, do cliente, etc.; • Atingível (Attainable): possível de realizar segundo as regras do projeto, do departamento, da organização, da legislação, leis da física, etc.

• Relevante (Relevant): avaliação se os requisitos fazem sentido em relação aos objetivos do projeto. “O ótimo é inimigo do bom”, então, deve-se focar em requisitos que realmente contribuirão para o resultado esperado do projeto e satisfazendo as necessidades das partes interessadas; • Com prazo (Time-bound): Requisitos sem prazo definido ficam perdidos no tempo e não temos como acompanhá-los a fim de 18

Processo 5.1 – Coletar os Requisitos – Unidade 3

garantir o bom andamento das atividades relacionadas e nem sabermos se tudo está caminhando para a entrega do projeto.

Por isto é importante que os requisitos tenham um referencial de tempo que será utilizado no planejamento das atividades.

No exemplo abaixo temos a descrição de um requisito onde, no fim do quadro, temos espaço para a marcação dos critérios da técnica SMART. RQ1 Emissão de nota fiscal eletrônica O sistema deverá ser capaz de emitir a NFe, gerando tanto o PDF da DANFE, quanto o XML, que deverão ser enviados automaticamente para o e-mail cadastrado no cliente em questão.

Responsável: Kadu Anastácio Solicitante: José das Couves S M A R T

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

10 Dicas para Coleta de Requisitos 1. Use questionários para coletar os requisitos. Gere perguntas sobre os aspectos do projeto, de forma a conseguir das partes interessadas a maior quantidade de informações possíveis. As perguntas devem começar com aspectos gerais e abordar mais e mais detalhes ao decorrer do questionário. Esta forma de coleta é muito boa para partes interessadas que não têm muita disponibilidade para reuniões ou estão em ambientes virtuais; 2. Colete requisitos para o escopo do projeto. O escopo do projeto é o que o projeto precisa/almeja realizar.

Alguns exemplos: Projeto A – Otimização do setor financeiro, Projeto B – Curso de Elaboração de Projetos.

Seu patrocinador e partes interessadas internas são os alvos nesta etapa; 3. Colete requisitos para o escopo do produto. O escopo do produto é o que o projeto vai entregar ao cliente ao final da sua duração. Exemplos: Projeto A – Processos Financeiros otimizados, Projeto B – Planos de Curso, Apostila de Elaboração de Projetos. Seu cliente e o usuário final são os alvos desta vez; 4. Elabore uma matriz de rastreabilidade de requisitos.

Nesta tabela você deve associar os requisitos às partes interessadas, recursos, atividades, entregas, pacotes 19

Gerenciamento do Escopo

Proibida a reprodução – © UniSEB Interativo

de trabalho e quaisquer outras informações que você achar pertinentes, de forma a facilitar o acompanhamento e assegurar que os requisitos estão sendo observados, respeitados e cumpridos; 5. Leve em consideração que os requisitos mais importantes podem não vir dos stakeholders mais importantes. Em um exemplo bruto, o faxineiro do prédio pode saber de uma coisa que nenhum dos membros da diretoria sabe. Procure sempre ao menos perguntar aos stakeholders de menor impacto ou não diretamente envolvidos sua percepção do projeto (mesmo que de uma forma que não revele que se trata de fato de uma coleta de requisitos).

6. Round 1… Fight! Se em algum momento, dois ou mais stakeholders decidirem que é um bom momento para brigar sobre requisitos e isso atrapalhar as reuniões, não tenha medo de encerrar a reunião e utilizar a técnica Delphi para chegar a uma decisão comum sem sacrificar as reuniões de planejamento.

7. Jogos de Poder. Existem situações onde a parte interessada A passa requisitos, mas é a parte interessada B quem tem poder de decisão para aprovar se o requisito entra ou não no projeto. Defina bem cedo uma matriz de priorização de partes interessadas, de forma a identificar quem tem prioridade sobre quem, bem como elabore o mais cedo possível um plano de gerenciamento de requisitos onde deve constar o processo a ser adotado quando um requisito crítico é identificado por uma parte interessada de menor importância. Se valer de opiniões especializadas nessa hora é sempre uma boa ideia; 8. Escreveu não leu… Exercite a técnica da retroalimentação no processo de comunicação para validar os requisitos. Inclua no seu plano de gerenciamento de comunicações o processo de que sempre que um pacote de trabalho estiver para ser iniciado ou concluído, o processo de comunicação deve revisar os requisitos com as partes interessadas envolvidas e com o clien20

Processo 5.1 – Coletar os Requisitos – Unidade 3

te/usuário final. Desta forma, requisitos que não estão aderentes com o objetivo e o escopo podem ser identificados a tempo.

9. Informal. Muitos requisitos não podem ser coletados dentro do ambiente formal de trabalho. Marque um almoço com algumas partes interessadas e converse sobre o projeto de maneira aberta e despretensiosa.

Muito da visão daquela parte interessada vai surgir desta forma e você vai poder conferir se os requisitos estão batendo.

10. Pesquisa! Recorra aos famosos ativos de processos organizacionais! Dependendo do nível de maturidade da empresa, lá você pode encontrar não só as lições aprendidas geradas para projetos anteriores como uma base de dados de requisitos… Ou um PMO que possa lhe informar onde encontrar essa informação… Ou um grupo de gerentes de projetos que podem lhe dar uma dica… Ou um punhado de técnicos que trabalharam em um projeto parecido… Ou nada. Mas procure lá!

(Revista Papo GP - http://papogp.com/2011/08/03/10dicas-para-coleta-de-requisitos/)

Referências bibliográficas

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos“ – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004 FRANCISCO, Egildo, Filho. Entrevistas - técnicas & dinâmicas de grupo: para não-especialistas. Qualitymark.

21

Proibida a reprodução – © UniSEB Interativo

Gerenciamento do Escopo

22

UNIDADE 4 Processo 5.2 – Definir o Escopo Objetivos da aula • Definir a forma de criação de uma EAP; • Apresentar técnicas de decomposição do escopo; • Definir componentes da EAP; • Apresentar o dicionário da EAP; É o processo de desenvolvimento de uma descrição detalhada do projeto e do produto. A preparação detalhada da declaração do escopo é crítica para o sucesso e baseia-se nas entregas principais, premissas e restrições que são documentadas durante a iniciação do projeto.

1. Termo de abertura do projeto

Entradas

–

2. Documentação dos requisitos 3. Ativos de processos organizacionais

1. Opinião especializada

5.2 – Definir o escopo

Ferramentas

Saídas

–

–

2. Análise de produto

3. Identificação de alternativas 4. Oficinas

1. Declaraçao do escopo do projeto 2. Atualização dos documentos do projeto

Imagem 4.1 Fonte: Autor.

Ciclo de vida do produto Como um primeiro passo, obter uma visão do ciclo de vida do produto, serviço ou resultado a ser obtido pelo projeto é crucial para uma visão mais abrangente do mesmo. Um exemplo de um ciclo de vida clássico

Gerenciamento do Escopo

é este: definir, desenhar, instalar, manter e então encerrar. Para o conhecimento deste ciclo de vida, pesquisas em projetos da mesma natureza já realizados é de grande valia, assim como entrevistas e técnicas de grupo com especialistas que já participaram de algum projeto em afim.

Identificação de processos Após a identificação do ciclo de vida, é de extrema importância que se identifique os processos que estão inclusos no escopo e quais estarão fora. Além dos processo do produto e do projeto, podem existir processos que estão fora do escopo, mas impactarão no resultado final, como atividades de suprimentos, fiscais, TI, etc. Existem ainda processos também não inclusos no escopo, mas que o cliente deverá executar para o bom andamento do projeto. Procure especificar sempre todos esses tipos de projeto para ter um escopo melhor definido.

Superposições do escopo Descubra como outros projetos, planejados ou em execução, podem impactar o seu projeto. Designe alguém como representante do seu projeto nestes outros projetos para que você possa coordenar seus esforços.

Declaração do escopo O objetivo da declaração de escopo é descrever de forma detalhada as entregas do projeto e o trabalho que será aplicado para produzir essas entregas. Além disso, um documento que descreve essas informações do projeto serve como um entendimento comum do escopo do projeto para todos os envolvidos. Outro papel importante da declaração do escopo é que ela serve de base para todas as outras áreas de processos do PMBoK®, ou seja, um escopo mal descrito afetará todas outras atividades de planejamento e, consequentemente, da execução, controle e finalização.

Proibida a reprodução – © UniSEB Interativo

Conteúdo de uma declaração do escopo Uma sugestão de conteúdo para uma declaração de escopo é: • Objetivos do projeto: descreve os fatores para os quais o projeto foi criado, ou seja, onde a organização quer chegar com o mesmo; • Descrição do escopo do produto: é uma versão preliminar da descrição do produto, serviço ou resultado a ser alcançado pelo projeto. Algumas vezes, durante todo o processo de planeja24

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Processo 5.2 – Definir o Escopo – Unidade 4

mento do projeto, são obtidos mais detalhes acerca do escopo do produto, que devem sempre serem acrescentados a este documento; • Requisitos do projeto: descreve quais as necessidades declaradas para o gerenciamento do projeto, ou seja, quais atividades de iniciação, planejamento, controle, execução e finalização deverão ser executadas.

• Limites do projeto: estabelece alguns limites de tempo, custo, qualidade, etc.

• Entregas do projeto: quais serão as entregas programadas para o projeto; • Critérios de aceitação de produtos: quais serão os critérios para que seja feita uma validação das entregas para avaliarmos se as mesmas estão condizentes com o especificado; • Restrições do projeto: aplica regras que limitam a atividade da equipe do projeto, de forma a atender alguma exigência do cliente, legislação, organização, etc.; • Premissas do projeto: são os aspectos em que a equipe do projeto assume como necessários para que possam executar seu trabalho; • Organização inicial do projeto: como estará estruturada a equipe do projeto, assim como podemos mencionar as funções e responsabilidades das pessoas no mesmo; • Riscos iniciais definidos: definição superficial dos riscos sem muita necessidade de aprofundamento; • Marcos do cronograma: quais serão os grandes marcos do projeto que já podem ser pré-estabelecidos neste momento; • Limitação de fundos: são os limites de orçamentos pré-estabelecidos para o projeto; • Estimativa de custos: estimativa macro dos custos para o projeto; • Requisitos do gerenciamento de configuração do projeto: como estarão estruturados os arquivos e artefatos do projetos, assim como a forma de organização das linhas de base, controle de alterações e comparativos; • Especificações do projeto: quaisquer especificações acerca do projeto a ser executado, e não do produto e nem do gerenciamento do projeto; 25

Gerenciamento do Escopo

• Requisitos de aprovação: quais serão as itens a serem validados para a aprovação final do projeto;

Referências bibliográficas PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos“ – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004

Proibida a reprodução – © UniSEB Interativo

PMI, Project Management Institute Practice Standard for Work Breakdown Structures - 2006

26

UNIDADE 5 Processo 5.3 – Criar a EAP Objetivos da aula • Apresentar o processo de verificação do escopo; • Conceituar os critérios de aceitação de requisitos; • Definir a matriz de rastreabilidade de requisitos; • Exibir as formas de verificação e inspeção; • Interligar os processos de mudanças e ocorrências de qualidade.

O entendimento do escopo do projeto através apenas de uma descrição das características do produto, serviço ou resultado, comumente não auxilia muito na obtenção de uma visão mais clara das entregas de um projeto. Consequentemente, nas várias atividades de gerenciamento do projeto que se baseiam no escopo, temos possíveis problemas tanto no planejamento, quanto no controle, execução e finalização. Portanto, se faz de grande valia uma de composição das entregas do projeto de forma a obtermos uma subdivisão do escopo em itens menores, facilitando o planejamento. A cada nível maior de detalhe, temos uma definição mais refinada das subdivisões do nível superior. Aí entra uma questão importante que é a decisão de até onde deve ir o nível de detalhe, onde recomendamos que vá até onde a equipe deseja controlar, desde que com custos viáveis (tempo, custos financeiros, lógicos, etc.).

Gerenciamento do Escopo

1. Declaração do escopo do projeto

Entradas

2. Documentação dos requisitos

–

3. Ativos de processos organizacionais

Ferramentas

5.3 – Criar a EAP

–

1. Decomposição

1. EAP

Saídas

2. Dicionário de EAP

–

3. Linha base do escopo 4. Atualização dos documentos do projeto

Imagem 5.1 Fonte: Autor

EAP (ou WBS) Uma Estrutura analítica de projetos (EAP), do Inglês, work breakdown structure (WBS) é uma ferramenta de decomposição do trabalho do projeto em partes menores, representados através de uma árvore, com suas hierarquias que representam as entregas do projeto.

Exemplo de uma EAP de um projeto de construção de uma bicicleta artesanal: Quadro

–

Estrutura metálica Furações Pintura Mesa Estrutura de fibra de carbono

Produto

Bicicleta

Guidon –

Manetes

– Manoplas

Acessórios

Sistema de freios

–

–

Computador de bordo Luz de sinalização

Canaletas Cabos de aço Discos Tambor Pastilhas

Etc

Proibida a reprodução – © UniSEB Interativo

Iniciação

Tempo de abertura do projeto

– Identificar partes interessadas

Plano de projeto

Gerenciamento do Projeto

–

Planejamento

Plano de gerenciamento do escopo Plano de gerenciamento do tempo

– Plano de gerenciamento dos custos

Plano de gerenciamento da qualidade ...

...

Imagem 5.2 Fonte: Autor.

28

Processo 5.3 – Criar a EAP – Unidade 5

Entregas (deliverables) Dentro de uma EAP, todos os nós existentes na mesma tratam-se de entregas do projeto. Alguns desses entregas estão subdivididos em outros itens filhos, mas tanto os pais quanto os filhos são entregas.

Um exemplo está na imagem abaixo: Quadro

–

Estrutura metálica Furações

Todos os nós são entregáveis

Pintura Mesa Estrutura de fibra de carbono

Produto

Bicicleta

Guidon –

Manetes

– Manoplas

Acessórios

Sistema de freios

–

–

Computador de bordo Luz de sinalização

Canaletas Cabos de aço Discos Tambor Pastilhas

Etc

Iniciação

Tempo de abertura do projeto

– Identificar partes interessadas

Plano de projeto

Gerenciamento do Projeto

–

Planejamento

Plano de gerenciamento do escopo Plano de gerenciamento do tempo

– Plano de gerenciamento dos custos

Plano de gerenciamento da qualidade ...

...

Imagem 5.3.

Fonte: Autor.

Pacotes de trabalho Já os pacotes de trabalho de uma EAP são somente o último nível decomposto da EAP, ou seja, se uma entrega possui filhos, ele não é um pacote de trabalho. Somente as entregas finais, que não possuem filhos, são pacotes de trabalho do projeto.

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Um exemplo está na imagem a seguir:

29

Gerenciamento do Escopo

Quadro

–

Estrutura metálica Furações Pintura Mesa Estrutura de fibra de carbono

Produto

Bicicleta

Guidon –

Último nível dos entrgáveis

Manetes

– Manoplas

Acessórios

Sistema de freios

–

Computador de bordo Luz de sinalização

–

Canaletas Cabos de aço Discos Tambor Pastilhas

Etc

Iniciação

Tempo de abertura do projeto

– Identificar partes interessadas

Plano de projeto

Gerenciamento do Projeto

–

Planejamento

Plano de gerenciamento do escopo Plano de gerenciamento do tempo – Plano de gerenciamento dos custos Plano de gerenciamento da qualidade ...

...

Imagem 5.4 Fonte:Autor.

Passos sugeridos para a criação de uma EAP Recomendaremos alguns passos para a criação de uma EAP para facilitar o entendimento e a realização dessa atividade: 1. Escreva o nome do projeto no primeiro nível da EAP Nome do Projeto 2. Iniciar o segundo nível com duas divisões padrões, sendo elas: gerenciamento do projeto e produto Nome do Projeto Gerenciamento do projeto

Produto

Proibida a reprodução – © UniSEB Interativo

3. Acrescentar as fases do processo de gerenciamento de projetos

30

Processo 5.3 – Criar a EAP – Unidade 5

Nome do Projeto Gerenciamento do projeto –

Produto

Iniciação Planejamento Controle Execução Finalização

4. Acrescentar as fases do ciclo de vida do produto Nome do Projeto Gerenciamento do projeto

Produto

–

–

Iniciação

Desenho

Planejamento

Protótipo

Controle

Produção

Execução

Homologação

Finalização

Liberação

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Suporte

31

Gerenciamento do Escopo

5. Decompor as entregas do gerenciamento do projeto dentro das fases abertas Nome do Projeto Gerenciamento do projeto

Produto

–

–

Iniciação –

Project Charter

Protótipo

Partes Interessadas

Produção

Planejamento –

Plano de gerenciamento do Escopo Plano de gerenciamento do Tempo Plano de gerenciamento de custos Plano de gerenciamento das Qualidades Plano de gerenciamento das Comunicações Plano de gerenciamento do RH Plano de gerenciamento dos Riscos Plano de gerenciamento das Aquisições Plano de gerenciamento do Projeto

Controle –

...

Execução –

...

Finalização

Proibida a reprodução – © UniSEB Interativo

–

32

Desenho

...

Homologação Liberação Suporte

Processo 5.3 – Criar a EAP – Unidade 5

6. Decompor as entregas do produto em subprodutos que os compõem.

Nome do Projeto Gerenciamento do projeto

Produto

–

–

Iniciação –

Desenho –

Project Charter

Validar o projeto estrutural

Partes Interessadas

Planejamento –

Protótipo –

Plano de gerenciamento do Escopo

Plano de gerenciamento das Qualidades Plano de gerenciamento das Comunicações

Aprovar Maquete

Produção –

Furações

Plano de gerenciamento dos Riscos

Pintura

Plano de gerenciamento das Aquisições

Controle –

–

...

Finalização

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

–

Embalagem

Homologação –

...

Execução

...

Corte dos Materiais Solda dos Materiais

Plano de gerenciamento do RH

Plano de gerenciamento do Projeto

Criar Maquete Adaptar Maquete

Plano de gerenciamento do Tempo Plano de gerenciamento de custos

Realizar o projeto estrutural

Testes com Colaboradores Testes com Clientes

Liberação –

Liberar o produto para Venda

Suporte –

Dar suporte a área Comercial Dar suporte aos Clientes

7. Revisar continuamente a EAP Dicionário da EAP Segundo o PMBOK® 4ª edição: “O dicionário da EAP é um documento que fornece descrições mais detalhadas dos componentes da EAP, 33

Gerenciamento do Escopo

inclusive dos pacotes de trabalho e outras entregas”. As informações incluem, mas não estão limitadas a: • Código de identificador da conta; • Descrição do trabalho; • Organização responsável pela execução; • Lista de marcos do cronograma; • Atividades do cronograma associadas; • Recursos necessários; • Estimativa de custos; • Requisitos de qualidade; • Critérios de aceitação; • Referências técnicas; • Informações do contrato; • Fornecedor das informações.

Um exemplo de dicionário da EAP está a seguir: ID 1

1.1

1.1.1

1.1.2

Proibida a reprodução – © UniSEB Interativo

1.2

Pacote de Trabalho Descrição Gerenciamento de Documentos e Áreas de Projetos Conhecimento necessárias para o gerenciamento do projeto.

Gerenciamento de Documentos que auxiliam o Integração do Projeto controle e acompanhamento do projeto.

Critério de Aceitação Verificar se todos os pacotes de trabalho foram entregues em conformidade.

Verificar se todos os pacotes de trabalho foram entregues em conformidade.

Termo de Abertura Documentos que contempla Aceite dos Sponsors o escopo macro, marcos, do projeto. restrições e premissas do projeto.

Plano de Gerencia- Documento que descreve Aceite dos Sponsors mento do Projeto como as áreas de conheci- do projeto. mento devem ser integradas.

Gerenciamento de Documentos necessários Verificar se todos os Escopo do Projeto para o Gerenciamento do pacotes de trabalho Escopo do projeto. foram entregues em conformidade.

Tabela.

Fonte: Autor

34

Processo 5.3 – Criar a EAP – Unidade 5

© JAMES STEIDL | DREAMSTIME.COM

Os dez mandamentos da EAP

Segundo Carlos Magno Xavier (XAVIER, Carlos Magno da Silva. Gerenciamento de projetos: como definir e controlar o escopo do projeto. São Paulo: Saraiva, 2009. 2ª ed.)

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

I – Cobiçarás a WBS do próximo: Aprender com o passado é uma habilidade importante do gerente de projetos. Antes de iniciar a elaboração da WBS do seu projeto, verifique como foi estruturado o escopo de projetos semelhantes. Consulte outros projetos da empresa, veja a literatura e converse com outros profissionais de gerenciamento que atuaram em projetos que tiveram como objetivo a geração de produtos e serviços similares.

II - Explicitarás todos os subprodutos, inclusive os necessários ao gerenciamento do projeto: O subproduto que não estiver na WBS não faz parte do escopo do projeto. Assim, não deixe nenhum de fora. Se durante a execução do projeto, algum membro estiver trabalhando em uma atividade que não esteja contribuindo para algum subproduto da WBS, ele estará trabalhando fora do escopo do projeto. Se esse trabalho for necessário ao projeto, devem ser utilizados os procedimentos para a sua inclusão no escopo, referentes ao controle de alterações do escopo. É importante lembrar que o conceito de subproduto do projeto também inclui os serviços (Ex.: teste, alinhamento, treinamen35

Gerenciamento do Escopo

to, instalação etc.). O importante é que, tanto os produtos como os serviços, sejam tangíveis e verificáveis. A WBS não deve conter insumos / recursos físicos a serem utilizados na geração dos subprodutos. Os custos de viagens, material, pessoal e outros insumos devem ser alocados ao elemento da WBS para o qual eles contribuem. Devemos verificar se os subprodutos necessários ao gerenciamento do projeto foram acrescentados à WBS. III - Não usarás os nomes em vão: Não devem ser utilizados nomes vagos para os elementos da WBS, que gerem dúvidas semânticas acerca de que subproduto está sendo representado.

Utilize substantivos para representar os produtos e serviços.

Não indique o processo de geração dos mesmos, mas sim o resultado desse processo. Desta forma, ao invés de “Testar o equipamento” (um serviço), utilize “Teste do equipamento”; ao invés de “Elaborar o Manual do Equipamento”, utilize “Manual do Equipamento”.

IV – Guardarás a descrição dos pacotes de trabalho no Dicionário da WBS: Os pacotes de trabalho devem ser claramente definidos no dicionário da WBS para que fique bem explícito o trabalho a ser realizado. O “Dicionário da WBS” é o documento que define e / ou descreve o trabalho a ser realizado em cada pacote de trabalho da WBS.

Proibida a reprodução – © UniSEB Interativo

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: O planejamento e controle incluem: escopo (verificação e controle de mudanças); tempo (definição das atividades); custo (planejamento de recursos, estimativa de custo e orçamento); e risco (planejamento do risco).

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: Planejar e controlar tem o seu custo / tempo necessário a esse trabalho. Assim, decomponha de acordo com a sua necessidade no projeto. Como exemplo, não adianta decompor 36

Processo 5.3 – Criar a EAP – Unidade 5

o escopo em subprodutos que durem 1 hora para serem gerados se o controle será realizado semanalmente. Por outro lado, foi citado anteriormente que os fatores “riscos” e “custos” associados são determinantes do rigor a ser aplicado nos controles.

Desta forma, caso um projeto tenha deliverables com altos níveis de incerteza (que implicam em altos riscos) e custos elevados, os controles necessários demandarão uma decomposição extremamente detalhada. Como exemplo, a WBS de um projeto de construção de um veículo lançador de satélites (que custa algumas centenas de milhões de dólares) será muito mais detalhada do que a WBS da construção de uma casa pré-fabricada de 2 quartos (que custa alguns milhares de reais).

VII – Honrarás o pai: Cada elemento da WBS deve ser um componente do subproduto do elemento pai ao qual está subordinado. Verifique se os elementos filhos na WBS são realmente componentes dos elementos pais. Por exemplo, o fato de um treinamento depender de um manual do equipamento ter sido disponibilizado não quer dizer que faça parte do treinamento a elaboração do manual.

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

VIII – Decomporás de forma que a soma dos subprodutos dos elementos componentes (filhos) corresponda ao subproduto do elemento pai (Mandamento dos 100%): Ao decompor um subproduto, nenhuma parte dele deve ser esquecida. Lembrese que a soma dos subprodutos componentes deve ser equivalente ao subproduto que foi decomposto. Por exemplo ao decompor um Estudo de Viabilidade da fase de Concepção, não poderíamos esquecer do Relatório conclusivo do estudo.

IX - Não decomporás em somente um subproduto: Um elemento da WBS não deve ter somente um componente (filho).

De acordo com o mandamento anterior, se um elemento tem somente um componente, ele é igual ao pai. Se for, porque representá-lo duas vezes? Quando isso ocorrer, verifique se, na realidade, não esqueceu de algum componente. Caso não tenha esquecido, é desnecessária a representação do elemento filho.

37

X – Não repetirás o mesmo elemento como componente de mais de um subproduto: Não podemos ter um elemento como (filho) componente de mais um subproduto (pai).

Por exemplo, se para ministrarmos dois treinamentos utilizarmos a mesma apostila, não devemos colocá-la como subproduto dos dois treinamentos a elaboração da mesma. É importante ressaltar que podemos ter elementos com o mesmo nome compondo subprodutos diferentes, mas cada um com um significado diferente.

Referências bibliográficas PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos“ – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004

Proibida a reprodução – © UniSEB Interativo

Xavier, Carlos Magno da Silva – “Gerência de Projetos - Como definir e controlar o escopo do projeto”. Editora Saraiva – 2005

38

UNIDADE 6 Processo 5.4 – Verificar o Escopo Objetivos da aula • Apresentar o processo de controle do escopo do projeto; • Explicar o processo de análise de variação; • Realizar todo o processo de análise de valor agregado (EVA). É o processo de checagem para a aceitação das entregas finalizadas do projeto. É comum que revisões sejam feitas com os clientes (internos ou externos) e também com o patrocinador, mas também devemos sempre atentar em formalizar esses aceites.

1. Plano de gerenciamento do projeto

Entradas

2. Documentação dos requisitos

–

3. Matriz de rastreabilidade dos requisitos 4. Entregas validadas

5.4 – Verificar o escopo

Ferramentas

–

1. Inspeção

1. Entregas aceitas

Saídas

–

2. Solicitação de mudanças 3. Atualização dos documentos do projeto

Imagem 6.1 Fonte: Autor.

Critérios de aceitação Durante o planejamento de escopo são definidos os critérios de aceitação para as entregas do produto e do projeto. A verificação do escopo se baseia nesses critérios para determinar se as entregas liberadas estão de acordo com o solicitado ou não.

Gerenciamento do Escopo

Matriz de rastreabilidade de requisitos

RQ4 – Nome do Requisito

RQ5 – Nome do Requisito

RQ6 – Nome do Requisito

RQ7 – Nome do Requisito

RQ8 – Nome do Requisito

RQ9 – Nome do Requisito

RQ10 – Nome do Requisito

RQ11 – Nome do Requisito

RQ12 – Nome do Requisito

RQ13 – Nome do Requisito

RQ14 – Nome do Requisito

RQ15 – Nome do Requisito

c x c c c x c x x c x c x x

RQ3 – Nome do Requisito

RQ1 – Nome do Requisito RQ2 – Nome do Requisito RQ3 – Nome do Requisito RQ4 – Nome do Requisito RQ5 – Nome do Requisito RQ6 – Nome do Requisito RQ7 – Nome do Requisito RQ8 – Nome do Requisito RQ9 – Nome do Requisito RQ10 – Nome do Requisito RQ11 – Nome do Requisito RQ12 – Nome do Requisito RQ13 – Nome do Requisito RQ14 – Nome do Requisito RQ15 – Nome do Requisito

RQ2 – Nome do Requisito

Rastreabilidade dos Requisitos

RQ1 – Nome do Requisito

A matriz de rastreabilidade cruza os requisitos com outras informações que podem ser em relação as suas origens, ou até em quais funcionalidades afetadas ou criadas por estes requisitos. A ideia principal é sabermos se, mediante a estímulos em determinadas informações, o que isto pode afetar o projeto. Por exemplo: se a exclusão de um requisito pode afetar outros requisitos.

x

x x

x x x

c c x c

c c x c x

x c c c c c

x c c x c c c

c c x c x x x x

x c x c c c c c x

x c c c c c x x c x

x x c c c c x x c x c

c c c x x x c x x c c x

c c c x x x c x x x x c x

c x c x x x c x x x c x c x

c c c x x x c c x c c c x

c c c x c x c x x c c x

c x x x c c c x x x c

c x x x c c c c c x

c x x x c c c c c

c c c c c x x c

c c x x x x x

x x x x x c

x c c x x

x x x c

x x x

x x

x

C = Complementares x = conflitantes

Imagem 6.2 Fonte: Autor.

Check-lists de inspeção

Proibida a reprodução – © UniSEB Interativo

Para a verificação do escopo através dos critérios de verificação, são geralmente utilizados os check-lists de inspeção, onde os mesmos são aplicados como forma de validar esses critérios para o aceite da entrega.

40

Processo 5.4 – Verificar o Escopo – Unidade 6

Exemplo de um check-list de inspeção: Projeto:

Construção da bicicleta artesanal de 100 anos de empresa

Preparado por: Aprovado por:

kadu Chaves Anastácio José das Couves

Versão: Data:

3 14/07/2013

Conforme

Não Conf.

WBS

Entregável

Verificação

1.1.1

Quadro

Teste de resistência deve suportar pressão de 290 kg

Observações

1.1.2

Sistema de Freios

Teste de frenagem de 50 km/h em 6 segundos

X

1.1.2

Sistema de Freios

Frenagem com sujeira e água no sistema deve reduzir, no máximo, 15% de eficiência do sistema

O teste apresentou, em média, frenagem de 8 segundos

X

A frenagem teve uma redução de 30% no resultado

1.1.2

Sistema de Freios

Teste em uma temperatura de 45 graus deve reduzir, no máximo, 5% de eficiência do sistema

X

X

...

Imagem 6.3 Fonte: Autor

Entregas aceitas De acordo com os critérios de aceitação definidos no escopo do projeto, as entregas são ou não formalmente aceitas, onde deve-se documentar este aceite através de um documento que será assinado pelos responsáveis pela validação (cliente, patrocinador, etc.).

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Solicitações de mudança Caso algumas das entregas não forem aceitas, e o que se deseja é algo diferente do planejado no projeto, é comum que sejam abertas solicitações de mudança para tratar essas diferenças. Este processo de mudanças será melhor detalhado mais a frente.

Ocorrências de qualidade Durante as validações das entregas, caso as mesmas não estejam de acordo com os critérios de aceitação, deve-se abrir uma ocorrência de qualidade para que seja tomada a ação necessária para a correção desta questão. Para esta ação será determinado um ou mais responsáveis assim como o prazo para a realização.

41

Gerenciamento do Escopo

Momentos para a validação do escopo O escopo de um projeto, tecnicamente, pode ser validado a qualquer momento. Mas é mais comum que sejam realizadas validações nos seguintes momentos: • Na entrega dos principais produtos finais dentro do projeto.

• No final de fase do projeto.

• No final do projeto.

Referências bibliográficas PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos” – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004

Proibida a reprodução – © UniSEB Interativo

Xavier, Carlos Magno da Silva – “Gerência de Projetos - Como definir e controlar o escopo do projeto”. Editora Saraiva – 2005

42

UNIDADE 7 Processo 5.5 – Controlar o Escopo Objetivos da aula • Apresentar os aspectos mais relevantes das mudanças em relação ao escopo do projeto; • Elencar as origens mais comuns de mudanças; • Visualizar o custo das mudanças em relação a fase do projeto; • Exibir um processo simplificado e outro mais complexo de mudanças; • Conceituar linha base do projeto e do escopo; • Conceituar um sistema de gerenciamento da configuração. É o processo, que se baseia geralmente nas informações coletadas na validação do escopo e as compara com os planejamentos realizados a fim de identificar a saúde do escopo do projeto, se o mesmo está sendo cumprido e até em que grau isto está ocorrendo. Além disso, o controle do escopo deve assegurar que o gerenciamento das mudanças foi feito corretamente na linha de base do escopo.

1. Plano de gerenciamento do projeto 2. Informações sobre desempenho do trabalho

Entradas

–

3. Documentação dos requisitos 4. Matriz de rastreabilidade dos requisitos 5. Ativos de processos organizacionais

5.3 – Controlar o escopo

Ferramentas

–

1. Análise da variação

1. Mediação de desempenho do trabalho 2. Atualização dos ativos de processos organizacionais

Saídas

–

3. Solicitações de mudanças 4. Atualização do plano de gerenciamento do projetos 5. Atualizações dos documentos do projeto

Imagem 7.1: Fonte: Autor

Gerenciamento do Escopo

Análise da Variação Técnicas que auxiliam a determinar a magnitude de modificações, suas causas e ações corretivas. Com a análise de variação podemos fazer comparações, por exemplo, entre a última linha base registrada antes da mudança e a linha base traçada depois de realizado o replanejamento da mudança.

Análise de Valor Agregado (Earned Value Analysis ou EVA) Uma das formas de realizar uma análise de variação é através da Análise de Valor Agregado (Earned Value Analysis ou EVA). Abaixo seus principais indicadores e suas respectivas formas de cálculo.

• Valor Planejado (VP): deveria ser gasto, considerando o custo de linha da base; • Valor Agregado (VA): deveria ser gasto, considerando o trabalho já realizado; • Custo Real (CR): para o trabalho já realizado até a data atual; • Orçamento original (BAC): Budget at Completion do projeto; • Variação ▪▪ Variação de Custo (VC): VA – CR; ▪▪ Variação de Prazo (VPr): VA – VP. • Índices de Desempenho ▪▪ Índice de Desempenho de Prazo (IDP): VA / VP; ▪▪ Índice de Desempenho de Custo (IDC): VA / CR; ▪▪ To complete Performance Index (TCPI): (BAC – VA) / (BAC – CR).

Análise dos indicadores: VPr e VC

Proibida a reprodução – © UniSEB Interativo

VPr VC

>0 =0 Adiantado No cronograma Abaixo do orçamento No orçamento

<0 Atrasado Acima do orçamento

Análise dos indicadores: IDP IDC

44

>1 =1 Adiantado No cronograma Abaixo do orçamento No orçamento

<1 Atrasado Acima do orçamento

Processo 5.5 – Controlar o Escopo– Unidade 7

Indicadores IDP IDC TCPI BAC/IDC BAC-(BAC / IDC) (BAC-VA) / IDC

Questões % do Projeto atrasado (-) ou adiantado (+) % acima (-) ou abaixo (+) do orçamento para que o trabalho seja concluído na data Com qual eficiência devemos usar os recursos restantes? Eficiência que deve ser alcançada para que o projeto termine na data especificada Quanto o projeto provavelmente custará?

Estamos acima ou abaixo do orçamento?

Quanto custará o trabalho restante?

Exemplo de uma EVA: Orçamento original (BAC): 1.000.000,00 Valor Planejado (VP): 550.000,00 Trabalho Realizado: 60% Valor Agregado (VA): 600.000,00 Custo Real (CR): 800.000,00 Variação de Custo (VC): – 200.000,00 Variação de Prazo (VPr) 50.000,00 Índice de Desempenho de Prazo (IDP) 1,09 Adiantado Índice de Desempenho de Custo (IDC) 0,75 Acima do Orçamento To complete Performance Index (TCPI) 2,00 Recursos restantes devem ser utilizados com o dobro do esforço

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Referências bibliográficas PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos” – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004 VARGAS, Ricardo Viana. Gerenciamento de Projetos Utilizando Análise de Valor Agregado (EVMS). Brasport, 5ª Edição

45

Proibida a reprodução – © UniSEB Interativo

Gerenciamento do Escopo

46

UNIDADE 8 Mudanças Objetivos da aula • Definir um processo de mudanças dentro da gestão de um projeto;

wikipidia

Constantemente nos deparamos com situações de mudança de planejamentos já realizados. Essas necessidades de mudanças podem ocorrer durante qualquer fase do projeto, desde a fase de iniciação até a fase de finalizaço.

“A única coisa que nunca muda é que tudo está sempre mudando” Heráclito de Éfeso

Heráclito de Éfeso

É importante a abertura para qualquer parte interessada solicitar mudanças no escopo do projeto, mas é mais importante ainda que, apesar de iniciadas formal ou verbalmente, devam ser tratadas a fim de considerarmos se devem ou não ser levadas adiante.

Origens mais comuns das mudanças Algumas das origens mais comuns de mudanças são: • Deficiente definição do escopo; • Mudanças no negócio; • Requisições formais do cliente; • Requisições informais do cliente; • Entusiasmo da equipe;

Gerenciamento do Escopo

• Requisitos esperados (implícitos); • Mudanças em legislação; • Novas informações sobre o produto; • Iniciativas de concorrentes; • Quebras de contratos com fornecedores.

O custo da mudança de escopo

O custo da mudança de escopo Requisitos

1 1 5 10 20 50 200

Design

5

Implementação

10

Testes de componente

20 50 200

Testes de aceitação Manutenção

Imagem: http://projetoseti.com.br/gestao/gerencia-de-projetos-pmp/ gp-escopo/monitoramento-e-controle-controlar-o-escopo/

Proibida a reprodução – © UniSEB Interativo

Processo de controle de mudanças Para que os envolvidos do projeto tenham o controle dessas mudanças e também para que tudo possa ser ajustado de forma que o projeto alcance o resultado esperado após essa situação de mudança, é necessário que exista um processo definido para que as mesmas ocorram de forma controlada.

Por esse motivo, define-se um processo de gestão integrada de mudanças, que é tratado pela área de processo de integração. Na nossa abordagem, iremos focar nas mudanças de escopo, que são um tipo muito comum em projetos e também pelo fato de geralmente se desdobrarem em uma reavaliação e muitas vezes em um replanejamento também das outras áreas de processos.

48

Mudanças– Unidade 8

Exemplo simplificado de um processo de mudanças Origens das mudanças Escopo Tempo Custos Recursos Qualidade Tecnologia Outras...

Identificação e avaliação dos impactos e desvios

Aprovação da mudança e negociação com os envolvidos

Análise de todas documentações e geração de um parecer.

Com base no parecer dos desvios e impactos.

Atualização das documentações

Comunicação das mudanças

Novas versões de cada área afetada para tratar as mudanças aprovadas.

Deixar cientes todos os envolvidos que são afetados pelas mudanças.

Imagem 8.1 Fonte: Autor.

Exemplo mais complexo de um processo de mudanças Solicitação do cliente

Contrato permite?

Aprovação do cliente

Negociar novos termos do contrato

Sim

Não

Não

Aprovação do cliente Sim

Sim

Contrato Permite?

Não

Determinar causa da mudança

Atraso Custo Qualidade

Impacto no custo cronograma qualidade e recursos

Sim

Não

Desenvolver plano de ação

Sim

Impacto aceitável?

Não

Novo plano de ação Não

Atualizar Plano de ação

Implementar mudança Documentação Final

Contrato permite?

Sim

Imagem 8.2

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Fonte: Autor.

Linhas base de escopo Para facilitar a visualização e controle dos planejamentos e mudanças, são estabelecidas as linhas base de controle, onde as mesmas funcionam como uma foto dos documentos do projeto em um determinado momento.

Esses momentos podem surgir de acordo com demandas específicas, ou até serem momentos pré-estabelecidos, como por exemplo: fim do planejamento, entrega do produto, início da execução, finalização do projeto, etc.

49

Gerenciamento do Escopo

Replanejamento Mudanças que exigem alterações na WBS, na Declaração do Escopo, nas estimativas e nos planos. Geralmente os replanejamentos acarretam na geração de uma nova linha base de planejamento, para que possam ser feitas comparações futuras em relação a esta mudança.

Reduzindo problemas de mudanças • Manter clientes e usuários integrados com a equipe de projeto • Realizar reuniões periódicas • Formalizar solicitações de mudanças • Realizar avaliação de impactos • Formalizar aprovações de mudanças • Utilizar um Sistema de Controle de Mudança • Manter o cliente informado sobre os impactos Sistema de Gerenciamento de Configuração

Proibida a reprodução – © UniSEB Interativo

Aplica técnicas de controle de versões de arquivos, além de traçarmos fotos no tempo para um grupo de documentos, com o intuito de sabermos se alterações que deveriam ser feitas foram ou não concretizadas e também auxilia no intuito de detectarmos se algo foi feito além do necessário.

Quando são geradas as linhas base no projeto, uma foto também é tirada dos documentos pertencentes ao mesmo, dessa forma, podemos saber como estava toda a documentação nestes momentos.

Imagem 8.3 Fonte: Autor.

50

Mudanças– Unidade 8

O sistema de gerenciamento da configuração, em um caso destes de mudança de escopo, deve garantir que, desde a última linha base traçada até a linha base que será traçada depois das mudanças, todos os planejamentos necessários tenham sido refeitos. Essa análise pode ser feita através da documentação de quais áreas e informações serão afetadas pela mudança e os documentos que realmente foram alterados entre as linhas bases em questão.

Referências bibliográficas PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos” – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

APPELO, Jurgen. Como Mudar o Mundo: Gestão de Mudanças 3.0.

51

Proibida a reprodução – © UniSEB Interativo

Gerenciamento do Escopo

52

UNIDADE 9 Modelos de Documentos Objetivos da aula: • Exibir alguns modelos de documentos que servirão de referência para o gerenciamento de escopo.

No intuito de facilitar o entendimento, colocamos aqui alguns modelos de documentos para servirem de referência. Muito embora apresentemos essas sugestões, isso não significa que todos as informações apresentadas são necessárias, assim como também não significa que outras informações não possam ser acrescentadas aos documentos. O bom senso e a vivência é quem vão ditar quais informações devem ser utilizadas para cada característica de projeto.

Declaração de escopo

Proibida a reprodução – © UniSEB Interativo

Gerenciamento do Escopo

54

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Modelos de Documentos – Unidade 9

55

Gerenciamento do Escopo

Proibida a reprodução – © UniSEB Interativo

Estrutura analítica do projeto (EAP)

56

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Modelos de Documentos – Unidade 9

Dicionário da EAP

57

Gerenciamento do Escopo

Proibida a reprodução – © UniSEB Interativo

Plano de gerenciamento do escopo

58

Modelos de Documentos – Unidade 9

Referências bibliográficas PMI, Project Management Institute (Editor). “Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos “– Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2004.

PMI, Project Management Institute Practice Standard for Work Breakdown Structures - 2006.

Xavier, Carlos Magno da Silva – “Gerência de Projetos - Como definir e controlar o escopo do projeto”. Editora Saraiva – 2005.

EAD-13-GP – Proibida a reprodução – © UniSEB Interativo

Revista Papo GP - http://papogp.com/ Ricardo Viana Vargas - http://www.ricardo-vargas.com/pt/

59

Proibida a reprodução – © UniSEB Interativo

Gerenciamento do Escopo

60