Free PRINCE2 7 Foundation Exam Flashcards

Principles, people, practices, processes and the project context. PRINCE2 6 had four integrated elements built around seven 'themes'. Version 7 renamed themes to practices and promoted people to an element in its own right. Any answer option that says 'themes' or 'four integrated elements' is a version 6 distractor.

Benefits, cost, time, quality, scope, sustainability and risk. Sustainability is the new seventh aspect in version 7 - PRINCE2 6 listed only six. These are also the seven performance targets that tolerances are set against at every management level.

Ensure continued business justification; learn from experience; define roles, responsibilities and relationships; manage by stages; manage by exception; focus on products; tailor to suit the project. Note the version 7 rewording of the first and third: 'ensure' was added, and 'relationships' was added. Unless all seven are applied, it is not a PRINCE2 project.

There must be a justifiable reason to invest at the start and it must remain justifiable through to completion, so the business case is reviewed at every stage boundary and whenever an exception arises. If the project stops being desirable, viable or achievable, PRINCE2 expects it to be changed or closed prematurely rather than allowed to run on.

At least two: the initiation stage plus one or more delivery stages. The project board authorizes only one stage at a time, and the stage plan for the next stage is produced near the end of the current one during managing a stage boundary. Management stages are the board's decision points, not the team's work packages.

Processes, terminology, management products and roles can be tailored to the project's environment, size, complexity, importance, delivery method, team capability and level of risk - but the seven principles are never tailored away. PRINCE2 7 names three delivery approaches: linear-sequential, iterative-incremental and hybrid. 'Predictive' and 'agile' are not the version 7 syllabus labels.

A project exists to deliver change, and that change lands on how people work, so success depends on team capability, the relationships between team members, and the people affected. 'People' covers those working on the project and the relationships between them, plus those impacted by it - not only the project management team. This element did not exist in PRINCE2 6.

The project ecosystem is the project itself and those directly involved in delivering it, spanning the business, user and supplier interests. The organizational ecosystem is the wider environment the project sits inside, including people affected by the change who hold no project role. A stakeholder is any individual, group or organization that can affect, be affected by, or perceive itself to be affected by the project.

Management is about directing the work: planning it, allocating it, controlling it and delivering within agreed tolerances. Leadership is about influencing people: setting direction, building trust, motivating and creating the conditions in which a temporary team performs. PRINCE2 roles need both, and the syllabus expects you to explain the difference rather than treat the two words as synonyms.

Change management is how an organization transitions from its current state to the target state so the project's outputs are actually adopted and benefits are realized. It is supported by the change management approach, held within the PID. Do not confuse it with change control, which belongs to the issues practice and governs changes to the project baseline.

The means and frequency of communication with, and feedback from, the project ecosystem, establishing a controlled two-way flow of information that supports alignment and stakeholder engagement. It sits within the PID. How a team communicates also depends on whether it is co-located, remote or hybrid.

Competence and capability matched to the work with gaps identified and closed; diversity of skills and perspectives; cultural intelligence to work across the organizational ecosystem; deliberate team building to create trust and compatible ways of working; and social cohesion whether the team is co-located, virtual or hybrid. Project teams are temporary and cross organizational boundaries, so a temporary leader finds authority harder to exercise than in an established business team.

The change management approach and the communication management approach, both held within the project initiation documentation. If an answer option offers a register or a report here it is wrong: the people element's products are approaches, not records.

An aggregation of the management products created or updated during initiation - the business case, project plan, the management approaches, project management team structure, role descriptions, project controls and tailoring decisions. Its purpose is to give the project board what it needs to authorize the project, and it then becomes the baseline the project is measured and reported against. It is a logical set of information, not necessarily one document.

The project log is PRINCE2 7's single repository for the project's records: the daily log, lessons log, issue register, risk register, quality register and product register. PRINCE2 6 held these as separate management products, so grouping them under one project log is a version 7 change and a frequent exam trap.

To establish mechanisms to judge whether the project is, and remains, desirable, viable and achievable, so decisions about continued investment can be made. Read the wording carefully: the practice is about supporting ongoing investment decisions, not about writing a document once at the start.

Output: the tangible or intangible deliverable of an activity. Outcome: the result of the change, normally affecting real-world behaviour and circumstances. Benefit: the measurable improvement resulting from an outcome that the investing organization perceives as an advantage. Dis-benefit: the measurable decline resulting from an outcome that it perceives as negative. The chain runs output, then outcome, then benefit, and benefits contribute to business objectives.

Develop: the outline business case is written pre-project in starting up a project, then expanded into the full business case in initiating a project. Maintain: it is checked and updated at every stage boundary and whenever an exception arises. Confirm benefits: benefits are confirmed during delivery and again after closure - post-project benefit confirmation sits outside the project lifecycle and belongs to the business, not the project manager.

