Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile contracting- APM Contracts and Procurement SIG, July 2016

153 views

Published on

Agile contracting
APM Contracts and Procurement SIG - Dr Jon Broome and John Lake
July 12th 2016
Roke Manor

Published in: Business
  • Be the first to comment

  • Be the first to like this

Agile contracting- APM Contracts and Procurement SIG, July 2016

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Contracts & Procurement SIG Q&A Notes: 30
  32. 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

×