Foundation Flashcards
1
Q
Recall the six aspects of project performance to be managed.
A
Cost Timescales Quality Scope Benefits Risk
2
Q
Recall the definition of a project and the purpose of PRINCE2
A
“A temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.”
Prince2 aims to seperate the management layer from the specialist work.
3
Q
Recall the 5 characteristics of a project
A
Change Unique Cross Functional (Involves) Uncertainty Temporary
4
Q
Recall four integrated elements of principles, themes, processes, and the project environment upon which PRINCE2 is based.
A
Principles: “guiding obligations and best practices” MANDATORY for a project to be PRINCE2.
Themes: “aspects of PM that must be addressed continually and in parallel throughout the project.”
Processes: “Chronological progression through project, providing a guide to recommended activities, products, and related responsibilities.
Necessary to “tailor” PRINCE2 “to the specific context of the project.”
5
Q
Recall the customer/supplier context of a PRINCE2 project.
A
Environment in which the customer defines the requirement, pays for the project and uses the eventual products; and in which the supplier provides the required skills and know-how to create the end-products for the customer.
6
Q
Recall the benefits of PRINCE2
A
“Established and proven best practice and governance for PM.”
Applicable to any type of project “and can easily be implemented alongside specialist, industry-specific models.”
“Widely recognized and understood.”
“Provides for explicit recognition of project responsibilities . . . There is a defined structure for accountability, delegation, authority, and communication.”
“Product focus clarifies (for all parties) what a project will deliver, why, when, by whom, and for whom.”
Meets needs of different management team levels.
Based on “management by exception.”
Ensures focus on Business Case (rather than seeing the project as an end in itself).
“Defines a thorough but economical structure of reports.”
Ensures proper representation of stakeholders.
“Promotes learning and continual improvement” in organizations.”
“Promotes consistency of project work and the ability to reuse project assets; it also facilitates staff mobility and reduces the impact of personnel changes/handovers.”
“Diagnostic tool, facilitating the assurance and assessment of project work, troubleshooting, and audits.”
Existence of accredited training, consulting, and certification organizations.
7
Q
Understand the seven principles.
A
(1) Continued business justification.
(2) Learn from experience.
(3) Defined roles and responsibilities.
(4) Manage by stages.
(5) Manage by exception.
(6) Focus on products.
(7) Tailor to suit the project environment
8
Q
Understand the characteristics of a project.
A
- Change
- Temporary
- Cross-functional
- Unique
- Uncertainty
9
Q
Understand the difference between a project manager and project management.
A
A PM sets out to achieve the project objectives using aspects of project performance (TeCQuila SoBer) and the Project Plan as a baseline.
Project Management makes use of Planning, Delegating, Monitoring and Controlling to achieve a projects objectives.
10
Q
Understand the difference between an output, an outcome, and a (dis)-benefit.
A
“An OUTPUT is any of the project’s specialist products (whether tangible or intangible).”
“An OUTCOME is the result of the change derived from using the project’s outputs.”
“A BENEFIT is the measurable improvement resulting from an outcome that is perceived as an advantage by one or more stakeholders.”
Dis-benefit - where the outcome is negative, usually the result of a side effect or a consequence.
Output -> Outcomes -> Benefit.
11
Q
Understand the purpose of the Business Case theme.
A
“The purpose of the Business Case theme is to establish mechanisms to judge whether the project is (and remains) desirable, viable, and achievable as a means to support decision making in its (continued) investment.
12
Q
Understand the purpose of a Business Case and a Benefits Review Plan.
A
“The Business Case is a description of the reasons for the project and the justification for its undertaking. It should provide a clear statement of the benefits that are expected from the project and the costs, risks and timescale that are entailed in achieving those benefits.” [ILX]. The Business Case enables the Project Board to judge whether the project is:
• Desirable - that the cost/benefit/risk analysis is valid,
• Viable - that the project can deliver its products, and
• Achievable - that the product can provide the benefits.” [ILX]
Benefits Review Plan - identify the benefits and most importantly, how the benefits can be measured so that it is possible to show that they have been reached
13
Q
Recall the defined roles within the Organization theme.
A
- Executive
- Senior User
- Senior Supplier
- Project Assurance
- Change Authority
- Project Manager
- Project Support
- Team Manager
14
Q
Understand the purpose of the Organization theme.
A
“The purpose of the Organization theme is to define and establish the project’s structure of accountability and responsibilities.”
15
Q
Understand the three project interests and how these are represented within the three levels of the project management team structure.
A
- Business (Executive)
- User (Senior User)
- Supplier (Senior Supplier)
Represented at the Directing (Project Board) level of the project management team.
16
Q
Understand the role, responsibilities and characteristics of the Project Board.
A
“Responsible for the overall direction and management of the project (DP) and the overall success of the project.”
“The Project Board is the overall authority for the project and is responsible for its initiation, direction, review and eventual closure.” [ILX]:
“Approve all major plans and resources. Authorize any deviation that exceeds tolerances. Approve stage completion and start of next state. Communicate with other stakeholders.”
Characteristics: Authority, Credibility, Delegation and Availability.
17
Q
Understand the role, responsibilities and characteristics of the Project Manager.
A
Responsibile for managing a project on a day-to-day basis, on behalf of the Project Board. Ensures the project products the required products in accordance with the six performance objectives. The PM provides regular Highlight Reports for the Project Board.
Characteristics: Good communication, cost management, leadership, team-building.
18
Q
Understand the role, responsibilities and characteristics of Project Assurance.
A
Responsible for monitoring all aspects of the project performance and products independently of the Project Manager.
3 forms:
- Business Assurance - value for money?
- User Assurance - work as expected?
- Supplier Assurance - deliver as expected?
Characteristics: Support PM, provide an independent view, are fully aware of correct standards.
NB: a MANDATORY role.
19
Q
Understand the role, responsibilities and characteristics of the Change Authority.
A
“Responsible for agreeing to changes to the requirements or scope of the project. By default this responsibility lies with the Project Board but they may, if they wish, delegate it to another body.” [ILX]
20
Q
Understand the role, responsibilities and characteristics of the Team Manager.
A
Responsible for producing and delivering the specialist products assigned in Work Packages by the PM and for regular status updates. They will define the responsibilities for team members and create own Team Plans. Any changes raised by the TM will be raised as issues for PM. The TM will run Checkpoint meetings to raise Checkpoint records for the PM.
NB: an OPTIONAL role.
21
Q
Understand the role, responsibilities and characteristics of Project Support.
A
Responsible for administrative services or advice and guidance on the use of PM tools or Configuration Management. Can also supply planning or risk management.
22
Q
Understand what a project stakeholder is.
A
Stakeholder
“Any individual, group, or organization that can affect, be affected by, or perceive itself to be affected by, an initiative (program, project, activity, risk).”
23
Q
Understand the purpose of the Communication Management Strategy.
A
Defines the rules of engagement for how communication should be done during the project between stakeholders (internal and external). Takes place during the IP phase, reviewed during the MS phase.
24
Q
Recall the recommended quality review team roles and their responsibilities.
A
Chair
Responsible for the overall conduct of the review.
Presenter
Introduces the product for review and and represents the producer(s) of the product. Also coordinates and tracks the work after the review, i.e. applying the changes to the product agreed by the team.
Reviewer
Reviews the product, submits questions, and confirms corrections and/or improvements.
Administrator
Provides administrative support for the chair and records the result and actions.
25
Understand the purpose of the Quality theme.
"To define and implement the means by which the project will create and verify products that are fit for purpose."
ILX adds: "and satisfy the needs and expectations of the Customer."
Provides a method to help specify Quality, tests, how to get approved and to facilitate the management of Quality during the Project.
26
Understand the relationship between Quality Assurance and Project Assurance.
Quality Assurance - provides a way to get an independent review of the Quality Process in a organisation.
Project Assurance - focuses on the quality in a project.
27
Understand the objectives of the quality review technique.
- To assess the conformity of a product which takes the form of a document (or similar item, e.g. a presentation or test results) against set criteria.
- To involve key interested parties in checking the product's quality and in promoting wider acceptance of the product.
- To baseline the product for change control purposes."
28
Understand the difference between Quality Process, Control, Standards and Quality Planning.
Quality Process - checks to see that it complies with the company Quality Standards.
Quality Standards - ensures that the quality Processes are in place.
Quality Planning - defines the products, methods, criteria, acceptance criteria and responsibilities in the QMS during IP.
Quality Control - techniques and activities to inspect and test methods to track Quality of products.
29
Understand the difference between Customer's quality expectations and acceptance criteria.
1. Customers quality expectations - requirements that will drive the choice of solution and, in turn, influence the time, cost, scope, risk and benefit performance targets of the project. Acknowledged in the Project Product Description.
Contains prioritized expectations, MoSCoW, Measures & tolerances.
2. Acceptance criteria - prioritised list of attributes. First agreed between Customer and Supplier in SU process. AC will be baselined with the rest of the PID and can only be changed with Board Approval.
Contains prioristied attributes, MoSCow, Yes/No.
30
Understand the purpose of a Project Product Description, Quality Management Strategy, Product Description and Quality Register.
3. Project Product Description - description of the main product that will be produced by the project. Created in the SU process, part of the Project Brief and may be refined in the Initiation Stage. Used by CP to help verify that the project has been delivered.
Contains purpose, composition, Quality Expectations, Acceptance criteria and tolerances.
4. Quality Management Strategy - PM teams proposal in response to the customers quality expectations and acceptance criteria. Confirms quality standards, procedures, techniques, tools and strategy.
5. Product Description - created for all products as part of planning and before Project Plan. Created in IP stage.
Contains identifier, title, purpose, composition and Quality (criteria, method, tolerance..).
6. Quality Register - diary of quality events planned and undertaken. Audit and assurance information relating to what was planned and agreed (in QMS and PD's) to the quality activities usually performed
31
Recall the levels of plans recommended by PRINCE2.
- Project Plans (Directing/high level)
- Stage Plans (Management/day-to-day level)
- Team Plans (Delivering/work level)
32
Recall four tasks ofUnderstand the purpose of the Plans theme product-based planning (iterative).
A technique "to determine and fully understand all of the products (or deliverables) which the project is to create. Having done that, it will be much easier to identify and plan the activities necessary to create them.
1. Writing the Project Product Description - describe the main product
2. Producing a Product Breakdown Structure - listing all products that need to be created
3. Writing Product Descriptions for all identified products
4. Producing a Product Flow Diagram - show product flow and inter-dependencies.
33
Understand the purpose of the Plans theme
"The purpose of the Plans theme is to facilitate communication and control by defining the means of delivering the products (the where and how, by whom, and estimating the when and how much)."
34
Understand the levels of plans, their purpose, and the interrelationship between the Project Plan, Stage Plans, Team Plans, and an Exception Plan.
Project plan: how time, cost, scope, and quality targets will be met, showing MAJOR products, activities, and required resources.
Stage Plan: More detailed, day-by-day level plan suitable for controlling one stage.
Team Plan: Produced by a Team Manager to facilitate the execution of one or more Work Packages.
Exception Plan - used to recover from the effect of tolerance deviation - to replace the current Stage Plan or Project Plan.
35
Understand the three types of management product: baselines, records, and reports.
"Baseline management products are those that define aspects of the project and, once approved, are subject to change control."
"Records are dynamic management products that maintain information regarding project progress."
"Reports are management products providing a snapshot of the status of certain aspects of the project."
Baseline products, e.g.
Business Case
Project Plan
Records, e.g.
Issue/Risk/Quality Registers
Reports, e.g.
Checkpoint Report
End Project Report
36
Understand the tasks within the product-based planning technique.
A technique "to determine and fully understand all the products (or deliverables, as they are often referred to) which the project is to create. Having done that, it will be much easier to identify and plan the activities necessary to create them." [ILX]
1. Product Planning Description - Senior User - Contains purpose, composition, Quality Expectations, Acceptance Criteria and tolerances
2. Product Breakdown Structure - Project product broken down into major products (hierarchy)
3. Product Description - Contains identifier, title, purpose, composition and Quality (criteria, method, tolerance..)
4. Product Flow - Sequence of product creation.
37
Recall the definition of a risk and the difference between a threat and an opportunity.
Risk: "An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives."
"Threat is used to describe an uncertain event that could have a negative impact on objectives."
"Opportunity is used to describe an uncertain event that could have a favorable impact on objectives."
38
Recall the risk response types and whether they are used to respond to a threat or opportunity.
Threat responses
- Avoid
- Reduce
- Fallback
- Transfer
- Share
- Accept
Opportunity Responses
- Exploit
- Enhance
- Share
- Reject
39
Recall the difference between a risk owner and a risk actionee.
Risk Owner: "The person responsible for managing the risk (there can be only one risk owner per risk)."
Risk actionee: "The person(s) who will implement the action(s) described in the risk response. This may or may not be the same person as the risk owner."
40
Understand the purpose of the Risk theme.
"The purpose of the Risk theme is to identify, assess, and control uncertainty and, as a result, improve the ability of the project to succeed.
[IAC]
41
Understand the five steps within the risk management procedure.
Identify (context & risks)
Context: obtain information about the project to understand objectives at risk and to formulate the Risk Management Strategy.
Risks: "To recognize the threats and opportunities that may affect the project's objectives (in terms of cause, event and effect)."
Assess (estimate & evaluate)
Estimate: "Assess the threats and opportunities to the project in terms of their probability and impact. The risk proximity will also be of interest to gauge how quickly the risk is likely to materialize if no action were taken."
Evaluate: "assess the net effect of all the identified threats and opportunities on a project when aggregated together."
Plan
"To prepare specific management responses to the threats and opportunities identified . . . "
Implement
"Ensure that the planned risk responses are actioned, their effectiveness monitored, and corrective action taken where responses do not match expectations."
Communicate
Carried out continually and "should ensure that information related to the threats and opportunities faced by the project is communicated both within the project and externally to stakeholders."
[IAPIC]
42
Understand the purpose of a risk budget.
"A sum of money included within the project budget and set aside to fund specific management responses to the project's threats and opportunities."
43
Understand the probability, impact, and proximity of a risk.
Probability: likelihood of occurrence.
Impact: the quantifiable effect on project objectives.
Proximity: when the risk risk is likely to materialize.
44
Understand the difference between cause, event, and effect when expressing a risk.
Pattern: "Due to (cause)… there is the risk of (event)… that could result in (effect)…." [MgmtPlaza]
Risk cause: "The source of the risk . . . often referred to as risk drivers . . . the potential triggers for risk."
Event: the thing that needs to materialize; the risk itself.
Effect: "the impact(s) that the risk would have on the project objectives should the risk materialize."
45
Understand the purpose of a Risk Management Strategy.
"To describe how risk management will be embedded in the project management activities."
"A strategy describing the goals of applying risk management, as well as the procedure that will be adopted, roles and responsibilities, risk tolerances, the timing of risk management interventions, the tools and technique that will be used, and the reporting requirements."
46
Understand the purpose of a Risk Register.
"A record of identified risks relating to an initiative, including their status and history."
"The purpose of the Risk Register is to capture and maintain information on all of the identified threats and opportunities relating to the project."
47
Understand the concept of risk appetite/tolerances.
Risk appetite: "An organization's unique attitude towards risk taking that in turn dictates the amount of risk that it considers is acceptable."
Risk tolerance: "The threshold levels of risk exposure which, when exceeded, will trigger an Exception Report to bring the situation to the attention of the Project Board."
48
Recall the three types of issue.
Request for change: "a proposal for change to a baseline."
Off-specification: "something that should be provided by the project, but current is not (or is forecast not to be) provided. This might be a missing product or a product not meeting its specification."
Problem/concern: "Any other issue that the Project Manager needs to resolve or escalate."
49
Five typical activities of a configuration management procedure.
Planning - to what level do we do Change Management, at the Starting Up a Project phase.
Identification - Coding systems to provide each product with a unique identifier
Control - controlling changes during a project, to ensure no change without authorisation
Status Accounting - reporting all current and historical data for each product
Verification and Audit - all products are in line with the data in Configuration Items Records
50
Understand the purpose of the Change theme.
"To identify, assess, and control any potential and approved changes to the baseline."
51
Understand the purpose of a change budget and Change Authority.
Change budget: "The sum of money that the customer and supplier agree will be used to fund the cost of request for change, and possibly also their analysis costs."
Change Authority: Optional group appointed by the Project Board "to review and approve requests for change and off-specifications."
52
Understand the purpose of a Configuration Management Strategy.
"Used to identify how, and by whom, the project's products will be controlled and protected.". Also determines how the issues and changes will be handled
53
Understand the purpose of a Configuration Item Record.
"To provide a record of such information as the history, status, version, and variant of each configuration item, and any details of important relationships between them."
54
Understand the purpose of an Issue Report.
To capture and communicate information used for formal handling of issues.
- Issue identifier
- Issue type
- Date raised
- Raised by
- Issue Report author
- Issue description
- Impact analysis
- Recommendation
- Priority
- Severity
- Decision
- Approved by
- Decision date
- Closure date
55
Understand the purpose of an Issue Register.
To capture and maintain information on all of the issues that are being formally managed. Should be monitored by the PM on a regular basis.
- Issue identifier
- Issue type
- Date raised
- Raised by
- Issue Report author
- Issue description
- Priority
- Severity
- Status
- Closer date
56
Understand the purpose of a Product Status Account.
"Provides information about the state of products within defined limits. . . . It is particularly useful if the PM wants to confirm the version number of products."
57
Understand the recommended steps in the issue and change control procedure.
- Capture
- Example
- Propose
- Decide
- Implement
58
Recall the lines of authority and reporting channels between the four levels of management
Corp + Program Management Project Board Project Manager
Team Manager
Tolerances are downwards and Progress and Exceptions trend upwards
59
Recall the difference between event-driven and time-driven controls.
Event-driven controls: "Take place when a specific event occurs. This could be, e.g., the end of a stage, the completion of the PID, or the creation of an Exception Report."
Time-driven controls: "Take place at pre-defined periodic intervals."
"Monitoring and reporting requires a time-based approach, whereas control (decision making) is an event-based activity."
60
Understand the purpose of the Progress theme.
"To establish mechanisms to monitor and compare actual achievements against those planned; provide a forecast for the project objectives and the project's continued viability; and control any unacceptable deviations."
61
Understand the concept of management stages and the difference between management and technical stages.
"Management stages are partitions of the project with management decision points. A management stage is a collection of activities and products whose delivery is managed as a unit. As such, this stage is a subset of the project and, in PRINCE2 terms, is the element of work that the PM is managing on behalf of the Project Board at any one time."
Technical stages are a way of grouping work - it may overlap, usually linked to specialist skills.
62
Understand the factors to consider in identifying management stages.
From ILX:
To define the number and length of management stages a number of elements are considered.
These are:
- How far ahead is it sensible to plan
- Where are key decision points needed. These are often before large items of expenditure are sanctioned
- How much risk does the project contain? For example if the project is well understood and contains few risks a longer stage may be appropriate whereas on a large complex project carrying significant risk more stages may be required.
- Finally, consider how confident the Project Board and Project Manager are in proceeding may affect the length of a management stage but remember that too many short stages will increase the management overhead whilst too few larger stages could result in reduced control
63
Understand tolerance(s): where they may be usefully applied; in which management products they are documented and how management by exception applies to the difference levels of management.
"Tolerances are the permissible deviation above and below a plan's target for time and cost without escalating the deviation to the next level of management."
For the rest: see Table 10.1 on page 102 of the manual.
64
Understand the purpose of a Daily Log.
"A Daily Log is used to record informal issues, required actions, or significant events not caught by other PRINCE2 registers or logs. It acts as the project diary for the Project Manager."
65
Understand the purpose of a Work Package.
"A Work Package is a set of information about one or more required products collated by the Project Manager to pass responsibility for work or delivery formally to a Team Manager or team member."
66
Understand the purpose of a Lessons Log.
"The Lessons Log is a project repository for lessons that apply to this project or future projects. Some lessons may originate from other projects and should be captured on the Lessons Log for input to the project's strategies and plans. Some lessons may originate from within the project -- where new experience (both good and bad) can be passed on to others via a Lessons Report.
67
Understand the purpose of an End Stage Report.
"An End Stage Report is used to give a summary of progress to date, the overall project situation, and sufficient information to ask for a Project Board decision on what to do next with the project.
The Project Board uses the information in the End Stage Report in tandem with the next Stage Plan to decide what action to take with the project: for example, authorize the next stage, amend the project scope, or stop the project."
68
Understand the purpose of an End Project Report.
"An End Project Report is used during project closure to review how the project performed against the version of the PID used to authorize it. It also allows the:
- Passing on of any lessons that can be usefully applied to other projects.
- Passing on of details of unfinished work, ongoing risks, or potential product modifications to the group charged with future support of the project's products in their operational life.
69
Understand the purpose of a Lessons Report.
"The Lessons Report is used to pass on any lessons that can be usefully applied to other projects.
The purpose of the report is to provoke action so that the positive lessons become embedded in the organization's way of working, and that the organization is able to avoid any negative lessons on future projects."
70
Understand the purpose of a Checkpoint Report.
"A Checkpoint Report is used to report, at a frequency defined in the Work Package, the status of the Work Package."
71
Understand the purpose of a Highlight Report.
"A Highlight Report is used to provide the Project Board (and possibly other stakeholders) with a summary of the stage status intervals defined by them. The Project Board uses the report to monitor stage and project progress. The PM also uses it to advise the Project Board of any potential problems or areas where the Project Board could help."
72
Understand the purpose of an Exception Report.
"An Exception Report is produced when a Stage Plan or Project Plan is forecast to exceed tolerance levels set. It is prepared by the PM in order to inform the Project Board of the situation, and to offer options and recommendations for the way to proceed."
73
Recall the stated purpose and triggers of the SU process.
"To ensure that the prerequisites for Initiating a Project are in place by answering the question: do we have a viable and worthwhile project?"
Trigger: the Project Mandate.
74
Understand the objectives and context of the SU process.
Objective: "The aim is to do the minimum necessary in order to decide whether it is worthwhile to even initiate the project."
"The objective of the SU process is to ensure that:
- There is a business justification for initiating the project (documented in an outline Business Case)
- All the necessary authorities exist for initiating the project
- Sufficient information is available to define and confirm the scope of the project (in the form of a Project Brief)
- The various ways the project can be delivered are evaluated and a project approach selected
- Individuals are appointed who will understand the work required in project initiation and/or will take significant project management roles in the project
- The work required for project initiation is planned (documented in a Stage Plan)
- Time is not wasted initiating a project based on unsound assumptions regarding the project's scope, timescales, acceptance criteria, and constraints.
Context
Projects are finite and require a defined beginning.
75
Understand how the SU process supports the seven PRINCE2 principles.
1) Do the minimum until a viable business justification is stated and agreed.
2) Considering of project approach includes examination of lessons learned on other projects.
3) Executive and PM appointed, along with the project management team.
4) Creation of an Initiation Stage Plan.
5) (not so clear on manage by exception)
6) Creation of a Project Product Description.
7) Project approach considers tailoring PRINCE2.
76
Understand the purpose of a Project Brief.
"A Project Brief is used to provide a full and firm foundation for the initiation of the project."
77
Recall the stated purpose and triggers of the DP process.
"To enable the Project Board to be accountable for the project's success by making key decisions and exercising overall control while delegating day-to-day management of the project to the PM."
78
Understand the objectives and context of the DP process.
"To ensure that:
- There is authority to initiate the project.
- There is authority to deliver the project's products.
- Management direction and control are provided throughout the project's life, and that the project remains viable.
- Corporate or programme management has an interface to the project.
- There is authority to close the project.
- Plans for realizing the post-project benefits are managed and reviewed."
Context
Covers the activities of the Project Board (the management level above the PM).
79
Recall the stated purpose and triggers of the IP process.
"To establish solid foundations for the project, enabling the organization to understand the work that needs to be done to deliver the project's products before committing to a significant spend."
Triggered by Project Board authority to initiate a project.
80
Understand the objectives and context of the IP process.
Objectives
"To ensure that there is a common understanding of:"
- Reasons / benefits / risks
- Scope of activities and products
- How/when delivered & at what cost
- Who is involved in project decision making
- How to achieve required quality
- How to establish & control baselines
- How risks/issues/changes IDed, assessed, controlled
- How progress will be monitored and controlled
- Who needs info & how & when
- How PM method will be tailored
Context
"aimed at laying down the foundations in order to achieve a successful project"
81
Understand the purpose of the Project Initiation Documentation (PID)
"To define the project, in order to form the basis for its management and an assessment of its overall success. . . [G]ives the direction and scope of the project and (along with the Stage Plan) forms the 'contract' between the PM and the Project Board."
82
Recall the stated purpose and triggers of the Controlling a Stage process.
"To assign work to be done, monitor such work, deal with issues, report progress to the Project Board, and take corrective actions to ensure that the stage remains within tolerance."
83
Understand the objectives and context of the CS process.
Objectives
To ensure that:
- Attn is focused on products
- Risks/issues are controlled
- Business Case reviewed
- Agreed products are delivered acc. cost, time, effort, quality.
- PM team is focused on delivery within tolerances
Context
Describes the work of the PM in handling the day-to-day management of the stage.
84
Recall the stated purpose and triggers of the Managing Product Delivery process.
"To control the link between the PM and the Team Manager(s), by placing formal requirements on accepting, executing, and delivering project work."
85
Understand the objectives and context of the MP process.
Objectives:
"To ensure that
- Work on products allocated to the team is authorized & agreed.
- Team Managers, team members, and their suppliers are clear as to what is to be produced and what is the expected effort, cost, or timescales.
- The planned products are delivered to expectations and within tolerance
- Accurate progress information is provided to the [PM] at an agreed frequency and to ensure that expectations are managed."
Context
MP "views the project from the Team Manager's perspective, while the [CS] process views it from the [PM's] perspective."
86
Understand how the MP process supports the seven PRINCE2 principles.
1) ???
2) ???
3) Defined roles of PM and TM
4) Takes place within a stage
5) Tolerances in place
6) All about products
7) Implemented as per tailoring
87
Understand the activities within the MP process.
- Accept a Work Package
- Execute a Work Package
- Deliver a Work Package
88
Understand the responsibilities within the activities of the MP process.
Project Manager
• Authorizes Work Packages (CS process)
• Reviews Checkpoint Reports and Quality Register (CS process)
Team Manager
• Manages the development of the products
• Sends Checkpoints reports [MgmtPlaza]
89
Understand the use of the Work Package as input in the MP process.
Serves as the agreement between the PM and the TM: what is to be delivered, reporting requirements, constraints, procedures, and whether the WP is reasonable and can be achieved.
90
Understand the use of the Product Description as input in the MP process.
Provides the quality criteria to be me during execution of the Work Package.
91
Recall the stated purpose and triggers of the Managing a Stage Boundary (SB) process.
"To enable the Project Board to be provided with sufficient information by the Project Manager so that it can review the success of the current stage, approve the next Stage Plan, review the updated Project Plan, and confirm continued business justification and acceptability of the risks"
Triggered near the end of the current stage. May be triggered by out-of-tolerance situation, requiring Exception Plan.
92
Understand the objectives and context of the SB process.
Objectives
- Assure the Project Board that all products in the Stage Plan for the current stage have been completed and approved.
- Prepare the Stage Plan for the next stage.
- Review and, if necessary, update the PID
- Provide the info needed for the Project Board to assess the continuing viability of the project
- Record any info or lessons that can help later stages of this project and/or other projects
- Request authorization to start the next stage
IN CASE OF EXCEPTION:
- Prepare an Exception Plan as directed by the Project Board
- Seek approval to replace the Project Plan or Stage Plan for the current stage with the Exception Plan.
Context
"Predicated on dividing the project into management stages."
93
Understand how the SB process supports the seven PRINCE2 principles.
1) Biz case used to assess continuing viability
2) Lessons recorded as part of process
4) Embodies stage concept
5) Defined out-of-tolerance exception handling
6) Ensures products have been completed and approved
7) Follows tailoring
94
Understand the activities within the SB process.
- Plan the next stage
- Update the Project Plan
- Update the Business Case
- Report stage end
- Produce an Exception Plan
95
Understand the responsibilities within the activities of the SB process.
Project Manager
• Creates or updates all SB management documents
Team Manager
• Can assist Project Manager is all planning activities [MgmtPlaza]
96
Understand the use of the PID as input in the SB process.
Input as starting point and updated as needed (whether to strategies or controls, or to project approach).
97
Understand the use of the Project Plan as input in the SB process.
Used as input to understand the products to be produced in the next stage. Updated to reflect actuals and forecasts from the current stage plan. Also updated in light of risks or issues, and to include any new or changed products authorized by the Project Board.
98
Understand the use of the Business Case as input in the SB process.
As input, to compare any benefit reviews taken during the stage with expectations. As input to see if there are any changes to risk appetite. Updated in light of actual product delivery during current stage.
99
Understand the use of the Quality Management Strategy as input in the SB process.
Used as input to determine the quality standards required during the stage.
100
Understand the use of the Risk Management Strategy as input in the SB process.
Used to determine how risk will be controlled during the stage.
101
Understand the use of the Communication Management Strategy as input in the SB process.
Used to determine how and with whom project information will be communicated during the stage.
102
Understand the use of the Configuration Management Strategy as input in the SB process.
Determines how and by whom products will be versioned and controlled.
103
Understand the use of the Stage Plan as input in the SB process.
Used as input to track progress during the stage. Updated with actuals from the stage.
104
Understand the use of the Exception Report as input in the SB process.
If raised and agreed with the Project Board, will trigger the creation of an Exception Plan (either Project or Stage).
105
Understand the use of the Configuration Item Record as input in the SB process.
Updated as products are created during the current stage; created (or updated) for products to be created during the next stage.
106
Understand the use of the Product Status Account as input during the SB process.
Drives the review of quality mgmt activities for the stage and their results. Ensures all products ID'ed are completed and approved.
107
Understand the use of the Benefits Review Plan as input during the SB process.
Used to list any benefits review activities that have to be performed.
108
Understand the use of the Issue Register as input during the SB process.
As input, may drive corrective action. Updated as necessary in light of stage activities.
109
Understand the use of the Quality Register as input during the SB process.
As input, lists required quality activities for the next stage. Updated to reflect activities undertaken during the current stage.
110
Understand the use of the Risk Register as input during the SB process.
Reviewed as input to planning of next stage. Updated with risks encountered during the current stage, or to reflect actions taken during the stage.
111
Understand the use of the Lessons Log as input during the SB process.
Reviewed to determine affect on next stage. Updated with lessons obtained during the current stage.
112
Recall the stated purpose and triggers of the Closing a Project (CP) process.
"To provide a fixed point at which acceptance for the project product is confirmed, and to recognize that objectives set out in the original Project Initiation Documentation have been achieved (or approved changes to the objective have been achieved), or that the project has nothing more to contribute.
Triggered either by approaching end or request to close prematurely.
113
Understand the objectives and context of the CP process.
Objectives
- Verify user acceptance of the project's products
- Ensure that the host site is able to support the products when the project is disbanded
- Review the performance of the project against its baselines
- Assess any benefits that have already been realized, update the forecast of the remaining benefits, and plan for a review of those unrealized benefits
- Ensure that provision has been made to address all open issues and risks, with follow-on action recommendations.
Context
Having a finite extent (defined start and finish) makes a project a project.
114
Understand how the CP process supports the seven PRINCE2 principles.
1) Makes sure the biz justification was met
2) Makes sure that lessons are passed on
3) ???
4) Part of the final management stage
5) Premature close is a type of exception
6) Ensures that products have been delivered and can be handled in production.
7) ???
115
Understand the activities with CP process.
- Prepare planned closure
- Prepare premature closure
- Hand over products
- Evaluate the project
- Recommend project closure
116
Understand the responsibilities within the activities of the CP process.
Project Manager
• Create or update all CP management documents
• End Project Report, Lessons Report, Benefits Review Plan, etc.
Project Support
• Assist the Project Manager (CIR documents, all records, etc.) [MgmtPlaza]
117
Understand the use of the Product Status Account as input in the CP process.
```
Requested from Project Support to determine which products
- have been approved
- remain in dev
- given approved concessions
- have yet to be started
- need to be made safe
- may be useful to other projects
Used to make sure that products meet their requirements
```
118
Understand the use of the PID as input in the CP process.
Used as input to compare final status with original, approved intention of the project. That is: used as input for project evaluation.
119
Understand the use of the Benefits Review Plan as input in the CP process.
Checked to ensure that post-project activities are assigned and will be handled.
120
Understand the use of the Project Product Description as input in the CP process.
Used as input to confirm that the project delivered what was promised.
121
Understand the use of the Lessons Log as input in the CP process.
Used as input to a lessons report so that lessons can be passed on. Closed.
122
Understand the use of the Project Plan as input in the CP process.
Input to be updated with actuals from the final stage.
123
Understand the use of the Issue Register as input in the CP process.
Used as input to the End Project Report. Closed.
124
Understand the use of the Risk Register as input in the CP process.
Used as input to the End Project Report. Closed.
125
Understand the use of the Quality Register as input in the CP process.
Used as input to the End Project Report. Closed.
126
Understand the use of the Risk Management Strategy as input in the CP process.
???
127
Understand the use of the Configuration Management Strategy as input to the CP process.
Determines how all project information will be secured and archived.
128
Understand the use of the Communication Management Strategy as input to the CP process.
Review to determine which organizations or interested parties need to know that the project is closing.
129
Understand the use of the Quality Management Strategy as input to the CP process.
Reviewed to evaluate how effective the strategy was in the creation of the products.
130
What is not in scope of Prince2?
Specialist Aspects,
Detailed Techniques,
Leadership Capability
