Get Started. It's Free
or sign up with your email address
Rocket clouds
Agile Programme Management (AgilePgM®) study guide mind map by Mind Map: Agile Programme Management (AgilePgM®) study guide mind map

1. Current DSDM® Consortium products family

1.1. DSDM® Consortium products history in a nutshell

1.1.1. positioning AgilePgM® in comparision to other Agile approaches

2. AgilePgM® Governance Levels (3)

2.1. Business Strategy Team

2.1.1. Responsibilities

2.1.1.1. Overall strategy, direction and goals of the business

2.1.1.2. Agreement and review of Business Case for programme with respect the Business Strategy

2.1.1.3. Prioritisation of the programme against other initiatives

2.1.1.4. Approval of programme vision

2.2. Programme Board

2.2.1. Responsibilities

2.2.1.1. Approval of Prioritised Benefits

2.2.1.2. Agreement of Programme and Tranche Plans

2.2.1.3. Agreement of project high-level requirements / scope with respect to the programme's Business Case

2.2.1.4. Agreement and control of resourcing and budgets Technical consistency across the programme Communication consistency across the programme

2.3. Capability Teams

2.3.1. Responsibilities

2.3.1.1. As defined by the project / activity

2.4. Portfolio Management Office

2.4.1. A portfolio management office is the team responsible for the management of initiatives within the organisation

2.4.2. Responsibilities

2.4.2.1. Prioritisation of programmes and other projects in line with agreed business priorities

2.5. Programme Strategy Office

2.5.1. Assists the programme in planning, reporting and administration. Also helps to implement consistent best practice across the programme

2.5.2. Responsibilities

2.5.2.1. Provides a support function and does not have management responsibilities over the programme

2.6. Project Strategy Office

2.6.1. Also helps to implement consistent best practice across large projects

2.6.2. Assists the project in planning, reporting and administration

2.6.3. Responsibilities

2.6.3.1. Provides a support function and does not have management responsibilities over the project(s)

3. AgilePgM® - an iterative, incremental, adaptive agile programme management method and framework from UK for general (not industry specific e.g. IT or Engineering) agile programme management. AgilePgM™ is closely aligned with methods AgilePM®, dedicated to generic agile project management and DSDM®, dedicated to agile project management of software development projects. Same as AgilePM®, AgilePgM® was created by DSDM® Consortium - www.dsdm.org

3.1. AgilePgM™ first version (v1.0) was published in 09.2014.

4. AgilePgM® Principles (5)

4.1. 1. Programme goals are clearly and continuously aligned to Business Strategy

4.1.1. Program will have an overall vision

4.1.2. Vision is based on business strategy at the time of definition

4.1.2.1. Vision should be updated throgh the programme

4.1.3. Programme team members must understand the business strategy, priorities and needs

4.1.4. Business Case must be established

4.1.5. All projects must be aligned with programme's Business Case

4.1.6. Maintain continuous business sponsorship and commitment

4.1.7. Review points within the programme

4.1.8. Frequent review and validation of the programme

4.2. 2. Benefits are realised incrementally and as early as possible

4.2.1. Incremental enablement of delivered capabilities

4.2.1.1. Which leads to realisation of programme benefits

4.2.2. Business can benefit early from the outcomes

4.2.3. Programme team can learn from experience and adapt

4.2.4. Include feedback from earlier deliveries

4.2.5. Prioritise benefits ASAP

4.2.5.1. So benefits can be deliered in incremental way ASAP

4.2.6. Prioritise the capabilities that can deliver the benefits to reflect the benefits prioritisation

4.2.7. Plan in detail only relative short term capabilities

4.2.7.1. Planning will need review and update after each capability enablement

4.2.8. Understand that some benefits will add more value to the business when compared with the costs of delivering the benefits

4.3. 3. Governance focuses on creating a coherent capability

4.3.1. Programme will be executed as a series of projects

4.3.2. In Agile environment projects are allowed to be carried out autonomously, with minimal intervention

4.3.2.1. Yet agile projects has to incorporate changes from programme

4.3.3. Projects must be aligned with programme vision

