O GoConqr está de visual novo! Conte para nós o que você achou.

Registre-se grátis

Flashcards

Planning process group & Scope processes in it

kelly nascimento pmbok 6th ed Inglês 90 flashcards

Planning process group & Scope processes in it

Flashcards do conjunto (90)

  1. 1planning process groupgroup of processes to define the scope total effort, establish and refine the objectives and developing the plan to reach those goals. the project plan components and project documents are created in this process group.
    Depending on the project nature, these components and documents might need to be reviewed and updated regularly. The same might be needed when a great change occurs.
  2. 2Process: 5.1 - Scope management plan Knowledge area: scopeDocumentation plan on how the scope is defined and how it will be validated and controlled.
  3. 3Scope management plan benefitsprovide info on how the scope will be managed throughout the project. It's a one-time process and can be reapplied if needed in a predefined point of the project.
  4. 4Scope management plan inputs- Project charter
    - Project management plan (quality management plan, project life cycle description, development approach)
    - OPAs
    -EEFs
  5. 5Scope management plan tools and techniques-specialized opinion
    -data analysis (alternative analysis)
    -meetings
  6. 6scope management plan outputs-scope management plan
    - requirements management plan
  7. 7components of the scope management plan document- scope statement
    -wbs
    -baseline measurement and evaluation
  8. 8requirements plan (business analysis plan)component of the project management plan which describes how the project and product requirements will be analyzed, documented and managed.
  9. 9requirements plan describes- requirements prioritization process;
    - metrics and its use;
    - configuration management activities (hpw changes are initiated, tracked and reported, how impacts are analyzed and etc)
  10. 10Process: 5.2 - collect requirements Knowledge area: scopeIt's the process to determine, document, and manage stakeholder's needs and requirements in order to meet the project objectives. Requirements are the basis for the wbs: cost, schedule, quality, and procurement are based on the requirements.
  11. 11the benefits of collecting requirementsit's a basis for defining and managing the project and product scopes. It's a one-time process or performed in specific points throughout the project.
  12. 12Collect requirements Inputs- project charter
    - scope management plan
    - requirementes management plan
    - stakeholders' engagement plan
    - project documents (assumptions log, lessons learned and stakeholders' log)
    - Business case
    - agreements
    - OPAs
    -EEFs
  13. 13Collect requirements tools and techniques- specialized opinion
    - data gathering (brainstorming, interviews, discussion groups, research, benchmarking)
    - data and documents analysis
    - decision making
    - data representation (diagram connection and mind maps)
    - interpersonal and team skills (nominal group technique, talking and observing, facilitation)
    - context diagrams
    - prototypes
  14. 14Collect requirements tools and techniques Decision-making techniques- Voting
    - Autocratic decision
    - Decision analysis involving multiple criteria
  15. 15Collect requirements tools and techniques Decision-making technique: voting- Unanimity: Everybody agrees on the same course of action
    - majority: more than 50% of the group reaches an agreement
    - plurality: the bigger block of the group has to be in agreement
  16. 16Collect requirements tools and techniques Decision-making technique: Autocratic decisionOne person is responsible for making decisions on behalf of the group
  17. 17Collect requirements tools and techniques Decision-making technique Decision analysis involving multiple criteriaA technique in which a decision-making matrix is used in order to give a systematic approach to evaluate and classify many ideas
  18. 18Collect requirements tools and techniques Data Representation techniquesAffinity diagrams: groups big amounts of ideas to classify, review and analyze them
    - mind maps: consolidates ideas generated by a brainstorming so they can be reflected upon later
  19. 19Collect requirements tools and techniques: Context diagrams toolsa scope model describing visually the product scope and showing a system and its interactions.
  20. 20Collect requirements tools and techniques: prototypesIt's a method to collect initial responses about the requirements by using a smaller scale model to represent the expected product before its real construction. It allows stakeholders to experience the final product rather than just discussing abstract representations of it. Storyboarding is a prototyping technique in which a sequence of images is exhibited to demonstrate the final product.
  21. 21Collect requirements Outputs- requirements log
    - requirements tracking matrix
  22. 22requirements logDescribes how the individual requirements meet the business and project needs. It can start at a high level and get more detailed as more knowledge is acquired. Its format may vary from a simple categorized list to a more elaborated executive summary with detailed descriptions and attachments.
  23. 23about the requirementsthey must always be measurable, testing proof, trackable, complex, consistent, and acceptable to the stakeholders and can be grouped as business requirements, stakeholders requirements, solution requirements (with functional and non-functional requirements), transition and readiness requirements, project requirements and quality requirements.
  24. 24requirements log: business requirementsDescribes the organization's need at a high-level, such as business opportunities or matters the project in place is addressing.
  25. 25requirements log: stakeholders requirementsDescribes the stakeholders' needs
  26. 26requirements log: solution requirementsDescribes the product, service or results in attributes, functions, and characteristics that will meet the business and stakeholders' needs. They can be grouped in functional and non-functional requirements.
  27. 27requirements log: solution requirements Functional requirementsDescribes product behavior
  28. 28requirements log: solution requirements Non-Functional requirementsThey complement the functional requirements and describe the conditions or environmental aspects required for product efficiency. Ex: reliability, performance, safety, service level, etc.
  29. 29requirements log: transition and readiness requirementsDescribes temporary abilities necessary to move from the actual state to future state. ex: training
  30. 30requirements log: project requirementsdescribes actions, processes, and conditions the project must meet. Ex: milestones dates, contractual obligations and restrictions
  31. 31requirements log: Quality requirements.describes any conditions or criteria needed to validate the successful conclusion of a project deliverable
  32. 32requirements tracking matrixmatrix connecting the requirements, since their origin with the project and product objectives, being a structure to manage changes in the product scope.
  33. 33Process: 5.3 - Define Scope Knowledge area: scopeScope definition is the process to develop a detailed description of the project and product. This process selects the final project requirements based on the documents developed during the process of collecting requirements and then it defines a detailed description of the project and product, service or result. It is also based on the assumptions' log and restrictions, documented by the initiation process group and it can add up to them. It's a very iterative process.
  34. 34The benefits of defining the scopeIt describes the product, service or result limits and its acceptance criteria
  35. 35Define scope inputs- project charter
    - scope management plan
    - assumptions log
    -requirements log
    -risks log
    -EEFs
    -OPAs
  36. 36Define scope tools and techniques- specialized opinion
    - data analysis
    - decision-making technique: Decision analysis involving multiple criteria
    - Interpersonal abilities and team skills: facilitation
    - product analysis
  37. 37Define scope tools and techniques: Product analysis techniqueIncludes asking questions over a product or service and elaborating answers to describe its use, characteristics and other relevant aspects. It translates a high-level product description into deliverables by decomposing the requirements into a detailed level that reflects the design of the final product.
  38. 38Define scope outputs- scope statement
    - updates in the project documents: assumptions log, requirements log and requirements tracking matrix, stakeholders' log
  39. 39Define scope outputs: Scope statementIt's a project, deliverables, assumptions, and restrictions description. It documents the project and product scope and details the project deliverables. It also highlights what isn't included in the scope, which allows the project team to evaluate what is acceptable when it comes to change requests.
  40. 40What is included in the scope statement (as part of it or as a reference to other documents)- product scope description
    - deliverables
    -acceptance criteria
    - out of the scope items
  41. 41Scope statement: Product scope descriptionelaborates, progressively, the product characteristics, as described in the project charter and requirements log
  42. 42Scope statement: DeliverablesAny product, result or service capability that is unique, verifiable and necessary to complete a process, phase or project. It includes auxiliary results and documents, such as project reports. They can be described in details or high-level
  43. 43scope statement: acceptance criteriaset of conditions that must be met so the deliverables can be accepted.
  44. 44scope statement: Out of scope itemsIdentifies what isn't included in the project scope, helping to manage the stakeholders' expectations
  45. 45differences between the project charter and scope statementLEVEL OF DETAIL!
    The project charter contains high-level information and the scope statement contains more detailed info on the scope elements.
  46. 46Project Charter x Scope Statement elementsProject Charter x Scope Statement elements
  47. 47Process: 5.4 - Create WBS Knowledge area: scopeIt's the process to decompose the deliverables and project work into smaller components and more easy to manage.
  48. 48The benefits of creating a WBSIt provides a structured view of what must be delivered. It's done once and repeated in predefined points of the project when needed.
    The WBS is the foundation of the project schedule and budget. Once you know all the deliverables required to complete the project, as well as their hierarchical relationships, it will be much easier to assign resources and set deadlines.
    Since all elements in a WBS are mutually exclusive, it helps create accountability. A team assigned to a single work package is wholly accountable for its completion. This reduces overlaps in responsibility.
    The WBS gives teams a very high-level overview of their responsibilities. Since each team is responsible for a specific component at a time, it helps make them more committed to completing their assigned tasks.
    The process of developing the WBS involves the project manager, project team, and all relevant stakeholders. This encourages dialog and helps everyone involved flesh out their responsibilities. Thus, everyone has less ambiguity and a better idea of what they're supposed to do.
  49. 49Create WBS inputs- Scope management plan
    - scope statement
    - requirements log
    - EEFs
    - OPAs
  50. 50WBS (Work Breakdown Structure)It's a hierarchical decomposition of the total scope and project work to be performed by the project team to meet project objectives and create its deliverables. It organizes and defines the total scope and represents the work specified in the approved scope statement. It represents all the product and project work, including the project management work.
  51. 51WBS elements: Work packageThe work defined at the lowest level of the WBS, with a unique identification, for which cost and duration are estimated and managed. The level of detail of the packages may vary accordingly to the project size and complexity.
    The identifications provide a structure to summarize costs, schedule and information over resource allocation. Each work package is part of a control account.
  52. 52Work package characteristics- Independent
    - Definable:
    - Estimable
    - Manageable
    - Integrable
    - Adaptable
  53. 53Work package characteristics: IndependentThe work package must be mutually exclusive and have no dependence on other ongoing elements.
  54. 54Work Package characteristics: DefinableThe work package should have a definite beginning and end, and should be understood by all project participants.
  55. 55Work package characteristics: Estimable: You should be able to estimate the work package's duration and resource requirements.
  56. 56Work package characteristics: Manageable: The package must represent a "meaningful unit of work", i.e. it must accomplish something concrete, and can be assigned to an individual or team. It should also be measurable.
  57. 57Work package characteristics: integrable: The package must integrate with other elements to create the parent level.
  58. 58Work package characteristics: AdaptableIdeally, the package must be able to accommodate changes in scope as per the project's requirements.
  59. 59Control accountA managed control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Each control account may have two or more work packages but each work package is associated with a unique control account.
  60. 60Planning packagesWBS component below the control account and above the work package with a known work but without detailed activities in the schedule. That means: it's a package that is part of the scope but needs further decomposition. It usually appears as part of the WBS when successively planning is needed.
  61. 61Work package x planning packageWork package x planning package
  62. 62Successively planningSometimes the decomposition of an item that will be developed in a distant future isn't possible. So, the project team waits to develop the WBS details until a consensus over the delivery of a component or subcomponent is reached.
  63. 63Create WBS Tools and Techniques- Specialized opinion
    - Decomposition
  64. 64Create WBS Tools and Techniques: Decomposition Techniquea technique used to divide the scope and its deliverables into smaller and easier to manage pieces (work packages). The decomposition level is oriented by the level of control necessary to manage the project effectively.
    Ideally, your decomposition should stop before you can use verbs to describe the element. For instance, if you're building a bicycle, "wheel rim" should be the final level since it describes a deliverable. If you decompose further, you'll have activities related to the deliverable such as "buy steel", "shape steel", "make holes for wheel spokes", etc.
  65. 65The 100% WBS ruleAll the lower level work must be tied to a high-level work so nothing is omitted or overworked.
  66. 66Create WBS Tools and Techniques: Decomposition Technique activities:- Identification and analysis of the related work
    - WBS structure and organization (determine the deliverables and how to represent them)
    - Decomposition of the highest WBS levels into detailed components in the lower levels (determine the work and planning packages)
    - Designation of the WBS components
    - Validation of the decomposition level
  67. 67Create WBS Tools and Techniques: Decomposition Technique approaches- Top-down (most common)
    - Organization specific WBS
    - WBS models
    - Bottom-up (to group sub-components)
  68. 68Create WBS Tools and Techniques: Decomposition Technique representation- project life cycle (2nd level) and its deliverables (3rd level)
    - main deliverables (2nd level)
    - etc
  69. 69Create WBS outputs- Scope baseline
    - updates in the assumptions and requirements log
  70. 70Create WBS outputs: Scope BaselineThe approved version of the scope statement, WBS, and WBS dictionary that can only be changed through formal procedures and it's used as a comparison basis. It's a project management plan component.
  71. 71Create WBS outputs: Scope Baseline components- Scope statement
    - WBS
    - Work packages
    - Planning packages
    - WBS Dictionary
  72. 72Create WBS outputs: Scope Baseline components: WBS DictionaryWBS dictionary is a document that provides detailed info about deliverables, activities, and scheduling of each WBS component. It supports the WBS and most of its info is created by other processes and added to it later.
  73. 73Create WBS outputs: Scope Baseline components: WBS Dictionary info- account control identification
    - work description
    - premises and restrictions
    - responsible
    - milestones
    - schedule related activities
    - resources
    - acceptance criteria
    - technical reference
    - agreements info
  74. 74Important about the WBSBesides its called work breakdown structure it isn't about breaking down the work but the DELIVERABLES! It is a hierarchical structure of things that the project will make or outcomes that it will deliver.
    That means: A work breakdown structure defines all the things a project needs to accomplish, organized into multiple levels, and displayed graphically.
  75. 75WBS Characteristics: The WBS doesn’t describe any actions. Instead, every item is a noun describing an end productWBS Characteristics: The WBS doesn’t describe any actions. Instead, every item is a noun describing an end product
  76. 76WBS Characteristics- Hierarchy
    - 100% rule
    - Mutually exclusive:
    - Outcome-focused
  77. 77WBS Characteristics: HierarchyThe WBS is hierarchical in nature. Each “child” level exists in a strict hierarchical relationship with the parent level. The sum of all the child elements should give you the parent element
  78. 78WBS Characteristics: 100% ruleEvery level of decomposition must make up 100% of the parent level. It should also have at least two child elements.
  79. 79WBS Characteristics: Outcome FocusedThe WBS must focus on the result of work, i.e. deliverables, rather than the activities necessary to get there. Every element should be described via nouns, not verbs.
  80. 80WBS Characteristics: Mutually exclusiveAll elements at a particular level in a WBS must be mutually exclusive. There must be no overlap in either their deliverables or their work. This is meant to reduce miscommunication and duplicate work.
  81. 81The fundamental features of a WBSit describes deliverables, not the activities necessary to get there. Every item in the WBS must correspond to an end product (real or virtual). If there are any verbs in your WBS, then you’re doing something wrong.
  82. 82Additional Definitions: Workwork products or deliverables that are the result of effort and not the effort itself”. That is, “work” defines the end result of any activity. The work remains constant even though the amount of effort needed to get there might inflate/deflate.
  83. 83Work Breakdown Structure vs Project Schedule vs Project PlanWhile these three things often describe the same thing - what is to be achieved in the project - they vary greatly in scope and details.
    In terms of the level of detail, the project plan is the broadest, followed by the work breakdown structure and project schedule.
  84. 84Work Breakdown Structure vs Project Schedule vs Project Plan: WBSdescribes the deliverables needed to complete the project, i.e. the “what” of the project. It doesn’t include timelines or resources. The goal of the WBS is to give the project team a hyper-focused idea of what they need to achieve.
  85. 85Work Breakdown Structure vs Project Schedule vs Project Plan: Project Scheduledescribes the project’s deliverables as well as their deadlines and resource requirements. Think of it as the “what”, “when”, and “who” of the project.
  86. 86Work Breakdown Structure vs Project Schedule vs Project Plan: Project Planis an expansive document covering virtually every aspect of the project and its management. It includes details on how the project will be executed, managed, and controlled. It usually has several constituent plans governing communications, risk management, change management, etc.
  87. 87heuristics for determining work packages- 8/80 rule
    - Reporting period:
    - Use nouns
  88. 88heuristics for determining work packages: 8/80 ruleA common rule of the thumb is that each work package must be no longer than 80 hours and no less than 8 hours in total length. If it is longer, decompose it further. If it is shorter, think of going up by one level
  89. 89heuristics for determining work packages: Reporting periodAnother common rule is to limit each work package to a single reporting period. If it takes longer than one reporting period (monthly, weekly, etc.), to accomplish, decompose it further.
  90. 90heuristics for determining work packages: Use nouns or adjectives, but never verbs.You should be able to describe each work package with a noun or an adjective. To break it down further, you’ll need to use verbs. For example, “bike seat” is a noun describing a work package. If you break it down further, you’ll need to use verbs like “cut foam”, “stitch leather”, etc.

Informações

Descrição
key point and concepts about the planning process group from pmbok 6th ed
Visualizações
11
Histórico
  • Criado por kelly nascimento · 22 mai 2019
  • Copiado por kelly nascimento · 2 jun 2019
Avaliação

Fale Conosco

Sobre o que é sua mensagem?

O que você acha do novo visual?

Você gostou?