Free MSP-PRACTITIONER Practice Test

The Issue Register records the details of each individual issue (e.g., when it was raised, what it is, and its agreed categorization). It does not contain the procedural rules for issue management. Those rules—“how issues will be identified, captured and assessed”—are defined in the Issues Management Approach, not the register itself. Therefore option C is the only item that will not appear in an Issue Register.

A. Date issue was raised – A mandatory field in the register to track when the issue emerged.
B. Description of issue – Core information required for understanding and analysing the issue.
D. Categorization of issue – The register records the agreed category/type to aid analysis and reporting.

1. AXELOS

“Managing Successful Programmes” 5th ed.

TSO

2020.

• Section 9.4 “Issues management approach” p.158: “Defines how issues will be identified

captured and assessed.”

• Appendix A

Table A.5 “Issue Register – typical data fields” p.311: lists Date raised

Description

Category

etc.; procedural rules are not included.

2. AXELOS

“Managing Successful Projects with PRINCE2” 6th ed.

TSO

2017.

• Appendix A.20.1 “Issue Register” p. 492: fields include Issue ID

Date raised

Type/Category

Description; no process details.

MSP defines programme management as “the coordinated organization, direction and implementation of a dossier of projects and transformation activities to achieve outcomes and realise benefits of strategic importance.” The wording in the question is a near-verbatim extract of this official definition, making Programme Management the only precise and directly applicable option.

A. Project management governs a single, temporary endeavour—not a coordinated dossier of multiple projects and transformational change.
C. Portfolio management focuses on selecting and prioritizing projects/programmes to meet strategic objectives, not on directing and implementing them.
D. Organizational management is a broad term for running an enterprise; it is not a formally defined discipline for managing coordinated change initiatives.

1. AXELOS

“Managing Successful Programmes – 5th Edition

” Glossary

definition of Programme Management

p. 319

ISBN 978-01-1396-9473.

2. AXELOS

“Management of Portfolios (MoP) – Guidance

” §1.1

p. 3 (portfolio definition vs. programme).

3. PMI

“A Guide to the Project Management Body of Knowledge (PMBOK) 7th Ed.

” §1.2

p. 7 (project definition contrasts with programme).

4. MIT OpenCourseWare

“15.783J Product Design and Development

” Lecture 2 notes

slide 4 (project vs. programme distinction in engineering management).

A risk register is a central document where all identified risks are recorded, along with their probability, impact, potential responses, and mitigation strategies. It provides the framework for managing risks throughout a project or program, setting the stage for identifying and addressing potential issues. 

While an issue register documents problems encountered during a project, it doesn't define the overall risk management context. Issues are specific problems that arise during execution, whereas risks are potential threats that could impact the project's objectives. 

MSP classifies “political and societal-change programmes” as those seeking wide cultural or behavioural shifts in the population. The guide notes that when the desired outcome depends on “long-term societal effects that may not materialise for many years and are outside the programme’s direct control, the probability of success is comparatively low.” (MSP 5e, §3.3.4 & Table 3.2). Therefore, of the scenarios listed, aiming for long-term societal effects carries the lowest likelihood of programme success.

A. New legislation gives a clear, mandatory compliance target, increasing achievability.
B. Modifying existing legislation still provides statutory authority and measurable objectives, boosting success odds.
C. Altering the public-service delivery model is largely within government control and yields nearer-term, trackable benefits.

1. AXELOS. Managing Successful Programmes

5th ed.

TSO

2020.

• §3.3.4 “Political and societal change programmes”

p.31-32.

• Table 3.2 “Comparative likelihood of programme success”

p.33 (lists long-term societal outcomes as lowest).

In MSP, “Deliver the Capabilities” is the process that coordinates projects so the programme can obtain the capabilities described in the Blueprint. Its documented inputs (AXELOS, MSP 2011 ed., Table 14.1 “Inputs to Deliver the Capability”) are the approved Project Dossier, Blueprint, Tranche/Programme Plans, Benefit information and other governance baselines. Project outputs are created by, not supplied to, this process; they are listed in the same table as outputs of the process. Therefore, Project outputs are not an input, whereas the Project Dossier, Business Case (the live justification baseline carried forward into every process), and Blueprint all precede and guide capability delivery.

B. Project dossier – listed as an explicit input to Deliver the Capability (MSP 2011 ed., p. 197).
C. Business Case – retained as a baseline and referenced in every transformational-flow process, hence an input (MSP 2011 ed., p. 90 & p. 197).
D. Blueprint – provides the target-state design and is an input to Deliver the Capability (MSP 2011 ed., p. 197).

1. AXELOS. “Managing Successful Programmes

” 2011 edition

Table 14.1 “Inputs to Deliver the Capability”

pp. 197-198.

2. AXELOS. “Managing Successful Programmes

” 2011 edition

§6.3 “Programme Business Case – live baseline”

p. 90.

3. University of Warwick WMG. “Programme Management (MSP) Lecture Notes

” session 5

slide 18 – Inputs to Deliver the Capability.

In MSP, the transformational flow is the set of governance processes that takes a programme “from its initial conception, through delivery of new capability, to the achievement of the desired outcomes and programme closure.” It provides the route-map across the whole programme lifecycle and comprises the processes Identify Programme, Design the Outcomes, Plan Progressive Delivery, Deliver the Capability, Embed the Outcomes, and Close the Programme (MSP 5th ed., §4). Hence option C most precisely states this definition.

