Mapping the future: the art and science of programme planning in a waterfall or agile world Thursday 16 July 2020 Presented by Adam Skinner and Andy Willis The link to the write up page and resources of this webinar: https://www.apm.org.uk/news/mapping-the-future-the-art-and-science-of-programme-planning-in-a-waterfall-or-agile-world-webinar/

1. Thursday 2 April 12.00-12.30pm BST
Welcome to P2 Webinars
Mapping the future: programme planning in a
Waterfall or Agile world
Thursday 16 July

2. p2consulting.com
We formed P2 to offer businesses embarking on major
transformations a real alternative to the false ‘comfort’
of the big 4
Our vision
We value our people
We understand the importance of workplace
engagement and value all our people – that’s
why we continue to invest in their development.
We’re global We speak your language
Our delivery experts talk the same language and
use the same tools. They make decisions with
you and take all the responsibility to achieve.
“P2 Consulting have put in place a
highly effective programme
management environment which
means that the senior team always
have full visibility and control”
We deliver
We quickly land and fit into your surroundings
and methodologies to provide immediate
impact
We’re qualified We’re growing
In 2017 we were the
fastest growing
privately owned
consultancy in the
UK.
We’re here for our partners when...
They need a
world-class PMO
or Portfolio Office
They need a tried
and tested
Programme
Delivery team that
can operate as
Agile, Waterfall or
bi-modal
They need cutting-
edge analytics and
insights
They need a testing
and
quality assurance
capability
They need a
transformation partner
We put your success first, and look to quickly
enhance your position
We manage your delivery on time, and to
budget
We coach, mentor and improve so that
change can be successfully delivered and
embraced
Head of Merchandising Strategy
John Lewis
Who we are

3. 3
Automation Analytics
P2 Scaled Agile Change
Management
IMPROVE
EFFICIENCY
• Reduce cost
• Faster time to market
• Continuous Improvement
• Future-proofed
Portfolio
Design
P2 PMO+®
Test
Management
Programme
Planning
CONTROL
EFFECTIVENESS
• Ensured ROI
• Reduced Delivery Risk
• Improved Collaboration
• Enhanced Transparency
Programme
Recovery
Design&
Mobilisation
Programme
Delivery
Go-Live
Management
DELIVER
EXCELLENCE
• Increased Confidence
• Set-up for Success
• Regained Control
• Burst Capacity
Our Promise
Our Services
Your Benefits
P2 Consulting IMPROVES, CONTROLS AND
DELIVERS your transformationambition

4. 4
Adam Skinner
▪ Co-chair of the APM’s Portfolio Management SIG committee
▪ Co-author of the APM’s Guide to Portfolio Management
▪ P2 Consulting’s Director of Consulting
Who are we?
Andy Willis
▪ P2 Consulting’s Academy Director
▪ 37 years of experience
▪ Led planning in various large programmes including LBG
Simplification, ONS Census, HMRC Brexit

5. 5
▪ In Prince2* a plan is defined as: A detailed proposal for doing or achieving something which specifies THE WHAT,
WHEN, HOW and by WHOM it will be achieved
▪ In DSDM** Agile values “responding to change over following a plan” – it still however places strong emphasis on
high level planning at the project and timebox level
▪ Even when scaling Agile (SAFe® for example) we still need to plan our activity, deliverables and dependencies –
even if it is only for the next program increment period.
*Prince2: Managing Successful Projects
** DSDM AgilePM Handbook
“If you fail to plan, you are planning to fail!” – Benjamin Franklin
Why plan at all?

6. 6
Define Scope,
Outcomes,
Objectives &
Deliverables
Define Products
Develop the Work
Breakdown
Structure
Establish
Milestones
Dependencies
& Critical Path
Develop
a Schedule
Estimate Effort and
identify Capability
Optimize
Plan
Ownership
Baseline
Maintain schedule, quality and baseline
Planprogress&reporting
Governance&oversight
Manage Risk & Dependencies
Planning in a Waterfall environment generally involves some significant planning up front, defining a series of outcomes, activities and
a long-term schedule which is then baselined…..with a broad reluctance to change anything after that!
Any Waterfall project or programme should start with broadly the same set of specific activities – set up the plan, schedule the
deliveries, monitoring/oversight & align to capacity and capability.
Where do we start? Let’s go old school!

