The document discusses contracting for agile software development projects, describing how agile approaches require collaboration and involvement across project teams, and research shows that using a time and materials contract under a framework agreement with a statement of work covering agile terms is the consensus for contracting agile projects effectively.

1. An Agile Approach to
Contracts and Procurement
in the “Contracting Jungle”
Presenters:
Dr Jon Broome, Chairman of the
APM’s Contracts & Procurement SIG,
John Lake, Secretary of the
APM’s Contracts & Procurement SIG
About the Presenters:
Dr Jon Broome, Chairman of the APM’s Contracts & Procurement SIG, has been
involved with the development of the New Engineering Contract (NEC) since 1993 and is
an acknowledged expert and accomplished presenter on it.
Jon will present an overview of the C&P SIG and its ongoing aims.
John Lake, BSc CEng RPP MAPM MIET, Project Manager, IEC Networking Limited
Since graduating with an electronics degree, John’s career has spanned 30+ years. He
has held positions in technical, project and general management within companies
ranging from SME’s to large corporations.
He has experience of both sides of the subcontracting equation and is keen to share this
knowledge base with others and wishes to promote best practice within the professional
project management community.
For John Lake Tel: +44 (0) 1794 324 715 Mob: +44 (0) 7798 583 576
Email: john.lake@iecnetworking.com
For Jon Broome Tel: +44 (0) 1179 09 3297 Mob: +44 (0) 7970 428 929
Email: jon@leadingedgeprojects.co.uk
1

2. Aim of the C&P SIG :
The Contracts & Procurement Specific Interest Group :
 Exists to promote and disseminate knowledge,
understanding and good practice of contracts and
procurement in a project & programme environment.
 Aims is to become a lively and constructive debating forum
which takes existing best practice and helps make it
better.
 Wants to be disseminating this knowledge, understanding
and better than best practice through a variety of
accessible means.
 Has a long term aspiration to become recognised as an
international forum at the leading edge of excellence in
contracts & procurement for projects.
The Contracts & Procurement Specific Interest Group :
Exists to promote and disseminate knowledge, understanding and good practice
of contracts and procurement in a project & programme environment.
Aims is to become a lively and constructive debating forum which takes existing
best practice and helps make it better.
Wants to be disseminating this knowledge, understanding and better than best
practice through a variety of accessible means.
Has a long term aspiration to become recognised as an international forum at the
leading edge of excellence in contracts & procurement for projects.
Notes:
2

3. Contracts & Procurement SIG Structure
The Outer Circle (& beyond) : Receive
Information via general APM publicity.
The Middle Circle : Those on the C&P
web mailing list.
The Inner Circle Circle : Those who are
willing to contribute when asked e.g.
Talks, contributing & reviewing
documents. Limited direct emails.
The Bulls Eye : Committee members &
those who want to initiate ‘projects’ &
pro-actively contribute. Copied in on
most emails wrt SIG initiatives.
Bi-monthly web / tele-conference
meetings.
Notes:
3

4. Presentation Background
The “Jungle”
In lean and uncertain times the challenges can be:
 Shrinking Territories (markets)
 Less prey (tighter budgets/margins)
 Only the fittest may survive
 Untenable to carry on as we’ve always done?
 The Agile option may help
In this presentation we look at the Agile option as a usable tool that can be used
when circumstances allow.
The Agile method has been in use for more than 20 years (predominantly for the
development of software). It has been found to delver significant benefits by
optimising the Time, Cost and Quality (Scope) constraints in the right
circumstances.
This presentation is not intended to “promote “ Agile but to give background on its
merits and how to place contracts for Agile developments.
Notes:
4

5. Presentation Topics
 When to decide your contracting strategy
 How did Agile come about (against earlier contracting
practice)?
 The Agile approach (Agile drives the contracting practice)
 How to contract Agile (current consensus)
 Agile in practice plus pros and cons
 Q&A
Presentation aims:
Looking at Agile from a procurement perspective
Not focussing on describing Agile methodologies (see “Agile is Coming” by Steve
Jones, Sellafield and APM PMC SIG and http://www.slideshare.net/fullscreen/merv/robin-yeman/1
)
Notes:
5

6. When to decide your contracting
strategy
The Procurement GuideThe Procurement Guide
1 Introduction and
Overview
2 Concept and Feasibility
3 Project Procurement
Strategy
4 Package Contracting
Strategy
5 Prepare Contract Terms
and Requirement
6 Select Provider and
Award the Contract
7 Manage and Deliver the
Contract
8 Contract Closure, Cut-
over Operation and Support
The Procurement Guide
Compiled by the Association of Project Management Contracts and Procurement
Specific Interest Group
Procurement and contracts management is becoming more prevalent in projects
and programmes PMs need to have a basic understanding of procurement and
contracting in order to effectively manage those aspects. The APM’s Contract &
Procurement SIG therefore offers this Guide as a ‘place to go’ that will supply a
basic understanding of ‘how to’ procure sub-project Works and to manage
delivery through the phases of the procurement life-cycle.
Notes:
6

