AgilePgM Lifecycle

 Agile Programme framework does not mandate any specific Agile method for running projects – merely a framework where any method can be incorporated at the project / initiative level.

Benefits management process is integrated throughout the lifecycle

Feasibility and foundations are sequential

foundations is likely to be run as a iterative and incremental project – with defined time boxes and a minimum defined set of outputs to be produced.

Capability evolutions phase 

areas capability enablement and benefits realisation

these are potentially overlapping phases. Constantly providing feedback – as soon as a capability is delivered this can enable some formal benefits realisation.

Pre-programme

In most orgs programmes exist as part of a portfolio of other programmes or projects.

Pre-programme formalises a proposal and places it in context of other work to be carried out.

Objectives:

1.       To describe business transformation to be carried out

2.       Identify the business programme owner and business change owners

3.       Confirm vision aligns to strategy

4.       Scope plan and resource the feasibility phase

5.       To justify if the programme is worth investigating

Important point only - EDUF (Enough Design Up Front) done here

Programme Feasibility

Need to have a programme vision that is clear and the strategy is aligned to the business and benefits – being cost effective.

Key point is the programme should be included in the organisations portfolio on initiatives

Objectives:

• 1.       Confirm programme is consistent with business strategy
• 2.       Can be achieved
• 3.       To refine the outline vision of the programme
• 4.       High level outline of benefits
• 5.       Outline cost of the programme
• 6.       Consider the future state of the organisation (possible interim states)
• 7.       Confirm if a programme structure is necessary
• 8.       Develop foundations plan – along with key participants
• 9.       Develop outline governance strategy
• 10.   Assess whether the organisation is ready to use Agile techniques on the programme

Preconditions

1.       Authorisation has been granted to move into feasibility

2.       Business programme owner has been identified and can participate in the feasibility investigations

Keep it short to principally justify the programmes inclusion in the orgs portfolio

Foundations

Aim is to establish firm foundations for the programme – ensure programme meets sufficient benefit è worthwhile investment.

Key areas addressed are:

•         I.            Vision
•       II.            Design
•     III.            Architecture
•     IV.            Governance
•       V.            Culture
•     VI.            Communication

Firm foundations include:

1.       A confirmed vision statement

2.       Business case

3.       Business architectural model (BAM)

4.       Prioritised business benefits

5.       The definition of prioritised, incremental capability enablement

6.       Programme management structure

7.       Programme organisation including roles and responsibilities

8.       Stakeholder engagement strategy

9.       Communication plans

10.   High level plans including road map and benefit realisation plans

The foundations phase does not plan ALL tranches and projects in detail.

It’s complete when there is sufficient information to be able to enter the first tranche and to approve making this step.

Planning the first tranche:

Need to

a.       Identify and plan the projects / initiatives that will deliver the outputs to deliver the capabilities

b.       Identify and plan the activities to enable delivery of the capabilities

Projects CAN be sequential OR overlapping è project planning is limited to:

         I.            High level scope of each project in relation to the programme business case

       II.            Define project interdependencies

     III.            Outline budget for each project

    IV.            Start end dates for each project

Objectives of foundations

         I.            Baseline vision of programme

       II.            Create the BAM

     III.            Define road map for realising vision and developing the BAM

    IV.            Define high level benefits and capabilities

      V.            Confirm the programme business case

    VI.            Establish governance model è must be agile

   VII.            Develop a programme plan è detailed first tranche è others in outline è comms plan

 VIII.            Describes how to assess and manage risks

     IX.            Identify key stake holders – develop stakeholder engagement strategy

       X.            Obtain approval to move into first tranche è gain funding for at least first tranche

 

Preconditions

         I.            Agreement that the programme should be in the business portfolio

       II.            Business Programme Owner (similar to Sponsor in AgilePM) is in place

     III.            Access to innovative thinkers

Foundations is considered a project in its own right

use many / all agile techniques

Follow EDUF

MUST consider the impacts of change 

responsibility remains with Business change owners

appropriate to at least consider specific changes

Capability Evolution

Works iteratively and incrementally

Iteratively è development based on constant review converging on the right solution

Incrementally è each tranche delivers a set of capabilities that move the organisation closer to its new state

Objectives

1.       Plan / initiate / execute projects to deliver capability

2.       Measure benefits along the way

Preconditions

Foundation products have been completed and agreed

Tranche plan has been agreed for this tranche

Overlapping tranches

May need to overlap tranches è when neither necessary nor advisable to sequence

Overlapping tranches need to be self consistent and non reliant on another tranche