7. 7
Pre-project:
ToR Only
Feasibility
Shape the
Project &
tentative
schedule only
Foundations:
Strategy for
development,
deployment and
commitment
around schedule
Modelling
Prototyping
Supporting
Materials
Testing &
Assurance
Deliver
High Level Project Plan:
High level schedule of Project Increments
and some shape to initial timeboxes for initial
PI
Timebox Planning & Reviews
Modelling
Prototyping
Supporting
Materials
Testing &
Assurance
Deliver
Timebox Planning & Reviews
Planning
Iterations
Planning
Iterations
Evolutionary Development & Delivery
Embrace change, Re-evaluate & Re-plan as required
(Set-up the plan) (Schedule the deliveries)
(Monitor & Oversight) (Monitor & Oversight)
Planning in an Agile world takes a more “pragmatic” approach – shorter term planning, evolving the detail as we
progress through delivery, regular learning cycles and embracing change…
There is an alternative

8. 8
Scope
Objectives
Deliverables
Outcomes
Understanding the scope in detail provides accuracy in articulation of the different components of a
plan early in the delivery cycle.
Defining scope also requires defining in and what's out of scope
Start right… The basics of Waterfall planning

9. 9
When mobilising the project, one of the first activities that
must be done is to identify and define the products that
will be delivered.
Prince2 defines this approach as Product Based
Planning.
Using and defining the Product Breakdown Structure we
progressively break down products into smaller products
and sub-products until the entirety of the scope is
covered.
A product description will be written for each product. This is not a planner responsibility however
they should be part of the team creating these as it helps with sequencing and scheduling to
understand detail about each and its inter-relationships with other Products.
So what are you going to deliver? What's a product?

10. 10
Once we have our agreed products, we then need to
decompose these into more manageable chunks of work-
based activity…behold the mighty…
…Work Breakdown Structure (WBS)!
▪ The WBS breaks up deliverables and work into
smaller, more manageable chunks of activity
▪ Ideally with an aligned estimate of required capacity
and capability.
The planner must be involved in WBS creation as the interconnection of these activities
create the plan and drive the sequencing and scheduling, alongside required
dependencies
How are we going to deliver these products?

11. 11
Once the WBS has been created, a work package
estimate of the required effort can be developed.
Estimating the work effort for each component in the WBS
requires the planner to identify the basic elements that
drive the work to complete the deliverable.
Once we understand the sequencing and effort required to
deliver a work package, we can then start to develop the
schedule.
The Planner consolidates their understanding of the whole Project including deliverables and
activities and sequences these against an associated timeline. Start with critical path items first and
build a schedule with progressively lower level milestones
Sequence & schedule with
dependencies, constraints
and capacity
L0, 1,2,3 milestones
Tasks
Activities
Track progress through milestone delivery
Maintain baseline through change control
How long is it going to take and how do I measure progress?

12. 12
Once you have your initial schedule you will want to review
and challenge the activities, sequencing, delivery timeline,
financial considerations and capacity requirements.
It is therefore important to factor in the constraints of
scope (have we kept to our boundaries), time (have we
drifted beyond delivery timeline appetite), and cost (is this
within the agreed business case).
An experienced Planner understands the levers that can be taken to optimize a schedule
whilst preserving plan integrity, quality and minimising risk.
Working smarter… Not longer or harder

13. 13
The planner must define plan ownership, so they and the team understand the
responsibilities for deliverables and how threats impact the bigger picture – getting this
agreed up front is essential to delivery success
If you don’t have agreed plan ownership, then the plan is
broadly worthless. It would only be a collection of related
tasks that the team aspire to deliver but have not committed
to.
The plan and schedule must have at least one accountable
owner for delivery – ideally this would be the Project Manager,
or in the case of a Programme this would be a Programme
Manager.
▪ Schedules can/will have multiple resources responsible for
individual activities
▪ Ultimately it should be the Project Manager who has
accountability.
Who’s going to deliver the plan?

14. 14
The developed schedule will generally be baselined within the tool that’s being used. Its likely that a
record of milestones will be maintained by a PMO or Portfolio office to ensure that dates are not
changed without consideration to impact on other projects/programmes
Once a schedule has been reviewed and finalised, it will
need to be baselined. Applying a baseline to a plan is
essential as it provides a clear reference point against
which the progress can be measured.
This becomes a KPI of the project in relation to time.
The baseline should be clearly documented and should
be controlled by the Project Manager and through formal
change control approval.
So that’s it then… We have a plan and a schedule

