18340848
Description
Flashcards by kelly nascimento, updated more than 1 year ago
More
| Question | Answer |
| planning process group | group 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. |
| Process: 5.1 - Scope management plan Knowledge area: scope | Documentation plan on how the scope is defined and how it will be validated and controlled. |
| Scope management plan benefits | provide 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. |
| Scope management plan inputs | - Project charter - Project management plan (quality management plan, project life cycle description, development approach) - OPAs -EEFs |
| Scope management plan tools and techniques | -specialized opinion -data analysis (alternative analysis) -meetings |
| scope management plan outputs | -scope management plan - requirements management plan |
| components of the scope management plan document | - scope statement -wbs -baseline measurement and evaluation |
| requirements plan (business analysis plan) | component of the project management plan which describes how the project and product requirements will be analyzed, documented and managed. |
| requirements 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) |
| Process: 5.2 - collect requirements Knowledge area: scope | It'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. |
| the benefits of collecting requirements | it'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. |
| Collect 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 |
| Collect 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 |
| Collect requirements tools and techniques Decision-making techniques | - Voting - Autocratic decision - Decision analysis involving multiple criteria |
| Collect 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 |
| Collect requirements tools and techniques Decision-making technique: Autocratic decision | One person is responsible for making decisions on behalf of the group |
| Collect requirements tools and techniques Decision-making technique Decision analysis involving multiple criteria | A technique in which a decision-making matrix is used in order to give a systematic approach to evaluate and classify many ideas |
| Collect requirements tools and techniques Data Representation techniques | Affinity 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 |
| Collect requirements tools and techniques: Context diagrams tools | a scope model describing visually the product scope and showing a system and its interactions. |
| Collect requirements tools and techniques: prototypes | It'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. |
| Collect requirements Outputs | - requirements log - requirements tracking matrix |
| requirements log | Describes 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. |
| about the requirements | they 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. |
| requirements log: business requirements | Describes the organization's need at a high-level, such as business opportunities or matters the project in place is addressing. |
| requirements log: stakeholders requirements | Describes the stakeholders' needs |
| requirements log: solution requirements | Describes 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. |
| requirements log: solution requirements Functional requirements | Describes product behavior |
| requirements log: solution requirements Non-Functional requirements | They complement the functional requirements and describe the conditions or environmental aspects required for product efficiency. Ex: reliability, performance, safety, service level, etc. |
| requirements log: transition and readiness requirements | Describes temporary abilities necessary to move from the actual state to future state. ex: training |
| requirements log: project requirements | describes actions, processes, and conditions the project must meet. Ex: milestones dates, contractual obligations and restrictions |
| requirements log: Quality requirements. | describes any conditions or criteria needed to validate the successful conclusion of a project deliverable |
| requirements tracking matrix | matrix connecting the requirements, since their origin with the project and product objectives, being a structure to manage changes in the product scope. |
| Process: 5.3 - Define Scope Knowledge area: scope | Scope 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. |
| The benefits of defining the scope | It describes the product, service or result limits and its acceptance criteria |
| Define scope inputs | - project charter - scope management plan - assumptions log -requirements log -risks log -EEFs -OPAs |
| Define scope tools and techniques | - specialized opinion - data analysis - decision-making technique: Decision analysis involving multiple criteria - Interpersonal abilities and team skills: facilitation - product analysis |
| Define scope tools and techniques: Product analysis technique | Includes 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. |
| Define scope outputs | - scope statement - updates in the project documents: assumptions log, requirements log and requirements tracking matrix, stakeholders' log |
| Define scope outputs: Scope statement | It'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. |
| What 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 |
| Scope statement: Product scope description | elaborates, progressively, the product characteristics, as described in the project charter and requirements log |
| Scope statement: Deliverables | Any 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 |
| scope statement: acceptance criteria | set of conditions that must be met so the deliverables can be accepted. |
| scope statement: Out of scope items | Identifies what isn't included in the project scope, helping to manage the stakeholders' expectations |
| differences between the project charter and scope statement | LEVEL OF DETAIL! The project charter contains high-level information and the scope statement contains more detailed info on the scope elements. |
| Project Charter x Scope Statement elements | |
| Process: 5.4 - Create WBS Knowledge area: scope | It's the process to decompose the deliverables and project work into smaller components and more easy to manage. |
| The benefits of creating a WBS | It 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. |
| Create WBS inputs | - Scope management plan - scope statement - requirements log - EEFs - OPAs |
| WBS (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. |
| WBS elements: Work package | The 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. |
| Work package characteristics | - Independent - Definable: - Estimable - Manageable - Integrable - Adaptable |
| Work package characteristics: Independent | The work package must be mutually exclusive and have no dependence on other ongoing elements. |
| Work Package characteristics: Definable | The work package should have a definite beginning and end, and should be understood by all project participants. |
| Work package characteristics: Estimable | : You should be able to estimate the work package's duration and resource requirements. |
| Work 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. |
| Work package characteristics: integrable | : The package must integrate with other elements to create the parent level. |
| Work package characteristics: Adaptable | Ideally, the package must be able to accommodate changes in scope as per the project's requirements. |
| Control account | A 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. |
| Planning packages | WBS 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. |
| Work package x planning package | |
| Successively planning | Sometimes 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. |
| Create WBS Tools and Techniques | - Specialized opinion - Decomposition |
| Create WBS Tools and Techniques: Decomposition Technique | a 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. |
| The 100% WBS rule | All the lower level work must be tied to a high-level work so nothing is omitted or overworked. |
| Create 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 |
| Create WBS Tools and Techniques: Decomposition Technique approaches | - Top-down (most common) - Organization specific WBS - WBS models - Bottom-up (to group sub-components) |
| Create WBS Tools and Techniques: Decomposition Technique representation | - project life cycle (2nd level) and its deliverables (3rd level) - main deliverables (2nd level) - etc |
| Create WBS outputs | - Scope baseline - updates in the assumptions and requirements log |
| Create WBS outputs: Scope Baseline | The 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. |
| Create WBS outputs: Scope Baseline components | - Scope statement - WBS - Work packages - Planning packages - WBS Dictionary |
| Create WBS outputs: Scope Baseline components: WBS Dictionary | WBS 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. |
| Create 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 |
| Important about the WBS | Besides 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. |
| WBS Characteristics: The WBS doesn’t describe any actions. Instead, every item is a noun describing an end product | |
| WBS Characteristics | - Hierarchy - 100% rule - Mutually exclusive: - Outcome-focused |
| WBS Characteristics: Hierarchy | The 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 |
| WBS Characteristics: 100% rule | Every level of decomposition must make up 100% of the parent level. It should also have at least two child elements. |
| WBS Characteristics: Outcome Focused | The 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. |
| WBS Characteristics: Mutually exclusive | All 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. |
| The fundamental features of a WBS | it 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. |
| Additional Definitions: Work | work 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. |
| Work Breakdown Structure vs Project Schedule vs Project Plan | While 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. |
| Work Breakdown Structure vs Project Schedule vs Project Plan: WBS | describes 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. |
| Work Breakdown Structure vs Project Schedule vs Project Plan: Project Schedule | describes the project’s deliverables as well as their deadlines and resource requirements. Think of it as the “what”, “when”, and “who” of the project. |
| Work Breakdown Structure vs Project Schedule vs Project Plan: Project Plan | is 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. |
| heuristics for determining work packages | - 8/80 rule - Reporting period: - Use nouns |
| heuristics for determining work packages: 8/80 rule | A 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 |
| heuristics for determining work packages: Reporting period | Another 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. |
| heuristics 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. |
Want to create your own Flashcards for free with GoConqr? Learn more.