Procuring for agile projects
APM Contracts and Procurement Specific Interest Group January 2020

Scene-setting and the aim of this white paper

Traditional legal drafting likes certainty. It aims to nail down every detail or at the very least define the terms sufficiently to get a meaningful ‘fixed price’ from the market. But change happens on projects, and that means the parties can easily be drawn into fighting over the cost, timescale and the other impacts of the change rather than delivering what the client wants.¹ Furthermore, traditional projects delivered under contract are often delivered late, with a ‘big bang’ coming all in one go. On a long project, this ‘big bang’ (whilst delivered to specification) could end up meeting outdated stakeholder requirements or using out-of-date technology.

It is for this reason that agile methodologies developed in the fast-moving IT sector have become popular in the last decade.² However, the whole world – not just IT – is moving faster in a more VUCA (volatile, uncertain, complex and ambiguous) environment. Consequently, project delivery methods are becoming more adaptable and collaborative. As a result, delivery teams are prizing collaboration and iterative approaches where risks are evolving and outcomes are not easily specified. These trends can be summarised in a slide taken from APM’s ‘Projecting the Future’ project.

How might the future profession look?

As can be seen, ‘commercial/procurement’ needs to facilitate a move at a very high level from the safe ‘big bang’ approach to ‘experimental, incremental’ (i.e. agile). This is already happening.

Two other trends in contracts and procurement are also worth mentioning, as they both impact on and result from working in a more agile way. The arrangements are becoming:

• more outcome- or benefits-focused i.e. what the business/user wants from the project, as opposed to being led by the technical specification. This understanding of the needs and possibilities generally only develops over time and cannot be fully foreseen.
  
  
• more collaborative, particularly in projects and especially in programmes, where relationships are increasingly being constructed to be ‘win-win’. This is because longer-term productive relationships cannot survive and thrive if the parties to it are not getting what they want from the relationship. This compares with the illusory ‘fixed price’ approach, where both parties often end up fighting to be the winner in a ‘win-lose’ relationship. The reality is that it often ends up as ‘lose-lose’, with the so-called winner simply losing less than the other party.
  
  But it is important not to confuse ‘working collaboratively’ with ‘working in an agile way’. We consider ‘working collaboratively’ a necessary prerequisite for ‘working in an agile way’.

Up to now, if you wanted to procure in an agile way, there seems to have been two approaches: the illusory ‘fixed price and fixed deliverable’ approach discussed above, or a ‘time and materials’ approach with little incentive for the provider to achieve better outcomes at a lower cost.

The aim of this white paper is to outline how procuring and contracting approaches can be developed to facilitate and support a more agile approach in any sector where there is need for a commercial arrangement to deliver an unknown or changing outcome.

¹ This white paper uses the terminology of the Contracts and Procurement SIG’s (2017) APM Guide to Contracts and Procurement for Project, Programme and Portfolio Managers, ISBN 978-1-903494-66-0. It also loosely follows the same structure.

² In the IT world, there exists a set of welldefined methodologies known by the overall term ‘agile’ that are specifically designed to cover the efficient development of software (e.g. ‘scrum’). In this paper, we use the term ‘agile’ to have the more general, wider meaning of the word.

The development of this paper was kicked off by a three-hour evening event attended by roughly 20 professionals in May 2019.³ Three speakers, whose brief was to raise questions and issues to stimulate thought and conversation among the wider participants, each gave a 10-minute talk. Each talk was followed by a 45-minute exercise, including feedback, before the next speaker. The thoughts and conversations were collected on flip charts and Post-Its and then written up.

A smaller group – the authors of this paper – then met in June 2019 to discuss and refine this output and ‘storyboard’ the structure of this paper, both in terms of section titles and what the key points should be in each section.

The paper went through four drafts before its final published version.

Authors: Dr Jon Broome, John Lake, Jason Sprague, Graham Blakoe, Olubukola Feyisetan, Andrew Thorp & Kevin Ruddock.

³ The authors would like to thank PwC for providing the meeting facilities both for the initial event and the subsequent meeting.

As the authors, we want to be clear about what this white paper is and is not covering:

⯀ It is not aimed solely at IT projects. It is about procuring and contracting for any project or programme in an agile way – whatever sector that project is in.

⯀ We are not basing our suggestions for the procurement and contracting on any specific agile methodology in terms of rules for project control.

