Hard Difficulty Questions

A Request for Change always has a cost and time impact, while an Off-specification never does.

Why it fails: Neither type invariably carries cost and time impact; an Off-specification can require remediation effort, and a Request for Change may be absorbed within tolerance. The actual distinction is that a Request for Change proposes modifying baselined products, while an Off-specification reports a product failing to meet its specification.

A Request for Change is recorded in the Issue Register, while an Off-specification is recorded in the Risk Register.

Why it fails: Both are issue types recorded in the Issue Register, not the Risk Register; risks are uncertain future events, while these are current issues. A Request for Change proposes an alteration to baselined products, whereas an Off-specification describes a product that has not met its agreed specification.

A Request for Change does not require authorization, while an Off-specification does.

Why it fails: Both a Request for Change and an Off-specification are issues that require the Project Manager's authorisation before action, so this distinction is false. Requests for Change are proposed modifications awaiting approval, whereas Off-specifications record something delivered that fails to meet its specification.

Approve the change using the Change Budget

Why it fails: Approval authority is bounded by scope as well as budget; a configuration item outside the Change Authority's remit falls to the Project Board regardless of cost. The Change Budget funds approved changes, it does not confer decision rights. Escalate the request to the Project Board for a decision.

Reject the change because it affects a configuration item

Why it fails: Rejection is unwarranted: the change falls within the delegated budget and merely sits outside the Change Authority's configuration-item scope. The Project Manager should escalate to the Project Board, which owns decisions on out-of-scope items; the scope mismatch tempts an incorrect blanket refusal.

Ask the Change Authority to decide

Why it fails: The Change Authority's delegated budget authority does not extend to configuration items outside its defined scope, so it cannot approve this request. Escalating to the Project Board, which retains authority over out-of-scope items, is required; the budget match tempts misrouting.

SU involves the Project Board; IP involves the Project Manager only

Why it fails: Both processes involve the Project Board and Project Manager; the Project Board authorises SU's project mandate and IP's PID, while the Project Manager drafts both. This option is tempting because SU is brief and manager-led in practise, but role involvement is not the axis separating the two processes.

SU is optional; IP is mandatory

Why it fails: Both SU and IP are mandatory in every PRINCE2 project; SU is only skipped when a project mandate already exists, which is a tailoring decision, not an optional process. This is tempting because SU can be shortened, but the mandatory/optional axis does not distinguish the two processes.

SU produces the PID; IP produces the Project Brief

Why it fails: The outputs are reversed: SU produces the Project Brief, and IP produces the PID. This option is tempting because both documents are baselined early, but naming them the wrong way round misstates which process generates each product, so it cannot describe the actual difference.

An RFC only applies to the Business Case; an Off-spec applies to any product

Why it fails: An RFC can affect any product, including the Business Case, and an Off-spec can likewise concern any product, so the scope split described does not exist. It is tempting because Business Case changes do arrive as RFCs, but that is one example rather than an exclusive rule.

An RFC is always accepted; an Off-spec is always rejected

Why it fails: Acceptance or rejection is a decision taken by the change authority after impact analysis, not an inherent property of either record type; an RFC can be rejected and an Off-spec can be approved. It is tempting because RFCs often proceed to approval while Off-specs frequently trigger corrective action.

An RFC is raised by the Project Board; an Off-spec is raised by the Project Manager

Why it fails: Both records can originate from anyone, including team members or suppliers; the Project Board and Project Manager are recipients or decision-makers, not fixed originators. It is tempting because the Project Board authorises changes and the Project Manager often raises Off-specs, but neither is a defining rule.

To reduce the workload of the Project Manager

Why it fails: The separation exists to give the Project Board independent assurance that the project remains viable, not to lighten the Project Manager's workload. It is tempting because assurance does absorb some monitoring activity, but reduced workload is a side effect, not the purpose of splitting the roles.

To avoid the need for quality reviews

Why it fails: Separating the roles exists so assurance is independent of the manager producing the work; it does not remove quality reviews, which remain part of the quality theme. It is tempting if assurance is misread as replacing review activity, but the split addresses independence, not the elimination of reviews.

To ensure that the Project Board has direct control over the team

Why it fails: Project Assurance advises and monitors on the Project Board's behalf; it does not place the team under the Board's direct control, which would bypass the Project Manager's delegated authority. It is tempting because assurance reports to the Board, but that reporting line is not line management of the team.