The project brief, the business case itself, and two approaches inside the PID: the benefits management approach and the sustainability management approach. The benefits management approach defines the actions that confirm outcomes are achieved and benefits realized; the sustainability management approach is new in version 7 and defines the actions, reviews and controls that will meet the project's sustainability performance targets.

Business, represented by the executive, who owns the business case and value for money. User, represented by the senior user, who is accountable for capturing requirements and for specifying and tracking benefits. Supplier, represented by the senior supplier, who is accountable for the quality of the delivered products and the technical integrity of the project. All three interests must be represented on the project board.

The executive is appointed by the business as the single point of accountability for the project, and that accountability cannot be delegated. There can only be one executive, and the role cannot be combined with the project manager role. The executive secures funding and owns the business case and continued business justification, including longer-term environmental, social and economic impact.

Business layer: the commissioning party, which provides the project mandate, identifies the executive and sets the project-level tolerances. Directing: the project board. Managing: the project manager. Delivering: team managers and team members. Only the last three form the project management team - the business layer sits outside the project.

Project assurance checks the project independently of the project manager on behalf of the project board; board members are accountable for assurance of their own interest and may appoint others to carry it out. Project support provides administration, meeting facilitation, tooling, planning and register-keeping, is the project manager's responsibility and can be delegated. The two must be kept separate so assurance stays independent.

To facilitate communication and control by defining the products to be delivered (the what) and the means to deliver them - the who, the how, the where, and estimates of the when and how much - so as to satisfy the business case (the why). The four plan types are the project plan, stage plan, team plan and exception plan.

Write a project product description (for the project plan only); create a product breakdown structure; write product descriptions (for all levels of plan); create a product flow diagram. Product-based planning starts from the products and derives the work breakdown structure, estimates and schedule from them - not the reverse.

The planning horizon is the limit of how far ahead it is realistic to plan in detail. PRINCE2 works within it by keeping the project plan at a high level and detailing only the imminent stage in a stage plan, produced near the end of the previous stage. This gives the project board a genuine go or no-go decision at each boundary instead of committing to detail nobody can yet forecast.

The plan itself (project, stage, team or exception), the project product description and the work package description. A work package description describes how one or more products will be produced and delivered, and is the instrument that formally passes responsibility for work from the project manager to a team manager or team member, together with the tolerances that work must stay within.

To document the user's requirements of the project's products and to establish the means by which they will be met. Quality is the degree to which a set of inherent characteristics fulfils its requirements, so quality in PRINCE2 means fitness against agreed specifications - not being expensive, elaborate or gold-plated.

User's quality expectations: a statement of the quality the user expects of the project product, captured early. Acceptance criteria: a prioritized list of criteria the project product must meet before the user will accept it. Quality specifications: the quality measures applied by those performing quality control on an individual product, and the levels the finished product must meet. Expectations come first and are refined into acceptance criteria.

Quality planning captures quality specifications for the products and generates the product descriptions and quality management approach. Quality control monitors the actual products and delivery activities to check compliance with standards and reduce causes of poor performance. Quality assurance gives independent confidence that products will meet their specifications when tested under quality control, and is typically a function managed independently of the project team - which is why it is not the project manager's job.

The product description, the quality management approach within the PID, and two records inside the project log: the quality register and the product register. The quality management approach names the quality techniques, standards, roles and responsibilities; the quality register records planned and completed quality activities.

An uncertain event or set of events that, should it occur, will affect the achievement of objectives. It is measured by combining the probability of the threat or opportunity occurring with the magnitude of its impact on objectives. A risk can be a threat or an opportunity, so treating risk as only bad news is a wrong answer. Assessment can also weigh proximity (how soon it might occur) and velocity (how quickly the impact would bite).

Identify: review the plan's context and objectives so threats and opportunities can be found. Assess: prioritize risks and assess the combined risk profile. Plan: decide risk responses and monitoring arrangements. Implement: establish monitoring and execute actions for priority or realized risks. Communicate: share risk information across the project ecosystem and with external stakeholders - this runs throughout rather than only at the end.

Risk appetite: the amount and type of risk the business is willing to take in pursuit of its objectives. Risk tolerance: a measurable threshold for the tolerable range of outcomes for an objective at risk. Risk budget: money set aside to fund responses, including contingent plans. Risk exposure: the degree to which an objective is at risk - a neutral term, since exposure can be positive. The risk owner is responsible for responding to a risk; the risk action owner, also called the actionee, carries out the agreed actions.

Avoid a threat or exploit an opportunity; reduce a threat or enhance an opportunity; transfer the risk; share the risk; accept the risk; prepare contingent plans. Only the first two pairs are worded as threat-or-opportunity specific, and mixing them up - for example pairing 'avoid' with an opportunity - is the classic error.