⯀ We see a spectrum of project types, where traditional ‘waterfall’ (in IT terminology) project management might be suitable at one end, but a full-on agile methodology might work better at the other. This paper is about procuring and contracting projects towards the agile end of the spectrum, not necessarily at the extreme end.⁴

It is also worth stating here that the procurement and contracting approach may change throughout a project.

⯀ We are not prescribing that this is how you should do it. Instead, we are presenting some questions you need to ask yourself and some suggested principles and approaches.

⯀ We absolutely are not saying ‘abandon good project management practice’. You still need good short-term planning for the sprints/projects, and you need even better and slicker programme management to do the right sprints/projects in the right order to maximise your contracted resource’s efficiency (to keep the resource working) and effectiveness (delivering what you want, when you want it).

⯀ You can deliver projects and programmes between parties without an agile procurement and contracting approach. However, having a commercial arrangement that works with, rather than against, this ethos can only be beneficial.

⁴ One of the contributors to this paper defined the essence of agile working as “rapid and informed decision-making to deliver something useful”. Ergo, we are talking about ‘more rapid and informed decision-making to deliver something useful more often’ than traditional methodologies.

It is easy to say that you want to contract in a more agile way, but your organisation may have to fundamentally change its mindset about contracting. Your organisation should ask itself these and other questions, answer them honestly and be prepared to change. Recognising that change is typically driven from the top down, these questions should be answered, understood and accepted at the highest level:

1) Provider selection: Is your procurement function willing and able to select the providers on the basis of technical competence, collaborative ability and input costs rather than on a fixed price for fixed scope, which simply gives the illusion of certainty?

2) Governance and decision-making: Are you willing to change your current governance procedures, moving from a typical gate model, with all its sign-offs and delays, to a more fluid model where you work with providers to select the best projects to do at the time (given your outcomes) and then instruct them in a timely manner so that the providers can resource and execute it properly and efficiently?

3) Legal considerations: Is your legal department comfortable with and signed up to having lighter, more flexible, shorter contracts with far fewer remedies and which define how the parties will work together as opposed to what has to be delivered?

4) Project controls: Are your administrative departments - including contract administration, change control, quality assurance, finance etc. - comfortable with iterative processes and documentation that needs to be done in a timely manner?

5) Skills and culture: Are your people able to work in a more collaborative and agile manner? Have they got the relevant skills? Are they capable of changing their attitude and style? Are you prepared to put the resources into the new or modified systems, the organisational structure and the people to help them change?

6) Wider buy-in: Have the wider organisation and key stakeholders bought into the approach? Do all parties recognise and accept that what is really being procured is, at the extremes, a managed team of competent resources rather than a fixed deliverable?

In industries such as construction, the contract is often with a prime contractor, who subcontracts almost all the physical work to other companies under the prime contractor’s control. In order to deliver in a more agile manner, the agreements with these subcontractors must also reflect the agile working and motivate them accordingly. This may necessitate direct meetings with key subcontractors to ensure understanding and buy-in to the approach.

7) Leadership support: Do your CEO, CFO and supply chain understand why you are doing this? Do they buy into it? Are they willing to actively champion it?

The position of your planned projects on the traditional/‘waterfall’ to agile spectrum should provide an indication of the scale of the change necessary.

Below is a table to give an indication of where on the traditional/‘waterfall’ to agile spectrum a potential contract package falls. On each row, tick where you think your project or projects typically sit, then add up the ticks in each column. This should give an indication of where on the ‘waterfall’/agile spectrum your project or projects sit and hence the nature of the arrangements – not just with respect to contracts and procurements – used to manage the project, programme or portfolio.

If the majority of ticks are on the right-hand side, then it would indicate that the potential package sits on the agile side of the spectrum. Consequently, the remainder of this paper might apply to you.

Our top 10 characteristics

We suggest that a contract for packages of work to be delivered in an agile way would have the majority or all of these characteristics compared with contracts for more traditional, ‘waterfall’-type projects:

1) It is designed collaboratively with provider input. This is not to say you single-source it, although you may. However, the market and then perhaps the shortlisted potential providers are consulted on what would make the contract attractive for them to work in an agile way which delivers to your objectives, with their suggestions enhancing the contract. You are harvesting the value from them early on.