The risk owner is always a member of the Project Board; the risk actionee is always a team member

Why it fails: The risk owner is not restricted to the Project Board; any project role can own a risk, while the risk actionee is the person tasked with implementing the agreed response, not necessarily a team member. This option is tempting because the risk owner is accountable for the risk, which might be assumed to require Board-level authority, but PRINCE2 explicitly separates accountability from execution, so the actionee could be any resource.

The risk owner identifies the risk; the risk actionee assesses it

Why it fails: Risk identification and assessment belong to the risk management approach and the project manager, not to these roles. The owner is accountable for managing the risk; the actionee implements the response. This option swaps those duties for activities neither role performs.

There is no difference; they are the same role

Why it fails: PRINCE2 separates the roles: the risk owner manages a specific risk, while the risk actionee carries out the agreed response. They may be the same person, but the responsibilities differ, so treating them as one role misstates the method's accountability model.

An RFC affects the project scope; an Off-Spec affects the project schedule

Why it fails: Both an RFC and an Off-Specification can affect scope, schedule, cost and risk; the real distinction is that an Off-Spec is a product failing to meet its agreed specification, whereas an RFC proposes a change to baselined products. It tempts because scope and schedule are the usual change dimensions.

An RFC is handled via the issue register; an Off-Spec is handled via the quality register

Why it fails: Both RFCs and Off-Specifications are issue types recorded in the issue register; the quality register tracks quality activities and results instead. It tempts because Off-Specs relate to quality expectations, and would be correct if the question asked where quality management records are maintained.

An RFC is raised by the Project Board; an Off-Spec is raised by the Project Manager

Why it fails: Anyone may raise an RFC or an Off-Specification, including team members and users; the Project Board authorises changes while the Project Manager manages issues. It tempts because the Board approves RFCs, and would be correct if the question asked who authorises a change rather than who raises the issue.

An RFC is always approved by the Change Authority, while an Off-spec is always escalated to the Project Board

Why it fails: Approval routes are not fixed: an RFC may be handled by the Change Authority or escalated, and an Off-spec is likewise assessed and may be approved or escalated. The distinction concerns what each document records — a proposed change versus a deviation from a baselined product — not a rigid approval path.

An RFC is for a change in scope, while an Off-spec is for a quality defect

Why it fails: An Off-spec records a product failing to meet its agreed requirements, which is not confined to quality defects; it can cover any unmet specification, and an RFC can address more than scope. The genuine difference is that an RFC proposes a change to a baseline, while an Off-spec reports an existing deviation.

An RFC is raised by the Project Manager, while an Off-spec is raised by the Senior User

Why it fails: Both an RFC and an Off-spec may be raised by any role, including team members; the raiser is not the distinguishing factor. This option tempts because PRINCE2 assigns distinct owners to some products, but here the difference lies in whether the request changes scope or corrects a failure to meet a requirement.

An RFC is a deviation from the original specification; an Off-spec is a suggestion for improvement

Why it fails: An RFC proposes a change to baselined products, while an Off-spec records something not delivered as specified; this option reverses both definitions. It is tempting because both are issue types raised during delivery, and it would be correct only if the stem asked which issue type captures a proposed modification to an agreed baseline.

There is no difference; they are both types of issues

Why it fails: RFCs and Off-specifications are distinct issue types: an RFC proposes a change to baselined products, whereas an Off-spec records a product not meeting its specification. It is tempting because both are raised as issues and follow similar assessment, and it would be correct only where the question asked what the two have in common.

An RFC is used to update the Stage Plan; an Off-spec is used to update the Business Case

Why it fails: Both RFCs and Off-specifications are issue types that may trigger plan and Business Case updates; they are not defined by which document they update. It is tempting because approved changes can affect plans and justification, and it would be correct only where the question asked what an approved issue may cause to be updated.

Both are the same

Why it fails: RFCs and Off-specs are distinct PRINCE2 records: one proposes a change, the other reports a product not meeting specification. Treating them as identical is tempting because both feed change control and may trigger corrective action, but they differ in origin, purpose and the information they capture.

An Off-spec is to change something; an RFC is a product not meeting specification

Why it fails: The definitions are reversed: an RFC seeks approval to change a baseline, while an Off-spec records a product failing to meet its specification. The pairing sounds plausible because both concern change and deviation, yet swapping them inverts the actual distinction the question tests.

