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