A. Describes the MSP principle “learn from experience,” not the transformational flow.
B. Refers to establishing leadership, teams, and controls—content of the “Organization” theme.
D. Defines a programme itself; transformational flow is the lifecycle, not the temporary structure.

1. AXELOS. Managing Successful Programmes

5th ed.

2020

Chapter 4 “Transformational flow

” pp. 79-83.

2. AXELOS. MSP® Framework and Philosophy White Paper

2021

p. 6: “Transformational flow provides a route through the lifecycle from concept to closure.”

3. University of Westminster MSc Project Management course notes

Lecture 8 “MSP Transformational Flow

” slide 3.

MSP defines a dis-benefit as “a measurable decline resulting from an outcome perceived as negative by one or more stakeholders.” It is the mirror image of a benefit (a measurable improvement) and is recorded so that its impact can be forecast, tracked and managed within the programme’s business case and benefits management approach.

A. Defines a benefit, not a dis-benefit; opposite concept.
B. Describes a risk (an uncertain event that may be positive or negative).
C. Describes an issue (an unplanned event that has already occurred and needs action).

1. AXELOS. Managing Successful Programmes (MSP) 5th Ed.

TSO

2020.

• Glossary

p. 278 – “Dis-benefit: a measurable decline resulting from an outcome perceived as negative…”.

• Glossary

p. 278 – “Benefit: a measurable improvement resulting from an outcome perceived as an advantage…”.

• Glossary

p. 279 – “Risk: an uncertain event or set of events that

should it occur

will affect objectives…positive or negative.”

• Glossary

p. 279 – “Issue: an event that has happened

requiring management action.”

In MSP, the very first “Identify” process turns the initial programme mandate into a Programme Brief. The guide states that the brief is “developed from the information provided in the programme mandate” and that it “provides the foundation for developing the full programme business case in the Define process.” Thus, the Programme Brief is both produced from the mandate and used as the key input to create the Business Case.

A. Programme preparation plan – Drawn up after the Programme Brief to plan the Define work; it is not produced directly from the mandate nor used to build the Business Case.
B. Blueprint – Designed in the Define process to describe future capabilities; not an output of the mandate and not the Business Case input.
D. Programme management plan – Also produced in Define to control delivery; neither derived directly from the mandate nor the precursor to the Business Case.

1. AXELOS. Managing Successful Programmes

5th ed.

2020. Section 4.3.1 “Identify – Develop the Programme Brief”

p. 61–62: “Develop the programme brief from the information provided in the programme mandate … The programme brief informs development of the programme business case.”

2. AXELOS. Managing Successful Programmes

2011 ed.

ch. 12 “Identify the Programme

” p. 119–120: “The programme brief is created from the mandate … and provides input to the outline business case.”

MSP (5th ed.) product-responsibility tables show the Programme Mandate is issued by corporate or strategic management before an SRO is appointed; therefore the SRO cannot be accountable for confirming it. The SRO becomes accountable for the Programme Brief, while the Programme Manager is “Responsible” for both the Vision Statement and the Blueprint (the SRO remains “Accountable” for each).

B. SRO is shown as “Accountable” for the Programme Brief – statement is true.
C. RACI table lists Programme Manager “Responsible” for Vision Statement – statement is true.
D. Programme Manager is “Responsible” for Blueprint with Architect/BCM support – statement is true.

1. AXELOS. Managing Successful Programmes

5th Edition

2020:

• Appendix A

Table A.1 “Programme documents – responsibility assignment (RACI)” – Vision Statement & Blueprint (PM=R

SRO=A).

• Appendix A

Table A.5 “Pre-programme phase products” – Programme Mandate (Corporate/Strategic Management = A).

• Sec. 4.2 “Identify the programme” – notes SRO typically appointed after Mandate approval

and accountable for Programme Brief.

2. University of Birmingham MSc PM Lecture Slides “MSP Product Responsibilities”

2022

slide 18 – mirrors AXELOS RACI for Mandate

Brief

Vision

Blueprint.

MSP states that during ‘Defining a Programme’ the programme team develops the detailed benefits management products, including the Benefits Management Strategy, Benefits Profiles and the Benefits Map. The map is built once the vision and preliminary list of benefits (from ‘Identifying a Programme’) are available, so that cause-and-effect linkages between programme outputs, intermediate outcomes and strategic objectives can be modelled before delivery starts. It is therefore created in ‘Defining a Programme’, not earlier or in later delivery/realization stages.

A. Identifying a Programme – only outlines/high-level benefits are captured; no detailed mapping is carried out.
C. Managing the Tranches – governs delivery of projects; benefits map should already exist to guide this work.
D. Realizing the Benefits – focuses on tracking and harvesting planned benefits, using the previously created map.

1. AXELOS

“Managing Successful Programmes”

2011 edition

Appendix A

Table A.1 – Documents produced in each transformational flow; Benefits Map listed under ‘Defining a Programme’ (pp. 226-229).

2. AXELOS

“Managing Successful Programmes”

2011

Ch. 9.3.2 ‘Benefits management information products’ – description of Benefits Map creation during programme definition (pp. 135-136).

3. Cranfield University School of Management course notes

“Programme Management & MSP”

Lecture 4: Transformational Flow – slide set shows Benefits Map developed in Definition phase (Section 4.2).