15. 15
Having the correct control structure around the plan is essential to keeping it in good order, ensuring
all team members understand the commitments that they have made, and early warning of threats
that may de-stabilise or prevent agreed delivery commitments
Once the plan and schedule have been agreed, that’s
only the beginning from a planning perspective.
A plan is a living set of documents, any schedule will
undoubtedly need to evolve over time – especially as
threats are identified and progress becomes challenged.
Equally important to setting up a plan / schedule is
maintaining its integrity through a series of controls and
appropriate governance.
We’re done then? Not quite…

16. 16
All to often plans and schedules have failed due to poor setup, maintenance and the failure to
recognise and react to “approaching storm clouds”…….an experienced planner will equally use fact
point reporting as well as “gut instinct and insight”.
An experienced planner is essential where you have large
or multiple projects, significant complexity and or a
programme where projects need to be aligned to
timebound delivery of strategic outcomes.
The perfect planner!
Prog.
Director
PMO
Lead
Delivery
Lead
Delivery
Lead
Delivery
Lead
Delivery
Lead
Fact Based Insight & Observations
Planner
Controls & Data Updates
Assurance
Fact based Insight
Data Triangulation
The planner: part wizard, part politician!

17. Agile Planning
17

18. 18
Not true… Planning still plays a big part in Agile delivery –
it is however different in several ways to the more
traditional approach to planning in Waterfall…..
▪ High-level planning up front – shape an outline of the
delivery plan, start and end points and early timebox
deliveries
▪ Shape the initial timeboxes – scope from the backlog,
timing, length, resources, velocity estimation etc
▪ Conduct a planning iteration (PI) session – what does
the next 10-12-week period look like, alignment across
Agile teams, identify x-dependencies etc.
I thought we didn’t need to plan in Agile?

19. 19
Well in reality – they don’t! As we are all aware within an
Agile environment the team is responsible for delivery and
in true team style the team is also responsible for
planning….
• Initially it won't be much – desired end date, planning
increments and some shape to the initial timeboxes
required.
As we mobilise the Solution Delivery Team they then
assume the responsibility for planning – fleshing out the
next few timeboxes (Scrums/Sprints) – and a detailed
timebox plan is created with a view of the predicted scope
for each.
Business
Analyst
Solution
Developers
Business
Ambassador
Solution
Tester
Team Leader
/ Scrum
Master
Technical
Advisor
Business
Advisor
Collective Team Planning Responsibility – NO Planner!
Solution Development Team
Where does the planner start in an Agile world?

20. 20
1. High Level Plan (start / end, Program Increments, Initial timebox planning)
2. Planning for the next Program Increment (every 10-12 weeks) (requires Business Context, Roadmap & Vision, Features + prep)
3. Timebox Planning (individual sprints within an increment)
4. Deployment Planning (could be technical and or business implementation).
As we scale Agile, we then get into Agile Release Train Planning through “Program PIs”
High Level
Plan
• Start / End of Project
• Planning Increments (phases of
activity over roughly 8-12
weeks)
• Initial 1 or 2 timeboxes in first
Program Increment based on
agreed prioritised requirements
list
1
Program / Planning Increment 1
2 3 4
Innovation
& Planning
1
Program / Planning Increment n
2 3 4
Innovation
& PlanningPIPI
• Time-Box planning
• Team backlog planning
• Plan for execution ~ 60-70% of
capacity
• Detailed analysis
• Test prep planning
• End to end test planning
• Deployment planning (if relevant)
• Fixed duration sprints
• Variable scope based on PRL
• Project Backlog planning
• Story analysis / estimation
• Risk / constraint planning
• Capacity planning
• Dependency planning
• Revised iteration goals
• Revised iteration backlog
• Definition of done
• Reconfirm roadmap and vision
• Commitment by teams
Fixed duration Sprints, Fixed duration Increment Fixed duration Sprints, Fixed duration Increment
Continual Delivery & Release On Demand (DevOps) – where appropriate
What does our Agile planning approach look like?