Both are handled only by the Project Board

Why it fails: Project Board involvement differs by severity and delegated tolerances, not by request type; routine RFCs and Off-specs are handled at lower levels. Escalating both to the Board is tempting because it sounds like strong governance, but it ignores the tolerance-based delegation that determines who actually authorises each.

The risk owner identifies the risk; the risk actionee implements the response

Why it fails: The risk owner is accountable for managing the risk and its response, not for identifying it; identification is a separate activity. The actionee carries out the allocated response tasks. This option misassigns identification, which belongs to whoever raises the risk, so it misstates the accountability split.

The risk owner monitors the risk; the risk actionee updates the risk register

Why it fails: Monitoring is part of the owner's accountability, but the actionee executes the response tasks rather than maintaining the risk register; that register is administered by the project manager. This option misassigns register upkeep, so it fails to capture the owner-actionee distinction.

There is no difference; the terms are synonymous

Why it fails: PRINCE2 defines the roles distinctly: the owner is accountable for managing the risk, while the actionee performs the allocated response tasks. Treating them as synonymous removes that accountability split. This would only hold if the method assigned no separate responsibility for executing responses.

An RFC is about scope changes; an Off-spec is about quality issues

Why it fails: An RFC covers any proposed change to baseline products, including scope, cost and schedule, while an Off-specification records a delivered product that fails to meet its agreed specification. Conflating RFCs with scope and Off-specs with quality misstates both definitions and their PRINCE2 purposes.

An RFC is always approved by the Project Board; an Off-spec is approved by the Project Manager

Why it fails: Approval authority is not the distinguishing axis: both RFCs and Off-specs are approved by the Project Board, since both are change requests against baselined products. The option confuses this with tolerance deviations, which the Project Manager may handle within stage tolerances.

An RFC is raised by the Project Manager; an Off-spec is raised by the team

Why it fails: Originator is not the defining difference; anyone — including the Project Manager or team — may raise either an RFC or an Off-spec. The real distinction lies in whether the change is a proposed modification (RFC) or a discovered non-conformance with a baselined product (Off-spec).

Team Manager

Why it fails: The Team Manager manages a team's work package delivery and reports to the Project Manager, so cannot independently assure the project's management; Project Assurance performs that independent check for the Project Board. It is tempting because Team Managers monitor progress, but their reporting line compromises independence.

Project Manager

Why it fails: The Project Manager runs the project day to day, so cannot give independent assurance on their own management. That independence belongs to Project Assurance, which reports to the Project Board. The role is tempting because the Project Manager owns delivery of the project's products and controls progress, but self-review cannot provide the objectivity the question demands.

Project Support

Why it fails: Project Support provides administrative and tooling assistance to the project manager, not independent assurance; that duty belongs to Project Assurance, which reports to the Project Board. It is tempting because support staff handle governance documentation, yet their remit lacks the independence assurance requires.

An RFC is raised by the Project Manager; an Off-spec is raised by the Team Manager

Why it fails: Both an RFC and an Off-spec may be raised by anyone, including the Project Manager or Team Manager, so the raiser is not the distinguishing factor. The real distinction is that an RFC proposes a change to an agreed baseline, while an Off-spec reports something that should have been delivered but was not. Attributing each to a specific role is tempting but inaccurate.

An RFC is used in the Managing Product Delivery process; an Off-spec is used in the Controlling a Stage process

Why it fails: Both RFCs and Off-specs are handled as issues within the Controlling a Stage process, so process placement does not separate them. The distinction is their nature: an RFC requests a change to an agreed product or baseline, whereas an Off-spec reports a failure to deliver something the baseline required. Tying each to a process is tempting but wrong.

An RFC always requires approval; an Off-spec never requires approval

Why it fails: Both RFCs and Off-specs are issues that require a decision, and both may be approved or rejected depending on their impact and the delegated authority. The genuine distinction is that an RFC proposes a change to an agreed baseline, while an Off-spec reports a failure to meet it. The approval claim is tempting but false.

A Request for Change is always raised by the Project Manager; an Off-specification is raised by the Team Manager

Why it fails: Both a Request for Change and an Off-specification may be raised by anyone, including team members; PRINCE2 does not assign them to fixed roles. It is tempting because the Project Manager typically approves changes and the Team Manager reports issues, but that concerns handling, not authorship.