7. Project Procurement Strategy
Project Procurement Strategy (Guide Chapter 3)
This chapter describes how to decide the Project Procurement Strategy, which divides
the proposed work into deliverable packages. It determines which packages of the
project are to be produced internally (either newly developed or manufactured) and
which to source externally (commonly referred to as the ‘Make versus Buy’ decision). For
the packages that that will be sourced externally the stage determines:
• The nature of the relationship to be sought with the Provider e.g. .
• The most appropriate high-level contracting strategy e.g. cost plus or fixed price.
• The Provider selection strategy to be employed.
Once these determinations have been made a procurement schedule, which informs and
is informed by the overall project schedule, is developed. The output of the stage is a
Project (or Programme) Procurement Strategy document forming a summary of the
decisions made and the underlying reasoning. The chapter covers:
• What you need to decide on the project procurement strategy – the inputs.
• The stage process.
• Descriptions of the activities involved in deciding the project procurement strategy.
• The outputs that should result from the stage.
7

8. Package Contracting Strategy
Package Contracting Strategy (Guide Chapter 4)
This chapter concerns the development of the contracting strategy for each
individual Project Package and its specific content. This includes:
The payment schedule (with regard to cash flow)
• How risk is to be managed (allocated, contained and mitigated).
• Choice of the Conditions of Contract, which may be based on a ‘best fit’
standard form of Contract, or whether an in-house or custom form should be
used.
The chapter covers:
• What you need to decide the Package Contract Strategy – the inputs.
• The stage process.
• The Risk Management aspects.
• Descriptions of the activities involved in deciding the Project Packaging
strategy.
• The outputs that should result from the stage
8

9. How do we Contract Agile?
Some Backgound Research
 Norwegian (NTNU) thesis (2008)
https://www.researchgate.net/publication/267247519_Software_Contracting_and_Agil
e_Development_in_the_Norwegian_ICT_Industry_A_Qualitative_Survey
 Computer weekly Article http://www.computerweekly.com/feature/How-
to-write-supplier-contracts-for-agile-software-development
 Bird & Bird: Contracting for agile software development projects
http://www.twobirds.com/~/media/PDFs/Brochures/Contracting%20for%20Agile%20s
oftware%20development%20projects.pdf
 InfoQ: Agile Contracts
https://www.infoq.com/articles/agile-contracts
 Agile Contracts Primer
http://agilecontracts.org/agile_contracts_primer.pdf
Norwegian (NTNU) thesis (2008)
https://www.researchgate.net/publication/267247519_Software_Contracting_and_Agile_
Development_in_the_Norwegian_ICT_Industry_A_Qualitative_Survey
• Looks into what work is done in adapting contract standards to better comply with
agile principles.
• Researches the experiences with using agile methods in practice and how the
contractual model used in a project affect its ability to use such methods - interviews
with seven of experienced practitioners.
Computer weekly Article http://www.computerweekly.com/feature/How-to-write-supplier-
contracts-for-agile-software-development
• Best mechanism is T&M.
• “Product owners must be continuously and intimately involved with everything the
development team should be delivering, as well as communicating with stakeholders
on the customer side.”
Bird & Bird: Contracting for agile software development projects
http://www.twobirds.com/~/media/PDFs/Brochures/Contracting%20for%20Agile%20soft
ware%20development%20projects.pdf
• Provides detailed description of what to be defined in a contract for Agile
development.
9

10. InfoQ: Agile Contracts
https://www.infoq.com/articles/agile-contracts
• T&M Rolling Contract: Supplier incentive to perform, Reduced Client risk, less up-front
planning
• Large projects – need to look at de-mobilisation cost compensation for Providers in the
event of termination
Agile Contracts Primer
http://agilecontracts.org/agile_contracts_primer.pdf
• Examines in depth potential contracting mechanisms (some complex)
• Capped T&M can be simple and effective
• Avoid bonuses and penalties: Behaviour driver: Affects transparency and can promote
“gaming” between Provider and Client
Notes:
9

11. How do we contract Agile:
What does an “Agile Contract” look like?
 Research into the performance and success of Agile processes under
