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 theAPM’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

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

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

Presentation BackgroundThe “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

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

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

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

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

How do we Contract Agile?Some Backgound Research Norwegian (NTNU) thesis (2008)

https://www.researchgate.net/publication/267247519_Software_Contracting_and_Agile_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 Contractshttps://www.infoq.com/articles/agile-contracts

Agile Contracts Primerhttp://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%20software%20development%20projects.pdf

• Provides detailed description of what to be defined in a contract for Agile development.

9

InfoQ: Agile Contractshttps://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 Primerhttp://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

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

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

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

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

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

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

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

WorkingSoftware

Comprehensive Documentation

Customer Collaboration

ContractNegotiation

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

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

Agile – The Collaboration Approach Agile factors driving the contracting practice:

ClientProvider

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

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

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

Iteration, Functionality and Release Plan

Release v1.2UK, EU.

Release v1.1UK, 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 DecPV

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

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

Agile SoW – Communications and Tools

Channels – “SharePoint” is better than emailFull 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

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

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

Agile – Summary - Cons

Client Overhead – Requires significantcommitment to involvement by the Clientand its user base – Not a hands-off situation

Infrastructure costs – May need significantinvestment to align tools

Not “Document free” – Not a panaceato radically reduce contract documentation!

Risk - T&M basis leaves some risk on theClient but with early warning of issues

Personnel – Can find it difficult tounderstand or “believe in” the Agile method

Users

Notes:

26

Agile – Real World ProjectsReal project delivery model

ClientProvider

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

Agile – Real World ProjectsReal 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

Agile – Real World ProjectsLessons 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

Contracts & Procurement SIG

Q&A

Notes:

30

Thank You!

For John LakeTel : +44 (0) 1794 324715 Mob : +44 (0) 7798 583576Email : john.lake@iecnetworking.com

For Jon BroomeTel : +44 (0) 1179 09 3297 Mob : +44 (0) 7970 428 929Email : jon@leadingedgeprojects.co.uk

setting | your | projects | up for | success

For John LakeTel : +44 (0) 1794 324 715 Mob : +44 (0) 7798 583 576Email : john.lake@iecnetworking.comFor Jon BroomeTel : +44 (0) 1179 09 3297 Mob : +44 (0) 7970 428 929Email : jon@leadingedgeprojects.co.uk

setting | your | projects | up for | success

31