To collect and assess issues and control changes to the project's baseline. In PRINCE2 7 issue management encompasses change control, so there is no separate 'change' theme as there was in PRINCE2 6. An issue is any event relevant to the project that requires project management consideration.

Problem: an issue with an immediate negative impact. Concern: an issue whose timing and impact still need to be assessed. Event external to the project: something outside that may affect it. Business opportunity: unanticipated positive consequences for the project or user organization. Request for change: a proposal to change the baseline. Off-specification: a product that will not meet its quality specifications. The last two are the ones that touch the project baseline.

Capture: determine the issue type and severity or priority, and register it. Assess: assess the impact on the business case and project risk profile and recheck severity. Recommend: identify and evaluate options and recommend one. Decide: approve, reject, ask for more information, or request an exception plan. Implement: take corrective action and update records and the project baseline if needed. Anything beyond the project manager's delegated authority is escalated to the project board or change authority.

A project baseline is the currently approved versions of the management and project products that are subject to change control. A change is a modification to any approved product in that baseline. A change budget is money or authorized constraint set aside in a plan to cover authorized changes. The project board can delegate authority for approving changes, within limits, to a change authority so routine changes do not need a board decision. Supporting products: the issue management approach in the PID, the issue register in the project log, and the issue report.

To establish mechanisms to monitor and compare actual achievements against those planned, to provide a forecast for the project's objectives and continued viability, and to control any deviation that causes an exception. It runs on a plan-do-check-act cycle covering management levels and tolerances, the two types of control, reviewing and reporting progress and lessons, forecasting, escalating, and using data.

Tolerance is the permissible deviation from a plan before it must be escalated; it establishes limits of delegated authority. An exception is a situation where a deviation beyond agreed tolerance is forecast. The business layer sets project tolerance for the project board, the board sets stage tolerance for the project manager, and the project manager sets work package tolerance for the team manager. Each level manages by exception within its tolerance and escalates upward only when a breach is forecast.

Event-driven controls occur when a specific event happens: the end of a stage, completion of the PID, creation of an exception report, or an organizational event such as a financial year end. Time-driven controls occur at predefined intervals: highlight reports for the project board and checkpoint reports on a work package. Classifying a highlight report as event-driven, or an end stage report as time-driven, is a common mistake.

Checkpoint report: team manager to project manager, on work package progress, time-driven. Highlight report: project manager to project board at agreed intervals, time-driven. End stage report: project manager to project board at a stage boundary. Exception report: project manager to project board when a tolerance breach is forecast. End project report: project manager at closure. Lessons report: produced whenever lessons should be passed on, typically at a boundary or at closure. The daily log and lessons log sit inside the project log.

Purpose: ensure the prerequisites for initiating a project are in place, answering 'do we have a viable and worthwhile project?'. Triggered by the project mandate, it happens pre-project. It appoints the executive and project manager and then the wider project management team, assesses previous lessons, prepares the outline business case, selects the project approach, assembles the project brief and plans the initiation stage, then requests project initiation.

Purpose: 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 to the project manager. Its five activities are authorize initiation, authorize the project, authorize a stage or exception plan, give ongoing direction, and authorize project closure. It runs from the end of starting up a project through to closure - the board never does day-to-day management.

Purpose: establish solid foundations for the project so the business understands the work needed to deliver the project product before committing significant expenditure or resources. It agrees tailoring requirements and the management approaches, establishes project controls, prepares the project plan and the full business case, and assembles the project initiation documentation used to request project authorization. It occupies the initiation stage.

Purpose: assign work, monitor it, handle issues, report progress to the project board and take corrective action so the stage stays within the tolerances the board set. Activities: authorize a work package, evaluate work package status, receive completed work packages, evaluate stage status, capture issues and risks, escalate issues and risks, take corrective action and report highlights. This is the project manager's day-to-day process.

Purpose: control the link between the project manager and the team manager by agreeing the requirements for acceptance, execution, reporting and delivery of specialist products. Its three activities are accept a work package, execute a work package and evaluate a work package. It is the team manager's process, and checkpoint reports originate here.

Purpose: give the project board enough information to review the success of the current stage, approve the next stage plan, review the updated project plan and confirm continued business justification and acceptable risk. It runs at or close to the end of every stage except the final one, since closing a project handles that. It is also used at any time, including during the final stage, to prepare an exception plan.

Purpose: provide a fixed point at which acceptance of the project product is confirmed and the objectives set in the PID are recognized as achieved - or, where there is a premature close, ensure the project is closed in an orderly way rather than abandoned. Objectives include checking user acceptance, ensuring the business can support the products, reviewing performance against baselines, assessing benefits already realized and updating the benefits management approach for post-project reviews, and making follow-on action recommendations for open issues and risks.