conventional contracting practices shows that the Agile process needs
to drive the contracting practice.
 An “Agile Contract” needs to take into account the benefits of the
process.
ContractAgile
The Agile process reflects back into the way work is contracted. The “Agile
Contract”.
Notes:
10

12. How did Agile come about?
- Look at a Typical Fixed Price Contract:
 Contracting organisation (Client) can clearly describe up
front what it is they want (the Requirement) and the
constraints under which it is to be delivered
 Competed based on price and compliance (points system)
 The Provider quantifies its risk level
 The Client quantifies its risk level
 Changes to the Requirement once under contract require
negotiation to agree any price changes
Client
Provider
FP
Contract
A “standard” FPFS (Fixed Price Fixed Scope) contract assumes that the scope is
understood up-front:
• In practise the cost of determining a fixed scope up-front can be significant
• Nominally all changes to Requirement are subject to contract change, which
can be a costly process
• Notes:
11

13. Fixed Price – Bid stage
 User input to the Requirement is time-bound (limited)
 Non-recoverable risk budget is included
 It is often not possible to define the Requirement to achieve
comparable quotations (Providers quote varying solutions)
 Bidders may over-specify and may add “bells and whistles” to
impress
 Price vs. Scope may be a key scoring principle – so Providers
may rely on short-cuts or adding contract changes later
Client
Provider
FP
Contract
The bid stage is often quite restricted in terms of time. Often the tender may only
be received by the Provider with perhaps a week or two to provide a response.
This puts considerable strain on the bid team and cause erroneous assumptions
to be made. Bids may also be couched in a myriad of assumptions and
dependencies due to lack of dialogue at the bid stage.
Notes:
12

14. Fixed Price Risks
Potentially Leading to:
 Features being specified that are never used and wasteful
 The Baseline Requirement may be interpreted/examined
by Provider/Client in the event of (or causing) dispute
 Concentration on progress against a Baseline Schedule
rather than what is being provided
 Potentially adversarial behaviour (Client/Provider
protecting profits)
 Ultimately users may reject the solution (“We’ve never
been asked…”)
Client
Provider
FP
Contract
Notes:
13

15. Hedges on FP arrangements
Client
Provider
FP
Contract
Client
Planning
Phase
Provider
FP
Contract
Client
Stage 1
Stage 2
Stage 3
Client
Framework
Agreement
Task 1
Task 2
Task 4
Task 3
1 2 3
Hedges on FP arrangements:
1. Early T&M/FP stage to establish the detailed/realisable Requirement: Need
to select a Provider to do this, costly, may required significant “de-risking”
work, conclusions may be wrong
2. Payment Milestones against stage deliverables: May be front loaded, limited
cost/attainment visibility or Review Points: More risky as provider’s solution
progresses.
3. Framework with individual tasks: Allows for flexibility in awarding contracts,
however the risks of requirement interpretation are still present. Tasks can
also be T&M basis but risk is then all the Client’s.
Notes:
14

16. What can go wrong (Gotchas!)
Gotchas league table (50 respondents):
 Unspecified dependencies (14)
 Resources issues (10)
 Requirements/Change Management (5)
 Poor procurement processes (5)
 Client factors (5)
 Policy/legislation/standards (4)
 Undefined acceptance criteria (3)
 Other (4)
Previous attendees views; as captured and categorised (numbers of instances):
Dependencies (14)
Resources Issues (10)
Requirements/Change Management (5)
Poor procurement process (5)
Client Factors (5)
Policy/legislation/standards (4)
Undefined Acceptance Criteria (3)
Other (4)
Notes:
15

17. Agile Approach – The Agile Manifesto
 Written in February of 2001 in Utah at a summit of practitioners of
software methodologies (e.g. Extreme Programming, SCRUM,
DSDM). They found consensus around four main values:
Individuals and
Interactions
Processes and
Tools
Working
Software
Comprehensive
Documentation
Customer
Collaboration
Contract
Negotiation
Responding to
Change
Following a
Plan
Over
Over
Over
Over
On the face of it; not compatible with conventional contracting practices!
What is a Contract?
Contract: A legally enforceable agreement between two or more parties defining the
obligations of each party. It specifies:
• The Required deliverables (which may be in the form of levels of performance)
• The corresponding consideration, normally monetary,
• In a project environment, in which there is a defined life-cycle, as opposed to a simple
transactional contract for pre-manufactured goods, the procurement process should
yield, as a minimum:
• The constraints under which the Requirement is to be delivered.
• How the Contract is to be administered (e.g. project management requirements,
points of contact, change control, etc.).
• The Consideration to be paid to the Provider against the deliverables.
• The Acceptance Criteria for the deliverables.
• Remedies for non-performance.
16