4.3.3.1. Projects (and other initiatives) must be constantly synchronised to ensure that they can deliver a capability that is coherent across the organisation

4.3.3.2. Projects are reviewed continaully to ensure their alignment with programme vision

4.3.4. High level requirements (HLR) e.g. Objectives and Themes of each project are aligned with programme vision

4.3.5. Project teams have to be empowered to deliver the outputs satisfying high level requirements

4.3.6. Project outputs are converted to capabilities that ultimately lead to benefits realisation

4.4. 4. Decision-making powers are delegated to the lowest possible level

4.4.1. In Agile environments decisions has to be made quickly and effectively

4.4.2. Empower project team members

4.4.3. Decisions can be made at the lowest possible level

4.4.3.1. Decisions regarding overall goal and vision has to be mage by Programme

4.4.3.2. Decisions hot regarding high level requirements must be made at the lowest possible level of the relevant project

4.4.4. Programme governance needs to be clearly defined early in the programme and effectively communicated clearly to all stakeholders

4.5. 5. Agile programmes are iterative and have the ability to contain both Agile (at least 1) and non-Agile projects

4.5.1. Through the programme, iterative techniques and practices can be used

4.5.2. Some of the projects within the programme may be run using non Agile techniques

4.5.2.1. Team has to understand how the different types of projects can be executed successfully within the programme

4.5.3. Programme is planning and enabling benefits iteratively and incrementally by means of a series of projects and that the projects are seen as autonomous

5. AgilePgM® Philosophy (1)

5.1. "An agile programme delivers what is required when it is required - no more, no less"

5.2. Programme management is concerned with the optimal resourcing of multiple related projects.

5.3. Programme will:

5.3.1. Constantly be aligned to business strategy, mission, vision

5.3.2. Adapt to emerging changes in the business environment

5.3.3. Deliver projects outputs incrementally, realising benefits ASAP

5.3.4. Do only enough to fulfil the vision

5.3.4.1. right-engineering (no under-engineering or over-engineering)

5.3.4.2. no gold plating

5.3.5. Provide and establish governance model that empowers the most appropriate people

5.3.6. Provide iterative environments

5.3.7. Ensure active and on-going involvement of stakeholders

5.4. "Project management is like juggling three balls – time, cost and quality. Program management is like a troupe of circus performers standing in a circle, each juggling-three balls and swapping balls from time to time." G. Reiss