2) The focus is on ‘how’ the parties work with each other, not ‘what’ is delivered, because there is an acceptance that the ‘what’ will change and evolve as it is being delivered. The contract should presume, encourage and enable collaboration and good project management, as we want the best and most timely decision-making. This contrasts with the traditional contracting approach of fighting change (and often each other).

3) Each deliverable/sprint/project can be instructed as a task without the need for a new contract to be negotiated and signed. The aim is to avoid potentially lengthy traditional corporate governance requirements, including directors having to sign contracts before work can proceed. Obviously, there should be appropriate governance in terms of selecting and instructing the right tasks in the right order, as well as metrics to measure performance in terms of both efficiency and effectiveness. However, there must be a focus on making timely, informed decisions.

4) The contract describes the overarching programme management and technical requirements, so that only the specifics of each task need to be in each task order. This is so that a task order can be put together quickly and those involved do not need to review masses of text for each task. Likewise, the results and outcomes of each task need to feed into project controls rapidly to inform the decision-making.

5) The conditions of the contract need to be high-level, with the more detailed ‘how’ sitting in the requirement. Over the long term, as the relationship evolves, the ‘how’ is highly likely to evolve and therefore needs to be able to be changed.

6) Detail (of both the ‘how’ and ‘what’) is ‘just sufficient’ to provide a framework, but not over-prescriptive, so as not to stifle innovation and creativity. Even so, it should ensure the provider delivers what is wanted in an effective manner.

7) Payment is primarily based around the cost of inputs rather than an agreed price for outputs, i.e. ‘time and materials’ or demonstrable cost, as opposed to delivering something. This is in part because resource is likely to be more fixed, but also because it promotes greater openness and transparency. But…

a. a completed task is one which delivers something useable, and;

b. input-based payment mechanisms are supplemented by positive incentives, which vary depending on the characteristics of the work and which are related to desired outcomes/ benefits being achieved.

8) The emphasis is very much on ‘carrots’ rather than ‘sticks’. Research⁵ – and our own experience – clearly demonstrates that the ability to make deductions, charge high damages and so on all inhibit creativity and innovation. Instead, they encourage the hiding of problems which, when they come to light, result in arguments of blame in order to avoid liability, rather than just solving them. As one of this paper’s contributors said, “a lack of sticks enables teams to fail fast and openly and then move on”.

9) Liability, where possible, should be for failing to ‘exercising reasonable skill and care’. All of the points above imply that you are buying a service rather than an end result. Additionally, if each task is contracted on the higher ‘fit for purpose’ level of liability, then more time will need to be spent by the client in nailing that purpose in the documents and by the provider in understanding the risks before accepting and undertaking the task. This will inhibit rapid decision-making. Having said this, the documentation for each task does need to be ‘just sufficient’ to adequately define what is required.

10) The ‘how’ is based on collaboration with a presumption of trust – trust in competence, trust in integrity and trust in the sensitivity to each party’s needs. Without trust, bureaucracy, administration and defensive behaviours stifle collaboration and the ability to be agile.

Some, like one of our contributors, would argue that much of the above is good procurement and contract-drafting practice… and they would be right.

⁵ Broome J C, Procurement Routes for Partnering: A practical guide, Thomas Telford Publishing, London (2002). ISBN 0 7277 3136 X

Based on the previous section, these points are relevant to both the preparation and operation of the contract. We have tried to arrange them in an approximate order in which they need to be addressed:

1) Get your decision-making processes in order: Internal procedures, particularly regarding governance, will need to be re-engineered so that they work within the timescales demanded by the chosen agile approach. This will need to be thought through in advance of writing the contract so that how a task order receives the go-ahead and the obligations of both parties to make it so are clearly spelled out. The decision-making process needs to align with the project controls and the feedback process.

2) Put stakeholder engagement at the heart of the decision cycle: Stakeholder engagement – be they the user, those involved in governance or other providers working on the same programme – is likely to be high and needs to be done early. How to do this should be a strong feature of the contract.

3) Establish how success criteria will be set: Determine the process by which emerging and evolving targets, against which positive incentives may be set, are going to be agreed. Research clearly demonstrates that negotiated incentive arrangements work better than those that are imposed, but you want a structure for doing so. Your decision-making and stakeholder engagement processes, as well as up-to-date and realistic assessments of risk, feed into this.