18. Agile – Can reduce risk
A deliverable at every iteration
The Agile process breaks the work down to the lowest common denominator
process – the “iteration”.
This has the effect of reducing risk - Is the project less risky half way through (the
red line) when using agile?
Notes:
17

19. Agile – The Collaboration Approach
Agile factors driving the contracting practice:
Client
Provider
PM
Senior
User
Users
PM
Product
Owner
Team
Backlog
Controller or
Scrum Master
Release
The Agile approach REQUIRES commitment to COLLABORATION and
INVOLVEMENT across the whole team, particularly the Client’s team.
If this cannot happen (e.g. users are not available) then the Agile method will not
deliver its benefits.
The key resources are the Product Manager and the Senior User.
Senior User: An end user of the capability to be delivered (usually familiar with
the system being superseded): The Senior User needs to be able to manage the
expectations of the user team and ensure that disagreements are overcome to
provide a basically stable Requirement.
Product Owner: Represents the interests of the Client to the Provider Team and
makes decisions on the backlog for on-going iterations.
18

20. How do we Contract Agile? - Consensus
Client Standard
Contract Terms or
Framework
Agreement
Annex
Statement of Work
(SoW) covering Agile
Terms
Capped
T&M
Rolling
T&M
A free example SoW can be found at: http://www.coactivate.org/projects/agile-
contracts/sample-fixed-price-agile-contract
Research favours a capped or rolling T&M basis under a framework or main
body Contract (T&M provides cost burn visibility).
Main body should define Contract background terms such as; parties to the
contract, IP ownership, security, jurisdiction and T&M rates.
An Annexe SoW should detail thoroughly the ways of working for the Agile
method selected.
Notes:
19

21. Agile SoW – Planning and Baseline
The Baseline:
• Description of the Client/Provider relationship and the background to the project – why
needed.
• High level description of the required capabilities: e.g. expected user experience,
performance parameters, interfaces.
• Requirement – The baseline upon which the price (price cap) was quoted (broken
down into N1 sprints of N2 duration and N3 average resource level, the
Requirements, Stories and Story Tests Baseline).
• Note that it is prudent to include some additional sprints to cover the likely changes
during the delivery lifecycle and “hardening” the capability for final
release/deployment. Things to define:
• Internal (Provider) iteration duration
• External (Client review) iteration duration
• Release Roadmap (releases to the Client)
• The Requirements, Stories and Story Tests (Baseline)
• Optional: Agile methodology description (for the uninitiated)
20

22. Iteration, Functionality and Release
Plan
Release
v1.2
UK, EU.
Release
v1.1
UK, EU.
Sprint Completion Dates
Sprint 27 2nd Dec 2014
Sprint 28 23rd Dec 2014
Sprint 29 27th Jan 2015
Sprint 30 17th Feb 2015
Sprint 31 10th Mar 2015
Sprint 32 31st Mar 2015
Sprint 33 21st April 2015
Release
Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
PV
Release Release Release
The Iteration, functionality and release plan needs to be defined for however far
in time the contract covers. This is subject to update during the process.
The plan shown has:
• Iteration (Sprint) duration of 3 weeks.
• A baseline functionality versus iteration schedule.
• A Major release plan.
Notes:
21

23. Agile SoW – Key personnel roles and
responsibilities
 Client and Provider Project Managers
 Product Owner (Client or Provider)
 Senior User (Client) … Note availability!
Agile SoW – Change Management
 Standard Change Process – Backlog update - no
change to overall budget
 Extraordinary Change Request – Budget expected to
be exceeded
The Product Owner represents the interests of the Client and approves changes
to the backlog. The Client must provide a Senior User that will represent the
interests of the User group (and resolve differences of opinion).
Significant change is able to be handled via the Agile process, particularly if a
rolling T&M arrangement is put in-place. If a fixed number of iterations is
contracted then a contract change only necessary when it is concluded that
additional iterations will be needed. In a fixed-iteration contract it is wise to allow
for a few iterations beyond the identified scope for “hardening” and unforeseen
requirements.
Notes:
22

24. Agile SoW – Communications and Tools
 Channels – “SharePoint” is better than email
Full visibility of progress/ key collateral.
 Close engagement - Co-location
Video-conferencing
 Backlog visibility across the project
Agile management tool (e.g. “VersionOne”)
 Aligned tools - Repository,
software languages, databases, issue tracking
 Aligned V&V environment – Build automation
Communications facilities and tools are very important in the Agile process. It is
best to rationalise communications channels and tools between the Client and
Provider. If there is poor communications this will potentially set up “barriers”
between the teams and the Agile process my not work as well.
Notes:
23

