SCOPE MGMT Flashcards Preview

PgMP > SCOPE MGMT > Flashcards

Flashcards in SCOPE MGMT Deck (62)
Loading flashcards...
1
Q

ACCEPTANCE

A

The process of formally receiving the work of the project after it is determined that the work is complete and fulfills the needs for which it was created.

2
Q

ACCEPTANCE CRITERIA

A

Requirements that must be completed before th work can be accepted

3
Q

BENEFITS REALIZATION PLAN

A

The document that memoriatizes the proposed benefits of the program for team monitoring, distinguishes the process and systems needed to achieve the benefits, details the manner in which the benefits will be achieved, and develops the schedule for transitioning the benefits

4
Q

BILL OF MATERIALS (BOM)

A

A formal document showing the heirarchy of product components or pieces and their subcomponents or sub-pieces

5
Q

COMPONENT STAKEHOLDER MANAGEMENT GUIDELINES

A

The blue print for managing stakeholders at the component level which addresses identification, assessment, and involvement of the stakeholders

6
Q

CONTROL ACCOUNT

A

A point where scope, time, budgeted cost, and actual cost come together to measure performance on a program or project; the control account is used at multiple interface points on the program or project

7
Q

DECOMPOSITION

A

The process of breaking down the work of the program or project into smaller more controllable pieces

8
Q

DEFINE PROGRAM GOALS AND OBJECTIVES

A

The process of determining the program objectives and benefits

9
Q

DELIVERABLE

A

A key piece of work for the program or project; can be physical work, a process, a document, or other measurable result of work

10
Q

DEVELOP PROGRAM ARCHITECTURE

A

The process of evolving the framework of the program components and determining the interrelationships of the components

11
Q

DEVELOP PROGRAM REQUIREMENTS

A

The process of determining and evolving the requirements that will attain the program objectives

12
Q

DEVLOP PROGRAM WBS

A

The process of decomposing the program to its components, deliverables, and activities to generate a work breakdown structure for each program components

13
Q

FOCUS GROUPS

A

Groups comprised of individuals who are brought together to answer specific questions about their reactions to a product, service, or idea; problem solving is often a goal of focus groups

14
Q

MANAGE PROGRAM ARCHITECTURE

A

Manages the relationships across all program components to ensure that the program architecture remains consistent across all the deliverables.

15
Q

MANAGEMENT COMPONENT INTERFACES

A

The process of ensuring that program components are executed so that program benefits are delivered

16
Q

MILESTONE

A

A major achievement on a program or project resulting from the completion of a series of activities; has ero=days duration and could be related to a “deliverable”

17
Q

MONITOR AND CONTROL PROGRAM SCOPE

A

The process of tracking and regulating the program to ensure adherence to the program charter in terms of objectives and benefits

18
Q

PLAN PROGRAM SCOPE

A

The process of distinguishing and evolving the activities that will produce the benefits and objecties defined in the program charter

19
Q

PROGRAM ARCHITECTURE

A

The coherent structure and interrelationship of the products of program component. The structure of the program component products and their technical relationships with one another

20
Q

PROGRAM ARCHITECTURE BASELINE

A

Comprised of the components that provide the specified benefits of the program and delineates their attributes, skills, timing and external interactions.

21
Q

PROGRAM DOCUMENT REPOSITORY

A

provides storage and accessiblity for program related documents; typically, versioning and standard document format are considered in the design

22
Q

PROGRAM REQUIREMENTS DOCUMENT

A

Depicts requirements that deliver benefits and addresses enterprise, environmental, legal, and technical consequences

23
Q

PROGRAM SCOPE MANAGEMENT PLAN

A

Part of program plan containing: 1. Assessment of scope stability, 2. Processes for Scope Change Req, 3. Processes to ID scope changes, 4. How scope managed, 5. How to integrate changes

24
Q

PROGRAM WORK BREAKDOWN STRUCTURE (PWBS)

A

An organized breakdown of the total work scope of the program, with each level of descent providing a greater level of detail

25
Q

PROJECT SCOPE BASELINE

A

Original, or revised with proper authorization, definition of the scope of the project; can include project scope statement, work breakdown structure (WBS), and WBS dictionary

26
Q

PWBS DICTIONARY

A

Description of components and relevant info such as: Logical groupings, Interfaces with ops or products, Clarify program?s conclusion, Non-project related work done at program level

27
Q

REQUESTED CHANGE

A

A formal request for a change to the program or project that is submitted for approval

28
Q

REQUIREMENT

A

A business or technical requirement for the attainment of program or project goals

29
Q

SCOPE

A

The work that will be encompassed in the program or project and the final product, service, result, or benefit. Scope overview and lists: 1. Org needs and requirements 2. High-level product requirements 3. Solution vision 4. Assumptions, Constraints, & Risks 5. Desc. of each project & resources 6. program Benefits and Deliverables

30
Q

SCOPE CHANGE

A

An approved change to the scope of the program or project

31
Q

SCOPE CREEP

A

unauthorized request for changes that occur as the program or project evolves

32
Q

SCOPE STATEMENT

A