There is no difference; they are synonyms

Why it fails: They differ in intent: a Request for Change proposes altering an approved baseline, while an Off-specification reports something delivered or forecast that does not meet its specification. It is tempting because both enter the same issue register and follow similar assessment, but their triggers and required responses are distinct.

A Request for Change requires a change budget; an Off-specification is always free

Why it fails: Neither document inherently requires or avoids cost; a Request for Change may be free and an Off-specification may need funding to rectify. It is tempting because changes often draw on the change budget, but PRINCE2 classifies them by intent, not by financial impact.

The risk owner identifies the risk; the risk actionee assesses it

Why it fails: Identification and assessment are steps in the risk management procedure, not role definitions. The risk owner owns the risk and its response; the risk actionee implements the assigned action. This option would only hold if PRINCE2 assigned identification and assessment to separate named roles, which it does not.

There is no difference

Why it fails: They are distinct roles.

The risk owner is responsible for the budget; the risk actionee is responsible for the schedule

Why it fails: Budget and schedule are not the dividing line. The risk owner owns the risk and its response, while the risk actionee executes the allocated action. Splitting by budget versus schedule would only make sense if PRINCE2 defined these roles by financial and timeline duties, which it does not.

Risk owner manages the risk; risk actionee monitors it

Why it fails: The risk owner owns the risk and is accountable for managing it, including monitoring; the actionee carries out assigned response actions. This option swaps the two roles' responsibilities, so it misstates the accountability split PRINCE2 defines.

Risk owner is the same as risk actionee

Why it fails: PRINCE2 distinguishes the roles: the owner is accountable for the risk throughout its life, while the actionee performs specific allocated tasks. Treating them as identical removes the accountability separation the method requires for effective risk management.

Risk owner identifies risks; risk actionee assesses them

Why it fails: Identification and assessment are activities within the risk management cycle, not the defining difference between the roles. The owner is accountable for the risk overall; the actionee executes assigned response actions on the owner's behalf.

A Request for Change is always raised by the Project Board, while Off-specification is raised by the Project Manager

Why it fails: Either role may raise both; the Project Board does not exclusively own Requests for Change, and the Project Manager does not exclusively own Off-specifications. The distinction lies in whether the product fails to meet its specification versus a proposed alteration to the baseline. Raising authority is tempting because governance roles differ, and it would matter when assigning approval responsibility.

A Request for Change requires a change budget, while Off-specification does not

Why it fails: Both are handled through change control; the change budget is not what separates them. The real axis is that an Off-specification describes something the project should deliver but currently does not, whereas a Request for Change proposes altering the baseline. A change budget is tempting because changes often consume it, and it would be relevant when funding approved changes.

Off-specification is a type of risk, while Request for Change is a type of issue

Why it fails: Off-specification is a specific PRINCE2 issue type, not a risk; both it and Request for Change sit within the issue register. It tempts because risks and issues are both logged in PRINCE2 registers, so the categories can appear interchangeable when classifying project events.

A Request for Change is raised by the Project Manager, while an Off-specification is raised by the Team Manager

Why it fails: Who raises it does not define the difference; both can be raised by anyone.

A Request for Change is for future products, while an Off-specification is for completed products

Why it fails: Both can apply to any product at any stage.

A Request for Change is about scope changes, while an Off-specification is about schedule changes

Why it fails: Off-specifications are about products not meeting specification, not schedule.

A Request for Change is raised by the team; an Off-specification is raised by the Project Board

Why it fails: Both are typically raised by anyone, including team members; the Project Board authorises changes rather than raising them. The real axis is intent: a Request for Change proposes modifying an agreed baseline, while an Off-specification flags a product already delivered outside its specification.

There is no difference; they are synonyms

Why it fails: A Request for Change seeks approval to alter baselined products, whereas an Off-specification reports a product that already fails to meet its specification. Treating them as synonyms erases that distinction, which matters because each triggers different PRINCE2 change-control and exception-reporting routes.

A Request for Change is always about cost; an Off-specification is about quality

Why it fails: A Request for Change can concern scope, time, quality or cost, and an Off-specification is a specific product failing to meet its agreed specification, not a quality-versus-cost split. Conflating them with cost and quality misstates the actual distinction between proposed change and reported non-conformance.