21. 21
High Level Plan:
Started at the very earliest stages of the project lifecycle – focus on
▪ Identify your development and testing strategy
▪ Identifying your risks
▪ Generating a high-level schedule
▪ Identify and mobilise the Agile team and establish your first 1-2
timeboxes through a simple timebox plan
Planning/Program Increment:
Mandatory event when scaling Agile although a simpler version can / could
be used in small scale Agile Projects
▪ Inputs include Business Context, Product Roadmap / vision and key
Features of the backlog
▪ Outputs should be committed PI objectives agreed within the teams with
corresponding business value
▪ Revised Program Board including Feature delivery dates, dependency
delivery dates and relevant milestones Confirm capacity, velocity and
capability requirements
Timebox (Iteration) Plan:
Initially established before development, but more detailed planning is
undertaken once development activity is underway
▪ Iterations are typically 2-4 weeks (2 weeks generally)
▪ Can take either a structured or free format approach
▪ Always start and end the same way – Kick-off (understand the
objectives) & close-out (including show & tells and retro’s)
▪ Team progress measured through daily stand-ups – SDT, BA’s and TA’s –
ideally facilitated by the Scrum Master
▪ General rule is five iterations per PI
Deployment / Release Planning:
If we consider a simple release of value per Program Increment (approx.
every 8-12 weeks) the release will represent all of the value (Features) that
the Agile teams were able to deliver in that period (it may not of course be
everything that we set out to achieve at the start of the PI!)
▪ Estimate roughly the Features to be delivered by the deadline
▪ Needs to be a technical release plan that supports the changes to
production systems – what, how, when, communication, “warranty”
▪ Needs to be a business release plan – process changes, procedures,
system training, business check out, super user support etc.
A quick summary of the key planning areas

22. 22
In many cases a combination of both of these types of tracking can be used at events such
as the Daily Stand-up, “Show & tells” or even as reference sources when planning the next
PI
Not quite…! Inevitably any project / ART will have some key
milestones, and these are more likely to be things such as key
deliverables.
If we have agreed a strategy for our program increments and
timeboxes, then in reality there’s little value to be gained from tracking
the milestone dates.
What we will want to focus on however is the delivery of the agreed
scope.
This could be done in one of two ways:
▪ Tracking of completed story points vs estimate and projected
velocity – overlaying with key milestones if required
▪ Tracking of completed user stories and how that supports the
delivery of our features or EPICs.
SIT Integration
UAT Testing
Dependency 1 Delivered
Do we still track our milestones?

23. 23
The SAFe definition of a roadmap is “a schedule of events and milestones that communicate planned solution
deliverables over a planning horizon”
The roadmap is the “glue” that links strategy to delivery and tells a story that creates alignment and momentum:
The process of creating the roadmap is often the point!
Building the roadmap narrative:
1. Understand the plot, not the story of your programme
2. Start with the ending
3. Identify the main characters and the transformation they will go through
4. Make it relatable to your stakeholders
5. Avoid excessive exposition – simple, clear and flowing
6. Get stakeholders to proof-read it!
Roadmap planning

24. 24
1. Not trying to “force” Waterfall planning approaches into an Agile team environment – adapt your
approach, play to the strengths of both methods and build something that bridges the differences
between both
2. Using the strengths of the team to identify and build your plan – this leads to commitment to delivery,
however, embrace the fact that change is inevitable – use it as a strength – not a weakness
3. Embracing the best of both Waterfall and Agile – regular retro’s on Waterfall plans, and combining
points tracking with milestones, blend some of the best aspects of both methods.
What have we learned?

25. p2consulting.com25
+44 (0) 20 7099 0803
info@p2consulting.com
p2consulting.com/webinars
Adam Skinner:
adam@p2consulting.com
linkedin.com/in/adam-skinner
+44 (0) 7803 260 508
Andy Willis:
Andy.willis@p2consulting.com
linkedin.com/in/andywillis/
+44 (0) 7966 974 457
Forthcoming FREE webinars:
The journey to Continuous Testing & Release on Demand
12.00-12.30pm | Thursday 23 July
The future of Project Management
12.00-12.30 | Thursday 6 August
Save your spot at p2consulting.com/webinars.
Stay updated:
Search ‘P2 Consulting’ on YouTube to visit our channel or
visit p2consulting.com/insights for our latest thinking.
Get in touch