4) Contractual-ise the critical agile methods: If you are selecting a provider based largely on how they will work with you – be it systems, the organisational structure of their team and/ or people – incorporate the provider’s ‘how’ (its agile method) into the contract. This needs to be a consideration in contract design, e.g. how is the contract structured so that the client’s higher-level requirements flow into the provider’s specifics? What happens if there is a contradiction? I.e. which has precedence?

5) Project owners must own the agile processes: The authors of the ‘how’ documents should be the people who will work with the provider, so that they have ownership of the processes and systems. They should be project-managed to ensure that they are not being overprescriptive or simply documenting how it has always been done. Some redrafting may be needed to ensure that what is written is contractually sound.

6) Bring subject-matter experts with you: Legal and technical authors need to be properly briefed with respect to working in an agile manner. They need to be project-managed and coached so that the agile system can operate – especially to ensure they do not revert to type by becoming over-prescriptive and detailed, by writing a contract incapable of changing as the relationship develops, or by introducing excessive remedies.

7) Allow for change over the duration of the relationship: The provider is likely to be engaged much earlier in the project life cycle to help develop the concept, assess different delivery options or methods before moving into a delivery phase. So it is very likely that the ‘how’ will evolve as the project or programme progresses. This is not just because of the developing relationship, but also because of the different nature of the work being done, e.g. it may initially be consultancy-based, before becoming more delivery-focused. Previously, we talked about tasks being instructed under one contract. However, it might be that as the nature of the work instructed fundamentally changes, a new contract needs to be put in place. These contracts could be linked together by an overarching framework-type contract (which also happens to provide a natural break if the client decides not to proceed with the programme or if it is not working out with the initial provider).

8) Pay for insight, information and decisions: Once a provider has been selected, they should be paid for their effort. This is for two reasons: firstly, you will have to pay for it somewhere and if it’s not done directly, costs will be hidden, undermining transparency and trust. Secondly, until a contract is signed, you may be working with a different team (e.g. business development) to the one that will deliver the work. This should be clearly stated in the tender documents, otherwise there is a risk that the provider will be paid twice.

The key challenge is that there will only be a loosely described outcome or output on which to estimate, and this will almost certainly change. Consequently, selecting a provider based on end price for an ill-defined and changeable scope to give the ‘illusion of certainty’ is of dubious logic. The financial assessment should therefore be based predominantly on input costs.

Public-sector clients face a particular challenge, as they have to select on a most economically advantageous tender (MEAT) methodology with strict compliance constraints which, if not followed, could result in fines, compensation and/or the competition being set back to zero, thus meaning they have to start again. However, the concept of achieving ‘best value’ – benefits delivered over the whole-life cost of the project – also applies to the private sector.

We suggest that the procurement is approached with this perspective:

• An agile approach to working has been chosen on the basis that is more likely to achieve better value than a traditional ‘waterfall’ project management method;
• The contracts reflect this chosen way of working; and
• The selection criteria used should reflect what will make this way of working operate most effectively and efficiently.

Or, to put it another way, the basis of selection is not the lowest initial price, but the right people, organisation and processes to achieve the best value.

Public-sector clients typically select potential providers based on financial standing and previous experience, with previous experience typically being related to similar technical experience. We suggest this criteria should also include previous experience of working in an agile way, or at the very least a collaborative way.

For the final selection, we suggest that the ‘quality’ part of the bid, like the contract documents, should focus more on how they will work with you, rather than what they will deliver. For instance, think about how their organisational structure will combine with yours; what systems, process and procedures they will use; whether they will replace, work alongside or integrate with yours; and above all, who they will provide with evidence both of technical capability and collaborative/ agile ability. Ideally, these can be expressed as contractual commitments and incorporated into the contract.

If you are a public-sector client, financial criteria must be a component of how you select a provider, and it would be naive to ignore this aspect as a private-sector client. We believe the focus here should be on realism rather than the lowest cost for it to be sustainable for the provider. This should be both for profit and operating margin, as well as for any resources directly allocated to the client (because you are unlikely to get superior resources allocated to you over the long term if you are paying below the average market rate).

1) Do your thinking early: Much of this has already been decided by how the contract was written, which included the provider contribution, so you need to have done your thinking early.