25. Agile SoW – Quality Metrics (e.g.)
 Unit test coverage (e.g. >85%)
 Test automation (e.g. >80%)
 LOC (software): per Method, per Class
Agile SoW – Termination or Extension
 Early completion – notice (any Gain-share?)
 Late completion – (pain-share if due to unmet metrics)
 Cancellation/termination –
notice and compensation (if any)
Metrics: Although the “agile proponents” may resist the idea of maintaining quality
metrics, some metrics can help when disparate teams need to work together.
Understand of what is “normal quality” can vary. Metrics can help when project
reviews are done.
Termination or extension: The arrangements for termination or extension need to
be set-out. At one end of the scale it could be stated that termination could be
initiated at the end of any iteration. This might be acceptable for small
endeavours, however if the Provider has to mobilise significant resources then
there will need to be some cost (compensation) attached to the termination
process.
“Lateness”, if due to Provider negligence, may be a trigger for compensation to
the Client. The Agile process can help the Client to find out performance issues at
an early stage.
Notes:
24

26. Agile – Summary - Pros
 End Result - more likely to achieve an acceptable end
result due to early visibility of the solution by users
 Deliverables per Iteration - (lower T&M risk)
 Early Warning - risks and issues emerge much earlier
giving more time to address them
 Change Tolerance - less change management overhead
 Openness - significant transparency for the Client
 Scalability - in the event of significant Client-driven
changes
Notes:
25

27. Agile – Summary - Cons
 Client Overhead – Requires significant
commitment to involvement by the Client
and its user base – Not a hands-off situation
 Infrastructure costs – May need significant
investment to align tools
 Not “Document free” – Not a panacea
to radically reduce contract documentation!
 Risk - T&M basis leaves some risk on the
Client but with early warning of issues
 Personnel – Can find it difficult to
understand or “believe in” the Agile method
Users
Notes:
26

28. Agile – Real World Projects
Real project delivery model
Client
Provider
PM
Senior
User
Users
PM
Product
Owner
Team
Backlog
Controller or
Scrum Master
Release
The Agile approach REQUIRES commitment to COLLABORATION and
INVOLVEMENT across the whole team, particularly the Client’s team.
If this cannot happen (e.g. users are not available) then the Agile method will not
deliver its benefits.
The key resources are the Product Manager and the Senior User.
Senior User: An end user of the capability to be delivered (usually familiar with
the system being superseded): The Senior User needs to be able to manage the
expectations of the user team and ensure that disagreements are overcome to
provide a basically stable Requirement.
Product Owner: Represents the interests of the Client to the Provider Team and
makes decisions on the backlog for on-going iterations.
27

29. Agile – Real World Projects
Real project delivery model
Client
Provider
FP
Contract
Provider
PM
Product
Owner
Team
Backlog
Controller or
Scrum Master
Remote Team
(Subcontract)
It is possible to run an Agile process underneath a FPFS contract, for example if
the deliverable is a variant of a standard product offered by the Provider. In this
case the product Owner manages the Client’s interests based on fixed scope
changes as agreed under the contract.
Notes:
28

30. Agile – Real World Projects
Lessons Learned – Reviewer Questions
 Is there an Integrated Baseline? – Make sure that all top level requirements
are covered
 Is the Product Owner is trained in the requirements of an agile team and the
agile process?
 Retrospective meetings: Are targets being met?
 Average iteration velocity: Is forecast within limits?
 Check 8-11 random Epics/Features/Stories – Are these valid and complete?
 Is there continuing Client (User) dialogue to prioritise features (promotion and
demotion) during development?
 Has integration with Client systems been contracted separately (T&M
contract)?
 Is there enough allocation at the full cycle end to “harden” the solution –
Significant stress testing?
Notes:
29

31. Contracts & Procurement SIG
Q&A
Notes:
30

32. Thank You!
For John Lake
Tel : +44 (0) 1794 324715
Mob : +44 (0) 7798 583576
Email : john.lake@iecnetworking.com
For Jon Broome
Tel : +44 (0) 1179 09 3297
Mob : +44 (0) 7970 428 929
Email : jon@leadingedgeprojects.co.uk
setting | your | projects | up for | success
For John Lake
Tel : +44 (0) 1794 324 715
Mob : +44 (0) 7798 583 576
Email : john.lake@iecnetworking.com
For Jon Broome
Tel : +44 (0) 1179 09 3297
Mob : +44 (0) 7970 428 929
Email : jon@leadingedgeprojects.co.uk
setting | your | projects | up for | success
31