Written statement in Pg Mgmt Plan which includes: 1) What is/is not included 2) List of Deliverables and Success Criteria 3) what the program is expected to do when complete. Used to gain common buyin from stakeholders on what the program is. Includes: detailed description of constraints, requirements, scope, business effect the program will have, description of each component, and a description of resources for each components
- The stakeholders “sign off” on this for alignment.

33
Q

STATEMENT OF WORK (SOW)

A

a description of services, products, and work results to be accomplished on a project or other initiative

34
Q

TASK

A

an activity to be completed on the program or project

35
Q

TASK RESPONSIBILITY MATRIX

A

an array of roles and involvement levels of each team member

36
Q

VALIDATION

A

the process of evaluating something that was created in the program or project to ensure that it meets the requirements for formal acceptance

37
Q

VERIFICATION

A

the process of evaluating something that was created in the program or project to ensure that it meets the specified conditions

38
Q

WORK BREAKDOWN STRUCTURE MATRIX

A

an array of work elements used to organize and categorize work scope

39
Q

WORK PACKAGE

A

a deliverable at the smallest level of the PROJECT WBS; represents the completed piece of the project from the culmination of a series of activiteis being complete

40
Q

How does the Program Mgmt Plan help the PgM?

A
  1. Establish a cope statement and requirements 2) creeate a PWBS, 3) validate that the deliverables and work of the program were built correclty and 4) address cope-related changes to the program and its projects
41
Q

CUSTOMER ACCEPTANCE REVIEW

A

Tool used during “Define Pg Goals and Obj” process in order to obtain customer acceptance for each deliverable to ensure custoemr satisfaction in the end.

42
Q

REQUIREMENTS GATHERING

A

tool used during “develop requirements”. Method of assembling requirements from various sources, including stakeholders, existing documents, and process anlayis; methods include inteerviewing, focus groups, and surveys.

43
Q

REQUIREMENTS ANALYSIS

A

tool used during “develop requirements”. Method of assessing the requirements to ensure consistency and completeness

44
Q

DESIGN REVIEW

A

tool used during “develop requirements”. Review to determine that the design of the program or component meets best practice guidelines; design reviews may be formal, reviewed by the customer, internal, reviewd by subject matter experts and peers, or in-process, reviewed by peers

45
Q

BRAINSTORMING

A

tool used during “develop requirements”. Used to ID requirements often.

46
Q

REQUIREMENTS VERIFICATION AND VALIDATION

A

tool used during “develop requirements”. Ongoing process of determining that requirements are correct and comprehensive.

47
Q

COMPONENT REQUIREMENTS DOC

A

Output of “develop requirements”. Decomposes component needs for inclusion into contracts and further decomposes them to a level that allows accurate schedule estimates.

48
Q

MANAGEMENT PLANNING PROCESSES

A

tool used during “Develop PWBS”. Supplies assessment and conception methods for achieving the program goals.

49
Q

SYSTEM CONFIGURATION TOOLS

A

tool used during “Develop PWBS”. Provide change control for items, such as processes, that are subject to modification throughout the program life cycle; the tools assign version control for ease of monitoring change.

50
Q

Who creats the PWBS?

A

PgM, Program Team, Project Mgrs, and PM teams

51
Q

What items are able to start from the PWBS?

A

schedule, bugt, resource assignments, risk planning

52
Q

How many levels of the Project WBS are typically included in the PWBS?

A

the top 2

53
Q

What happens with inadequate PWBSS work?

A

often leads to scope creep and estimating inaccuracies. Jeapordizes successful delivery of one or more projects

54
Q

Organizational Breakdown Structure

A

also known as an org chart for the program

55
Q

RBS (Resource Breakdown Structure)

A

shows the type of resources used on a program or project

56
Q

CONFLICT MANAGEMENT

A

Conflict management is the approach used to resolve conflict among stakeholders and team members; escalation is addressed in conflict management

57
Q

VERIFY SCOPE

A

process that occurs during project mgmt. used to approve copmleted project deliverables that contribute to benefits at the program level.

58
Q

100% RULE

A

ensuring that 100% of the work of the program or project is represented in the WBS to ensure that the time, cost, and staffing estimates are as accurate as possible.

59
Q

PROGRAM PACKAGE

A

lowest level of decomposition at the PROGRAM LEVEL.

60
Q

M/C SCOPE OUTPUTS (4)

A
  1. Approved Change Requests - governance group approves scope change formally
  2. Pg Requirements Updates - as needed per the approved change
  3. Pg Mgmt Plan Updates - as needed per the approved change
  4. Pg Doc Repository Updates - must update the docs accordingly per the change!
61
Q

M/C SCOPE INPUTS (6)

A
  1. Pg Scope Statement - current approved scopes, constraints, requirements
  2. Scope Change Requests - requests
  3. Component Transition Requests - after governance review, Pg mgr does final confirmation scope of components complete
  4. Pg Architcture Baseline - review for timing of components, etc. Are things progressing? how will the change requests affect this?
  5. Governance Plan - tells processes to follow for change requests, initiate comp, etc
  6. Pg Mgmt Plan - Provides overall plan for M/C
62
Q

END USER VS CUSTOMER STAKEHOLDERS

A

The customer is the one contracting with you for the product or service. But the End User is the ultimate final user after the product/service is resold to them. The PgM should meet with end-users as much as feasible to understand the ultimate product/service requirements.