6. This freeware, non-commercial mind map (aligned with the newest version of AgilePgM®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the AgilePgM® method and as a learning tool for candidates wanting to gain AgilePgM® qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

6.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com

6.1.1. http://www.miroslawdabrowski.com

6.1.2. http://www.linkedin.com/in/miroslawdabrowski

6.1.3. https://www.google.com/+MiroslawDabrowski

6.1.4. https://play.spotify.com/user/miroslawdabrowski/

6.1.5. https://twitter.com/mirodabrowski

6.1.6. miroslaw_dabrowski

7. AgilePgM® Official publications

7.1. Agile Programme Management Handbook

7.1.1. http://dsdm.org/product/agile-programme-management-handbook

7.1.2. The most important, key position on AgilePgM™ preparing for Foundation and Practitioner exams

8. AgilePgM® Lifecycle (1) with Phases (6)

8.1. a.k.a. DSDM Agile Programme Framework (AgilePgM)

8.2. Lifecycle is both iterative and incremental

8.2.1. Increment is called "tranche"

8.3. Programme Feasibility and Programme Foundations are sequential phases

8.4. 1. Pre-Programme

8.4.1. Objectives

8.4.1.1. Describe business transformation

8.4.1.2. Identify Business Programme Owner (PBO) and Busines Change Owners (BCOs)

8.4.1.3. Derive a programme from the existing portfolio within the organisation

8.4.1.4. Confirm alignment of programme vision with business strategy, vision, misson etc.

8.4.1.5. Scope, Plan, Resource Programme Feasibility phase (not the whole programme)

8.4.1.6. Check if programme is worth pursuing to Programme Feasibility phase

8.4.1.7. Determining the initial key roles

8.4.1.7.1. Business Programme Owner (BPO)

8.4.1.7.2. Business Change Owner (BCO)

8.4.2. Do not not into details

8.4.3. Justify the programme is needed and worth investigation further

8.5. 2. Programme Feasibility

8.5.1. Objectives

8.5.1.1. Confirm programme is consistient with business strategy and potentially achievable

8.5.1.2. Refine outline vision of programme

8.5.1.3. Outline high-level benefits of business transformation

8.5.1.4. Produce initial outline costs for the programme

8.5.1.5. Confirm programme structure

8.5.1.6. Develop outline plan for Programme Foundations

8.5.1.7. Develop outline governance strategy

8.5.1.8. Assess organisation readiness for use of Agile techniques on the programme

8.5.2. As short as possible

8.5.3. Justify the programme's inclusion in the organisation's portfolio of initiatives

8.6. 3. Programme Foundations

8.6.1. Objectives

8.6.1.1. Baseline programme vision

8.6.1.2. Create initial Business Architecture Model

8.6.1.3. Define initial Roadmap for realising vision

8.6.1.4. Define and prioritise the high-level benefits and capabilities

8.6.1.5. Confirm the Business Case for the programme

8.6.1.6. Establish governance model that is Agile

8.6.1.7. Develop Programme Plan

8.6.1.8. Describe, assess and manage risk

8.6.1.9. Identify and categorise key stakeholders

8.6.1.10. Plan initial tranche(s)

8.6.1.11. Obtain approval to proceed to first tranche

8.6.1.12. Gain funding for at least the first tranche

8.6.2. Establish firm foundations for the programme

8.6.3. Ensure that the programme will realise sufficient business benefits

8.6.4. Address key areas of vision, design and architecture, governance, culture and communication

8.6.5. Do not plan all tranches

8.6.6. One of the main goals of Programme Foundations is to plan first tranche (of projects)

8.6.6.1. Identify and plan the projects and initiatives to build the capabilities

8.6.6.1.1. Projects may be sequential or much often overlapping

8.6.6.1.2. Plan only high-level scope of each project in alignment to programme Business Case

8.6.6.1.3. Determine projects inter-dependencies

8.6.6.1.4. Set outline budget

8.6.6.1.5. Set outline start and end dates

8.6.6.2. Identify and plan the activities required to build and enable the capabilities

8.7. 4. Capability Evolution

8.7.1. Objectives

8.7.1.1. Plan, initiate and execute projects to deliver the capabilities

8.7.1.1.1. a.k.a. Sprints / Timeboxes on the programme level

8.7.1.2. Iteratively and incrementally enable consistent subsets of capabilities into the live organization

8.7.1.2.1. a.k.a. Deployments on the programme level

8.7.1.3. Deliver capabilities as soon as posible through projects with delivering outputs regularly and often

8.7.1.4. Run projects within tranches (tranches can be overlapping)

8.7.1.5. Measure the benefits being released through the capabilities

8.7.2. Contains 2 main processes

8.7.2.1. Capability Enablement

8.7.2.2. Benefits Realisation

8.8. 5. Tranche Review

8.8.1. Objectives

8.8.1.1. Confirm the sufficient capability has been delivered for the tranche

8.8.1.1.1. a.k.a. Review on programme tranche level

8.8.1.2. Plan next tranche in sufficient detail

8.8.1.3. Review the programme and update plans and other Programme Foundations products as necessary based on experiences from the current tranche

8.8.1.4. Review lessons learnt

8.8.1.4.1. a.k.a. Retrospective on programme tranche level

8.8.2. Update BAM after tranche review to incorporate newest changes and lessons learnt

8.8.3. Update governance structure and / or processes after tranche review to incorporate newest changes and lessons learnt

8.9. 6. Programme Close

8.9.1. Objectives

8.9.1.1. Confirm that sufficient capability has been delivered

8.9.1.2. Close the programme

8.9.1.3. Gather lessons learnt for the future initiatives

8.9.1.3.1. a.k.a. Retrospective on programme level

8.9.1.4. Review the programme against its vision and Business Case

8.10. Benefits Management

8.10.1. Starts when capabilities have been enabled

8.10.2. An iterative and incremental on-going process that starts early in the programme where benefits definition commences

9. AgilePgM® method consists of: 1 Philosophy, 5 Principles, 10 Roles, 6 Phases, 3 Governance Levels, 20 Products (a.k.a. documentation).

9.1. Download: AgilePgM® Project Phases vs Products (documentation) vs Roles vs Reponsibilites Matrix (PDF)

10. AgilePgM® Products / Artifacts (20)

10.1. The types of Products

10.1.1. Evolutionary products

10.1.1.1. Initial produced in outline in a specific phase

10.1.1.2. Continued to evolve, becoming more detailed as the programme progresses

10.1.2. Milestone products

10.1.2.1. Created in a phase and typically fulfill a specific purpose

10.1.3. Foundation products

10.1.3.1. Fundamental drivers of the programme

10.1.3.2. Normally baselined during the Programme Foundations

10.1.3.3. Set the basis of all programme activity

10.2. Legend

10.2.1. Icon

10.2.1.1. This means that selected products are Gateway Products, which can be used for Yes / No decision if project should be continued

10.2.2. Orange

10.2.2.1. Business focused products

10.2.3. Blue

10.2.3.1. Programme management focused products

10.2.4. Green

10.2.4.1. Outputs / Capabilities / Benefits focused products

10.2.5. Violet

10.2.5.1. Benefits management focused products

10.3. Vision Statement

10.3.1. Define clearly and concisely the desired future state of the organisation

10.3.2. Used to validate all decisions, plans, activities and communcations carried out during the programme

10.3.3. Captures the intended state of the organisation following the transformation programme

10.3.4. Expresses the desired future state of the organization

10.3.5. Aligned to business strategy

10.3.6. Needs to be agreed with the Business Strategy Team

10.3.7. Relatively short and easily understood

10.3.8. Responsiblities

10.3.8.1. Owned by:

10.3.8.1.1. Business Programme Owner (BPO)

10.3.8.2. Agreed by:

10.3.8.2.1. Business Strategy Team (outside the AgilePgM)

10.3.8.3. Compiled and Updated by:

10.3.8.3.1. Business Programme Owner (BPO) and peers

10.3.8.4. Contributions from:

10.3.8.4.1. Programme Team, Business Change Owners (BCOs)

10.4. Business Case

10.4.1. Compares the benefits to result from the programme with the risks and costs of realizing the benefits

10.4.2. Provides justification that the programme is worthwhile

10.4.3. Responsiblities

10.4.3.1. Owned by:

10.4.3.2. Agreed by:

10.4.3.3. Compiled and Updated by:

10.4.3.4. Contributions from:

10.5. Business Architecture Model (BAM)

10.5.1. Describes the desired future structure of the organization

10.5.2. Describe in outline the potential incremental step changes that could lead to the final structure

10.5.3. The BAM will normally cover (a.k.a. POTI model):

10.5.3.1. Processes

10.5.3.1.1. Processes and business models of operations and functions

10.5.3.1.2. Operational costs and performance levels, KPIs

10.5.3.2. Organisational structure

10.5.3.2.1. Organisation structure, staffing levels, roles and skills

10.5.3.2.2. Culture, style, supply chain

10.5.3.3. Technology

10.5.3.3.1. Technology, IT systems, tools, equipment, machinery

10.5.3.3.2. Buildings and accommodation, infrastructure

10.5.3.4. Information

10.5.3.4.1. Information and data required for future business operations and performance measurement

10.5.3.4.2. Current State, Intermediate Future States, Final Future State

10.6. Programme Plan

10.6.1. Roadmap

10.6.1.1. Describes the incremental steps (tram to realise the vision of the programme

10.6.1.2. Forms part of the Programme Plan

10.6.1.3. Describes a schedule of tranches for the incremental enablement of consistent capabilities

10.6.2. Benefits Realisation Plan

10.6.2.1. Describes how the benefits identified within the Prioritised Benefits Definition will accrue as capabilities are enabled Describes how benefits will be measured Forms part of the Programme Plan

10.7. Tranche Plan

10.7.1. Defines the MoSCoW-prioritised capabilities, projects and costs for the tranche

10.7.1.1. Not define the projects in detail

10.7.2. Produced for each incremental step in the programme

10.7.3. Produced immediately prior to the commencement of the tranche

10.7.4. Defines the Timeboxes for the projects as subsequent projects and activities may be dependent on their completion

10.8. Tranche Review Record

10.8.1. Describe what has been achieved during the tranche and is used as a foundation for future tranche plans and to update the overall Programme Plan

10.8.2. Produced at the end of a tranche

10.8.3. An output of the Tranche Review

10.9. Programme Control Pack

10.9.1. Programme Control Pack comprises reports, documents and logs related to the ongoing status of the programme

10.9.2. Programme Risk Log

10.9.3. Programme Issues Log

10.9.4. Communication Log

10.9.5. High-Level Project Status

10.9.6. Benefits Assessment

10.10. Stakeholder Engagement Strategy

10.10.1. Defines approach to be taken towards all groups of stakeholders

10.10.2. Includes internal and external stakeholders

10.10.3. Stakeholder Engagement Strategy should be is reviewed and updated often, but at least during Tranche Review

10.11. Communication Plan

10.11.1. Aimed predominantly at the communication requirements for a given tranche

10.11.2. Each plan will identify how and when key events will be communicated to stakeholders

10.12. Governance Strategy

10.12.1. Documents the way in which governance will be carried out on the programme

10.13. Capabilities

10.14. Benefits

10.15. Prioritised Benefits Definition

10.15.1. Defines benefits predicted to emerge from the change

10.15.2. Defines how benefits realisation will be measured

10.15.3. Can be decomposed into sub-benefits

10.15.4. Benefits should be prioritised using MoSCoW rules

10.16. Programme / Tranche Approach Questionalire (PTAQ)

10.16.1. Original product of DSDM

10.16.2. Provides set of questions to be asked when conducting agile programme

10.16.3. Helps assess how Tranches should be applied in specific environment

10.16.4. Helps explore characteristics of the project and organization in context how AgilePgM should be applied

10.16.5. Helps identify potential areas of risk that should be considered and addressed moving forwards

10.16.6. Helps to understand how the critical success factors are addressed

11. AgilePgM® Roles (10)

11.1. Legend

11.1.1. Orange

11.1.1.1. Business intrest roles representing the business view

11.1.1.2. Typically taken by business personnel

11.1.2. Blue

11.1.2.1. Management intrest roles representing the management / leadership view

11.1.2.2. Managing or facilitating the management/leadership aspects of the programme

11.1.3. Green

11.1.3.1. Technical intrest roles representing the technical view

11.1.3.2. Contributing to technical consistency, design or development

11.2. Roles can comprise one or more individuals and sometimes a group of individuals

11.3. An individual or group can take more than one role

11.4. Programme Management Team (PMT)

11.4.1. Programme Management Team comprises of roles that for the most part are involved both in business strategy and programme management

11.4.2. Roles are accountable for oversight and must direct and strategically guide the transition of the organisation towards its new future state

11.4.3. Roles are supported in administrative affairs by the Programme Support Office

11.4.4. Agile Programme Management Team (PMT) characteristics

11.4.4.1. Strong communication skills

11.4.4.2. Confidence and trust in their teams, giving them real empowerment

11.4.4.3. Clarity of vision and ability to share it with others

11.4.4.4. Determination to achieve the vision

11.4.4.5. Strong focus on priorities

11.4.4.6. Respect for everyone involved in the programme

11.4.4.7. Ability to inspire and motivate

11.4.4.8. Positive attitude at all times and an innate ability to be diplomatic

11.4.4.9. Passion and pride in what they do

11.4.4.10. Lateral thinking and the ability to find innovative ideas

11.4.4.11. Ability to focus on developing people

11.4.4.12. Willingness to take calculates risks

11.4.5. Business Programme Owner (BPO)

11.4.5.1. Programme Champion

11.4.5.2. The most senior programme-level business role

11.4.5.3. Responsibilities

11.4.5.3.1. Overall strategic programme direction

11.4.5.3.2. Continuous and ongoing commitment to the programme

11.4.5.3.3. Provision of funds

11.4.5.3.4. Ensuring the programme vision and goals are aligned with organisational / business strategy

11.4.5.3.5. Managing the interface to key stakeholders

11.4.5.3.6. Ensuring efficient, effective and rapid decision-making process

11.4.5.3.7. Responding rapidly to escalate issues

11.4.5.4. Mappings to other roles in other methods ...

11.4.5.4.1. Managing Successful Programmes (MSP®)

11.4.6. Programme Manager (PgM)

11.4.6.1. Responsibilities

11.4.6.1.1. Incremental and iterative programme design and planning

11.4.6.1.2. Monitoring the programme progress agains it's design and plan

11.4.6.1.3. Ensuring project outputs are appropriate (meeting the programme vision with ability to deliver benefits)

11.4.6.1.4. Managing risks and issues

11.4.6.1.5. Creating autonomous projects environment

11.4.6.1.6. Managing project interdependencies and inter-projects conflicts

11.4.6.1.7. Managing and communicating with all stakeholders

11.4.6.1.8. Working together with Stakeholder Engagement Coordinator ensuring clear and continuous communication

11.4.6.1.9. Incremental and iterative programme design and planning

11.4.7. Business Change Owners (BCOs)

11.4.7.1. Realising benefits that the new programme capabilities will provide

11.4.7.2. Implementing change in the business area

11.4.7.3. Senior member of a specific business area

11.4.7.4. Responsibilities

11.4.7.4.1. Defining benefits for their area of responsibility

11.4.7.4.2. Ensuring projects are aligned to the programme vision

11.4.7.4.3. Creating and monitoring the plan for benefits realisation

11.4.7.4.4. Reacting to business change

11.4.7.4.5. Leading change in their business area

11.4.7.4.6. Managing stakeholders within their area of business

11.4.7.4.7. Ensuring efficient, effective and rapid decision-making process

11.4.7.4.8. Responding rapidly to escalate issues

11.4.7.5. Characterisics

11.4.7.5.1. Incremental approach

11.4.7.5.2. Constant review benefits against current business

11.4.7.5.3. Instils empowernmanet and commitment

11.4.7.5.4. Strong communication of the programme vision

11.4.7.5.5. Gentle steering of project teams towards the progremme vision

11.4.7.6. May be supported by

11.4.7.6.1. Programme Change Architect

11.4.7.6.2. Stakeholder Engagement Cooridnator

11.4.7.6.3. Change Agents

11.4.7.7. Mappings to other roles in other methods ...

11.4.7.7.1. Managing Successful Programmes (MSP®)

11.5. Capability Delivery Team (CDT)

11.5.1. Deals with:

11.5.1.1. delivery of the products/outputs

11.5.1.2. business architectural design and consistency

11.5.1.3. technical design and consistency

11.5.1.4. stakeholder engagement and commitment

11.5.2. Programme Technical Architect (PTA)

11.5.2.1. Responsibilities

11.5.2.1.1. Agreeing and ultimately controlling the programmes architectures

11.5.2.1.2. Agreeing technical environments

11.5.2.1.3. Advising and coordinating each project's technical activities

11.5.2.1.4. Identifying and owning programme-level architectural and other technical risks

11.5.2.1.5. Ensuring compliance with appropriate norms, standards, technical best practices

11.5.2.1.6. Resolving design / technical differences between project members across projects

11.5.2.1.7. Facilitating and ensuring communication between teams on the coherence of the developing capabilities and so avoiding technical inconsistencies

11.5.3. Programme Change Architect (PCO)

11.5.3.1. Responsibilities

11.5.3.1.1. Creating the Business Architecture Model (BAM)

11.5.3.1.2. Advising and guiding on business architecture

11.5.3.1.3. Monitoring the achievement of the Business Architecture Model (BAM)

11.5.3.1.4. Identifying and owning programme-level business architecture risk

11.5.3.1.5. Resolving differences between project teams with respect to business architecture as defined in the Business Architecture Model (BAM)

11.5.3.1.6. Facilitating and ensuring communication between project teams on the coherence of the changes to achieve the new business architecture

11.5.4. Stakeholder Engagement Coordinator (SEC)

11.5.4.1. Onward-facing and inward-looking

11.5.4.2. The key purpose of outward stakeholder engagement Sis to ensure that stakeholders remain informed about, engaged with, and positive towards programme

11.5.4.2.1. This becomes important when a tranche is about to start as all stakeholders to be involved in the tranche need to be aware that they are required, ready to participate and committed to their part of it

11.5.4.3. Stakeholder Engagement Coordinator has two aspects:

11.5.4.3.1. Engagement and communication outward from the programme to stakeholders

11.5.4.3.2. Engagement of stakeholders into the programme and internal communication within the programme

11.5.4.4. Agile programme will generally require more business resource to be involved in the programme than using more traditional techniques

11.5.4.4.1. This is one of the reason why stakeholder engagement is so important to the success of the programme that a separate role is defined in AgilePgM

11.5.4.5. Responsibilities

11.5.4.5.1. Creating and maintaining the Stakeholder Engagement Strategy

11.5.4.5.2. Ensuring active, ongoing engagement with all stakeholders

11.5.4.5.3. Creating and maintaining the Tranche Communication Plan

11.5.4.5.4. Identifying and owning programme-level stakeholder engagement activities

11.5.4.5.5. Ensuring all outward communications are aligned to programme vision

11.5.4.5.6. Facilitating and ensuring effective communication between teams and stakeholders within the programme

11.5.5. Project Teams (PTs)

11.5.5.1. Responsibilities

11.5.5.1.1. not defined in AgilePgM™

11.5.5.1.2. In general responsible for successful project delivery for start to the finish in alignment to the programme vision

11.6. Supporting Roles

11.6.1. Deals with:

11.6.1.1. assistance and guidance to the programme

11.6.2. Works on ad hoc basis throughout the programme lifecycle

11.6.3. Change Agents (CAs)

11.6.3.1. Responsibilities

11.6.3.1.1. Change management specialist input

11.6.3.1.2. Assisting Business Change Owners (BCOs)

11.6.3.1.3. Implementing business processes to realise the benefits of new capabilities

11.6.3.1.4. Implementing organisational changes required to realise the benefits of new capabilities

11.6.4. Specialists (Ss)

11.6.4.1. Responsibilities

11.6.4.1.1. Consulting input

11.6.4.1.2. Advising and guiding the programme stakeholders / decision-makers

11.6.5. Programme Support Office (PSO)

11.6.5.1. Responsibilities

11.6.5.1.1. not defined in AgilePgM™

11.6.5.1.2. Assistance

12. Interactive AgilePgM® Glossary

12.1. Interactive AgilePgM® Glossary

13. Portfolios, Programmes & Projects

13.1. DSDM AgilePgM framework in context

13.2. Relationship between Programme and Projects

13.3. Example programme with three tranches

14. AgilePgM® Planning

14.1. There are two important concepts to confer when planning for Agile programmes:

14.1.1. Change is inevitable and plans must be able to deal with change

14.1.2. Experience from executing plans will change the future plans

14.2. Planning needs to

14.2.1. Be iterative and incremental

14.2.2. Set the vision for the long term

14.2.3. Divide delivery into increments to realise benefits as early as possible

14.2.4. Prioritise delivery based on the relative value of benefits and on interdependencies

14.2.5. Plan the immediate future in some detail

14.2.6. Plan the mid and long term in outline, knowing that it will change

14.2.7. Review and update plans based on experience of delivery

14.2.8. Review and update plans based on the current business landscape

14.3. Overlapping tranches to ensure that benefits can be realised as soon as possible

14.3.1. This implies that the capabilities within each of the overlapping tranches are not interdependant

14.4. MoSCoW Prioritisation