Procuring for agile: thoughts on what good looks like webinar Thursday 23 April 2020 presented by Dr Jon Broome, Olubukola Feyisetan, John Lake, Jason Sprague, Will Webster The link to the write up page and resources of this webinar: https://www.apm.org.uk/news/procuring-for-agile-thoughts-on-what-good-looks-like-webinar/

1. Welcome to a webinar on
Procuring for Agile :
thoughts on what good
looks like
by the

2. Introduction
▪ Order follows that of our
recently published white
paper, which is
downloadable from APM
website.
▪ Key points from the white
paper are in the slide set.
▪ But discussing and
amplifying the text, not
regurgitating it as you can
read the guide.
& Agenda

3. Who are we?
’Bukola Feyistan is a project professional with over 16 years of
experience in UK central government, working with teams that
deliver change to the public.
John Lake is secretary of the SIG and has a career spanning 30+
years in technical, project and general management, predominantly
within the high-technology sector. He is currently an independent
contracting Project Manager.
Dr Jon Broome – chair of the SIG, a trustee director of the APM
and managing consultant of leading edge projects consulting. He
has advised on contracting arrangements and issues for complex
projects and programmes up to £16.5bn for last 20+ years.
Jason Sprague is a managing consultant for ASE Consulting. He
specialises in transformation having worked within some of the
largest change projects in the UK bringing together technology,
commercial and organisational culture.
Will Webster is Head of IT for APM who recently awarded an ‘agile
contract’ to improve our website. He has previous experience of agile.

4. Why this paper and how was it
developed ?
▪ Topic identified by C&P SIG as worthy of a white
paper, but not just for IT projects – the world is
speeding up & wanting benefits delivered earlier
▪ Held a workshop early last year and got lots of info,
examples and insight from 27 odd participants
▪ Seven of us formed a working group and developed
a white paper on it, published in Feb this year.
▪ Three of the working group were from an IT
background and been involved in ‘full-on’ agile
projects.

5. Why the need for a White Paper?
▪ Traditional legal drafting likes certainty and
precision: everything is tied down.
▪ Procurement likes to get to contract with a ‘fixed’
priced.
BUT
▪ The world, not just IT, is moving too fast: we live in a
VUCA (Volatile, Uncertain, Complex, Ambiguous) world
I.e. the world often does not fit the traditional legal
and procurement way of doing things.

6. #projectingthefuture
Trends Traditional Transformational
Setup Detailed design approved before execution
Broad vision of outcomes. Iterative approach:
test and learn
Leadership Defined network, specific outputs Loose network, common aspirations
Stakeholder management Support for a defined plan Jointly developing ‘the what and why’
Budgets and plans Use external comparisons to ensure realistic goals Avoided detailed plans too early. Test and learn
Risk management Detailed risk register and contingency plans
Focus on big issues e.g. customer behaviour,
delivery pace
Commercial/procurement ‘Big bang’ Experimental, incremental
Key skillsets and mindsets
Specific technical skills, esp. programme
management – applied rigorously
Transformational leadership, organisation
design, digital leadership, communications,
tailored governance and review; applied
flexibly, embracing change
How might the profession change?

7. Procuring for Agile:
The traditional approaches
1. Fixed price contracts:
2. Time & Materials.
and nothing in-between !
The Guide is intended to address this big gap
for projects on the agile side of the
waterfall/agile spectrum.

8. What other trends were you aware
of which informed your thinking?
▪ A move towards more benefits / outcome-based
projects (as opposed to delivering to a technical
spec) which is reflected in contracts
▪ A move towards greater collaboration and longer-
term relationships, which needs to be reflected in
win-win commercial and hence contractual
relationships.

9. Some caveats
The White Paper is:
▪ not just for IT projects
▪ not based around using any specific agile methodology
▪ for projects on the agile side of the agile/waterfall
spectrum i.e. they have mostly agile characteristics
▪ not encouraging the abandonment of good project
management practice: Agile actually calls for slicker
programme management
▪ presupposing that a procurement and contracting
approach which is in harmony with agile working has got
to be more helpful than one that doesn’t.

10. Before an organisation procures for
agile, it needs to address …
▪ Provider selection: whether it is willing to select on tech
competence, collaborative ability and input costs ?
▪ Governance & decision-making: fluid selection & instructing
of sprints/projects so Provider can work efficiently.
▪ Legal considerations: lighter, more flexible shorter contracts
with a greater focus on the ‘how’ versus the ‘what’.
▪ Projects controls: a lighter more iterative approach
▪ Skills and culture: see above and a collaborative approach
▪ Wider buy-in: the inputs to the team may need to change.
▪ Leadership buy-in: otherwise the above won’t happen.