Tranches delivering different capabilities often run in parallel

Processes

1.       Capability enablement

2.       Benefit realisation

 

1.       Capability enablement

To drive the creation / development / enablement of capabilities within a tranche

4 components

        I.            Prepare for capability development and enablement

a.       Tranche is considered and checked to:

                                                               i.      All stakeholders understand purpose of tranche

                                                             ii.      All stakeholders understand their roles / responsibilities

                                                           iii.      Communication activities are clear and prepared

                                                           iv.      Project managers + teams are identified and briefed

                                                             v.      ENABLEMENT teams are ready to start

                                                           vi.      Projects and enablement activities are clearly defined

      II.            Execute projects

a.       Detailed project planning happens during PROJECT EXECUTION

b.       Projects executed to deliver outputs è further projects could be identified è this will lead to a review of the Programme and tranche plan

c.       Enablement activities can also commence è so long as not dependent on the project output

    III.            Enablement capabilities

a.       Consolidate project outputs è assemble

b.       Change / develop new processes è drive efficiency

c.       Instigate relevant change initiatives within the organisation

    IV.            Retrospective

a.       Occurs only on enablement of capability è feedback used to update tranche plan è could result in more projects or negating some projects. If sufficient work has been done move into the tranche review

2.       Benefit realisation

Is reliant on capability evolution.

Many enablement activities within capability enablement are driven by the benefits realisation plan è this defines how the benefits in the PRIORITISED BENEFITS DEFINITION will accrue as capabilities are enabled

Benefits realisation process can commence as soon as capability is identified è i.e. measuring the improvements gained so far through delivery of an output.

Main activities in benefits realisation during capability evolution are:

          I.            Baseline measurement prior to capability enablement

        II.            Incremental measurement following capability enablement è show benefit evolution

      III.            Update benefit assessment è show current state of benefit

      IV.            Potential update to benefit realisation plan/ prioritised benefits definition and other programme foundation products as necessary

Points to consider

Always use experts

Use retrospectives even after only partial project deployments

There needs to tranche flexibility in the definition of planning tranches è must never impose rigidity that could stifle the autonomy of Agile

Tranche review

Commences once considered sufficient capability achieved.

Key è confirms the viability of continuation

Confirms any changes needed to plans and other programme foundation documents

Each tranche has its own review

Tranches in parallel or overlapping è remember capabilities being delivered have been identified as neither overlapping nor interdependent è meaning NO dependency between tranches

Best practise suggests è if a tranche review identifies a change to programme foundation products è the overlapping tranche should be reviewed to ensure its validity è may require replanning

Objectives:

         I.            Determine sufficient capability è tranche complete?

       II.            Has sufficient capability been delivered to determine if programme is complete?

     III.            To plan the next tranche

    IV.            Review the programme and update plans and other foundation products as necessary

      V.            Review lessons and manage appropriately

Preconditions

Sufficient capabilities have been enabled to allow the tranche to be deemed complete

Points to consider

Tranche review may deem PROGRAMME complete even with outstanding future tranches

Future plans and foundation documents WILL evolve as more becomes known from tranches

Lessons learned may require governance structures / processes to be amended

Care in planning tranches running in parallel

Benefits Management

Used to ensure optimum benefits are being realised from the enabled capabilities è ASAP

Monitors benefit accruals throughout the programme

Benefit management is iterative and incremental

Where does benefit management typically take place?

                     I.            Programme feasibility è identifies definition / prioritisation of benefits and benefit planning

                   II.            Benefit planning baselined during foundations

                 III.            Benefit realisation mainly occurs in capability evolution

                IV.            Future plans for continued benefits assessment take place during Programme Closure

Objectives

         I.            To gain optimum benefits from capabilities

      II.            Monitor benefit accrual

    III.            Prove benefits through measurement

    IV.            Ensure any future benefit management activities are owned by business change owner

Preconditions

         I.            Capabilities have been enabled

       II.            Business change owners are committed

Points to consider

Use early benefit indicators to help map the future ones

Some benefits will only be realised post programme è process therefore must carry on

Programme Close

Objectives

•         I.            Confirm sufficient capability has been delivered
•       II.            Close the programme
•     III.            Gather any lessons
•     IV.            Review programme against it vision / business case

Preconditions

Sufficient capability has been achieved

Points to consider

BCO’s are committed ongoing for benefit realisation

The business strategy definers within the org need to be informed of closure and may need to approve its closure

Programmes are not formally recognised as closed until the final project or enablement activity is completed è but team involvement may reduce in the later stages