2) Collaboration is a means to an end, not the end: Do not confuse working collaboratively or in an agile way with being nice to each other. Equally, it does not replace good project and programme management practices. Collaboration should mean that together you can make better and faster decisions due to strong project controls, more rapid and honest feedback, and greater realism about risk. Working collaboratively also does not mean sweeping the hard issues under the carpet in order to avoid confrontation. It does mean identifying and addressing those hard issues early, resolving them using each other’s expertise and with regard to the impact on the other party.

3) Agility needs to be nurtured: This applies at all levels of the organisations that interact with each other, in addition to the delivery team. There will be issues and misunderstandings, and the easy thing to do is to revert to type. Leadership from all parties will need to step up.

4) Collaboration is not just about ‘behaviours’, but also infrastructure: Effective infrastructure is needed to support efficient working and ensure there is ‘one version of the truth’. The ‘how’ of working together might include:

a. Booked-in meetings, not just to progress tasks but also ‘time-out’ workshops to consider how the relationship and the ‘nuts and bolts’ of operating it are working and can be improved. It makes sense to use agile methods to do this, e.g. value mapping, a plan-docheck-act (PDCA) cycle, gemba walks and/or kanbans;

b. a shared database of project information;

c. shared planning tools between the parties;

d. videoconferencing and other collaborative technologies if the parties are geographically distant; and e. common reporting standards.

5) ‘Just sufficient’ governance: This needs to be in place for the client’s project manager to be able to instruct the right tasks or sprints promptly so that the provider’s resources are not being used inefficiently or, worse still, are on stand-still.

6) Governance of the ‘how’ (not just the ‘what’): This needs to be in place to prepare for changes in the ‘how’ as the relationship develops. Because the contract defines the ‘how’ at a ‘just sufficient’ level, this should not mean that every adaptation needs to be approved. However, the contract documents should be able to be updated periodically to reflect both the reality of how the parties are working together and how they aspire to work together in the future.

All of the above can be seen as an increased overhead of managing the contract… and that’s exactly what this is! However, the benefits should be much better delivery (i.e. what you want from the contract), less administration, and fewer arguments and disputes. The benefits of working in this way should outweigh those of working in a more traditional, transactional manner. The benefits, therefore, need to be recorded.

The approach taken to developing this white paper has been to collect the views and real-world experiences of a group of interested volunteer project professionals to structure and refine that information. The purpose of this white paper is to equip commercial project managers and project-based procurement professionals, as well as senior decision-makers, with some pointers regarding:

• the internal organisational changes that are likely to be needed for an agile contracting approach to be successful, and ways to ensure that senior management buys into and endorses it;
• identifying what sort of projects and programmes might benefit from an agile approach. The view of those consulted and the authors is that there is a spectrum of project types, where traditional ‘waterfall’ project management might be suitable at one end but a full-on agile methodology might work better at the other. We provide a scale to identify where your projects and programmes are on this spectrum;
• what the contractual arrangements might look like. While we give our top 10 characteristics in terms of contract features, the result is a contract that focuses more on the ‘how’ rather than the ‘what’, that has built-in flexibility, that is likely to be input-/cost-based and that both presumes and encourages collaboration between the parties through positive incentivisation;
• how to develop the contract. This can be summarised as project-managing the drafters to ensure they do not revert to type, be they legal or technical drafters;
• the key considerations in selecting the provider, which could be summarised as searching for a track record of working in an agile, or at least collaborative, way. Likewise, final selection is based more on how the provider will work with you and less on what they will provide. It therefore makes sense to design the contract to incorporate how the provider has said they will work with you in an agile way; and
• managing the contract in a collaborative manner with good project management discipline, especially in terms of slick governance when it comes to selecting, in a timely manner, the right task/sprint to do.

We reiterate that this work is not intended to be any way prescriptive, more to give the reader a level of perspective.

Finally, the APM Contracts and Procurement SIG, now Interest Network, wishes to express sincere thanks to the contributors to this paper, both those who attended the initial workshop and especially those involved in drafting this paper, for taking time out from their busy schedules to give us the benefit of their experience in managing contracted works.

APM Contracts and Procurement Interest Network

It aims to become a lively and constructive debating forum which takes existing best practice and helps make it better. The Interest Network wants to disseminate this knowledge, understanding and better-than-best practice through a variety of accessible means.