11. Is your project suitable for Agile?
X
X
X
X
X
X
X
X
X
3=1x3 36=9x4 Total = 39 / 50
X

12. What does an Agile Contract look like?
Our Top Ten …
1. It is designed collaboratively with the (potential)
Provider(s), so that you utilise their experience and it will
work for them.
2. The focus is on the ‘how’ it will be delivered, not the
‘what’, because the ‘what’ won’t be fully defined and
will evolve over time. The ‘how’ embraces change, rather
than fights it.
3. Each sprint is instructed as a Task, not as a new contract,
so that it can be delivered within a contract.
4. The contract describes the standard technical,
management and administrative requirements with
only the specifics in the Task Order.

13. 5. The conditions of contract are high-level with greater detail
is in the requirement docs which can be changed.
6. Detail of both the ‘how and ‘what’ in the contract is ‘just
sufficient’ to provide a framework, but not over-
prescriptive to stifle innovation and creativity.
7. Payment is primarily based on input costs, but
supplemented by performance measures which are related
to the desired outcomes/benefits within the Provider’s
influence.
8. The emphasis is on ‘carrots’, not ‘sticks’. Contractual ‘sticks’
encourage hiding of problems and blame to avoid liability. “A
lack of sticks enables teams to fail fast and openly and then
move on”.
9.
What does an Agile Contract look like?
Our Top Ten …

14. 9. Liability is for failing to act with ‘reasonable skill and care’,
not ‘fit for purpose’. Points 1 to 8 imply you are buying a
service not a product. If liability is ‘fit for purpose’, the Client
will have to spend too much time defining that purpose and
the Provider being clear about what it is taking on and not
finishing each sprint until absolutely sure it’s met that
standard.
10. The ‘how’ is based on collaboration with a presumption of
trust in competence, integrity and empathy to each others
needs. A lack of trust means more administration and
defensive behaviours.
What does an Agile Contract look like?
Our Top Ten …

15. Preparing the Contract
1. Get your decision making in order so that you can instruct
the right Task fast enough for the Provider to not have
resource doing nothing. It needs to align with the project
controls and feedback process.
2. Put stakeholder engagement at the heart of the decision-
making cycle whoever those stakeholder are.
3. Establish how success criteria and any incentives will be
set: research clearly indicates joint setting works best, but
their needs to be a framework to do this. Decision making,
stakeholder and risk assessment feed into this.
4. Contractual-ise the critical agile methods be it systems, the
organisational structure &/or people of the Provider – so
need to design the contract to incorporate the provider’s
‘how’ (its agile method) into it. Precedence?

16. Preparing the Contract
5. Project Owners must own the agile process … so must be
heavily involved in writing the ‘how’ documents and project
managed in order not to revert to type.
6. Bring subject-matter experts with you so need to be briefed
and project managed in order not to revert to type e.g.
overly prescriptive technically or excessive remedies
7. Allow for change over the duration of the relationship so
much of the ‘how’ will not be in the conditions of contract
but can be changed. It may that different types of contract
are need over the duration of the relationship & are
connected by an over-arching framework type contract.
8. Pay for insight, information and decisions once the Provider
is selected for two reasons: you pay for it anyway and it will
be given willingly by the delivery team. State this upfront.

17. Selecting the Provider
▪ MEAT is a challenge, but mainly in the mind!
▪ Need to sell that the right people, organisation and
processes/systems will give best value, not the illusion of
lowest tender Price for undefined & changing deliverables.
▪ For example:
– how will their organisational structure combine with yours;
– what systems, process and procedures will they will use; will they
replace, work alongside or integrate with yours; and
– who will they provide with evidence both of technical capability and
collaborative/ agile ability.
▪ Ideally, these can be expressed as contractual commitments
and incorporated into the contract.

18. Managing the Contract &
Delivering the Work
1. Do your thinking early … see previous slides!
2. Collaboration & agile are a means to an end, not the
end. I.e. together you make better & faster decisions
due to strong project controls, more rapid and honest
feedback, and greater realism about risk. This does not
mean you sweep hard issues under the carpet.
3. Agile needs to be nurtured, not just in the delivery
team but across the organisation that feeds into the
delivery team. Leadership needs to step up.

19. 4. Collaboration is not just about ‘behaviours’, but also
infrastructure. E.g.
– booked-in regular meetings and ‘time-out’ workshops for
continuous improvement of effectiveness & efficiency.
– shared & common databases, planning tools and reporting
standards
– video-conferencing if located remotely etc.
5. ‘Just sufficient’ governance so that Tasks can be instructed
in a timely manner & performance evaluated without undue
bureaucracy.
6. Governance of the ‘how’ (not just the ‘what’), so that the
‘how’ evolves in a controlled way as the relationship evolves
= more management time, less admin, improved benefits!
Managing the Contract &
Delivering the Work