commercial engagement in an agile worldsig.org/docs2/commercial_engagement_pa_consulting... ·...

© PA Knowledge Limited 2015 1

COMMERCIAL ENGAGEMENT IN AN AGILE WORLD SIG, Bay Area

September 13, 2016


Agenda

The changing nature of IT 1 Software development in an Agile way 2 Agile commercial approach 3


COMMERCIAL ENGAGEMENT IN AN AGILE WORLD

01 The changing nature of IT


A number of significant trends have been changing the shape of IT across all industries and organizations

Big Data Consumerization of IT

Ongoing need for cost savings Maturing market

The changing nature of IT


Migration to the cloud has undergone a number of significant waves as services have matured



Adoption of cloud services is dependent on any organization’s underlying strategic appetite, however benefits (and challenges) scale rapidly with ambition

The key driver for IT leaders is to provide services to their customers at greater breadth, depth of information and speed

Be tactical Be differentiating Be transformational

“We

will…

”

•  Ensure that the business has a safe framework in which to access Cloud services

•  Encourage innovation

•  “Fail early and often”, quickly adopting successful experiments into production

•  Avoid wholesale challenge to enterprise constraints (legal, security, political, regulatory)

•  Make a once-in-10-years change

•  Achieve breakthrough unit cost reductions (typically 30-40%)

•  Change the way the IT organization supports business capabilities

•  Change the way the business thinks about and uses IT

•  Challenge the status quo

•  Focus on enhancements that move our business 12-18 months ahead of competitors

•  Deliver better service levels, scalability, agility and user access for specific services

•  Access new capabilities such as big data analysis for better business insight

•  Avoid costs otherwise required to address substantial growth

•  Address enterprise constraints



Example - the UK Met Office rapidly extended their breadth to deliver their first global amateur weather portal

•  Wanted a safe way of capturing weather data from the public to augment its own weather data

Business challenge

How cloud helped

•  Provided a social platform that automatically scaled up and down as demand dictated

•  Used a hybrid cloud/behind-the-firewall architecture to get the cloud-scale processing and maintaining personal data securely

•  Costs $70 per day to run

•  Rapid data capture and display

•  Rapidly scalable to match demand

•  API-driven integration to many sources

Critical Capabilities



Example - The depth and value of big data was rapidly demonstrated for the UK’s National Health Service

•  Wanted an inexpensive way to process very large data sets – over a billion rows

Business challenge

How Google BigQuery helped

•  Very cheap data storage costs ~ 12 cents per Gb per month

•  Very quick query times – querying 200 million records in less than 20 seconds

•  Integrated with other Google tools for very rapid proof-of-concept – think a couple days instead of months

•  Secure storage of massive data volumes at low cost

•  Provide more value-add reporting services to customers

Critical Capabilities



Transformational Once in 10 years

Differentiating 12-18 months ahead of others

Enabling innovative ideas within the business

Rapid response to customer needs

Whichever approach is taken, considering the customer journey is an increasingly important aspect determining the scope and speed of change

Tactical Delivering benefits in weeks

Fundamental business operation change



Maturing cloud service models offer a variety of options for IT leaders to deliver solutions to their customers

However, the challenge is that not many enterprises are starting from a green field environment – this raises a number of hard questions…



“I already have significant outsourced managed services and development contracts”

•  What do I do with my current managed services provider ?

•  How do I transform my infrastructure for the cloud ?

•  Should I get out of the data center business ?

And what about development of my applications ?

•  Can I develop software differently ? For example using Agile ?

•  Will bringing development in-house improve quality and speed ?

•  If not, what is the best way to contract for this ?

Questions for IT & Sourcing leaders




02 Software development in an Agile way


Typical challenges

Why is it hard to deliver quality software?

•  Requirements evolve •  Silos between teams

•  Inconsistent processes within the organization

•  Difficult and time consuming defect and issue resolution

•  Short deadlines and managing constant scope change

•  Compliance and governance mandates additional constraints

Software development in an Agile way


Agile is an iterative and incremental, customer centric, method of doing work in a highly flexible and interactive manner:

•  Avoids big upfront design and ‘big bang’ delivery in preference to iterative

development, short feedback loops, and multiple releases

•  Fixed time and budget, floating scope

•  Promotes adaptive planning, evolutionary development, early delivery,

continuous improvement, and encourages rapid and flexible response to

change

•  Useful not only for improving the software development lifecycle but other

business activities

So why is Agile becoming more prominently used?



Traditional software delivery method

Month 1 Month 2 Month 3 Month 4

Risk

Time

Stage gates

Month x …

“Managing the Development of Large

Software Systems”, 1970, Winston Royce



Iterative software delivery method



•  In the iterative approach, requirements are delivered in slices called ‘user stories’

•  The user story looks at the functionality that a system should provide in terms of:

•  the roles of users, called actors

•  the functionality they need, called acceptance criteria

•  Many find this way easier to work with, it also enables iterations to deliver meaningful slices of the system to users

•  User Stories are broken down and refined in the backlog

•  Items at the top represent the highest priority stories that are “ready” for implementation

Iterative development



•  Visibility: frequent Sprint reviews, show & tell

•  Value: early delivery of real working software

•  Adaptability: requirements and solution not fixed in detail up-front.

•  Risk: early delivery of real working software targets risky areas early

•  Resulting Satisfaction: should be far higher for all stakeholders

What makes Agile great for project delivery?




03 Agile commercial approach


Assumptions •  Can reasonably articulate target state at the beginning

•  With the target state articulated correctly, failures will then be due to the supplier; this is the risk to be managed

Challenges to be managed •  Contract sets up a transactional customer / supplier basis that often carries through to the way of

working on project •  Motivations between customer and supplier misaligned in a standard fixed price contract

Recourse •  Lack of evidence in Waterfall lifecycle can mean issues come to light after most of the time and budget

has been consumed •  Ultimate performance sanction is the threat of legal recourse

•  Legal recourse is rarely straightforward though, often expensive and drawn out

Typical contract inputs Full signed off requirements

Agreed quotation for work

Expected outputs System

Supplier payment per phase

Project Purpose

How the Project is Run

What Happens When Things go Wrong

Contract

Waterfall contracting model

Agile commercial approach


Typical contract inputs Agreed set of target

outcomes Way of working and

estimating model

Expected outputs System increments

Supplier payment per increment

Project Purpose

How the Project is Run

What Happens When Things go Wrong

Contract

Agile contracting model

Assumptions

•  Cannot reasonably articulate target state at the beginning

•  With outcomes and ways of working agreed, failures occur when the relationship breaks down or a party takes advantage

Challenges to be managed

•  Without an agreed specification it can be challenging to identify the most cost efficient supplier

•  Estimation models must be used to maintain a level of cost control but these can be gamed

Recourse

•  Performance management is via the relationship and commercial threat of ending the contract early

•  Incremental delivery provides concrete performance data that can be used to manage the supplier before the full budget and time has expired



Vendor relationships

The Agile approach works best with a collaborative relationship rather than the transactional type.

Where vendor relationships have soured, Agile may not be the best approach as it requires trust and close working

•  The client must trust that suppliers will behave reasonably as requirements emerge and change

•  Suppliers must trust that the client has gone to reasonable lengths to articulate the perceived complexity of the challenge from the outset

Where relationships are perceived to be poor a greater level of upfront requirements specificity may be helpful



Common commercial approaches

Simplest form – pay for effort

Used when outcomes / effort are uncertain

Requires trust and confidence and close management

Used when certainty of cost is main driver

Needs clear definition of outcomes, assumptions and dependencies

When up front cost is the issue and when you are concerned with maximising benefits

Can be a share of return

Needs clear measurable benefits and clear assumptions and dependencies

Used to ensure focus on delivery of clearly defined outcomes

Focuses on payment trigger – the amount can be fixed, based on effort or outcome

Needs clear acceptance criteria

When you want to transfer ownership of service to the supplier and have little interest in the absolute cost of delivery of service

Payment can be fixed for a service or on a ‘pay per use’ basis

Share of Benefits

Payment on Delivery

Managed Service Price

Fixed Price

Time & Materials



Two phase and progressive acquisition contract models

Two contract types are commonly used in the Agile model:

•  Two phase: The two-phase model uses one contract for ‘System definition’ and one contract for ‘System acquisition’

•  Progressive acquisition: This model uses a head contract and a separate call off for each Iteration

There is also a Start phase which is completed by the customer only.

A single contract covering the entire supplier engagement doesn’t typically give the same flexibility as the two above models.

We will look at the two-phase model.



Customer and supplier motivation in a two-phase contract

Start System Definition System Acquisition

Cus

tom

er Su

pplie

r

Motivations

• Getting scope clear

• Securing funding for the project

• Stakeholder access

Motivations

• Winning the System Definition contract

• Demonstrating capability

• Building relationships

Motivations

• Getting the architecture base-lined

• De-risking & demonstrating quick win functionality

• Getting the right partner

Motivations

• Winning the much more lucrative contract

• Demonstrating delivery capability

• Being seen to go the extra mile

Motivations

• Showing the right rate of progress throughout the phase

• Ensuring that quality is acceptable

• Users increasingly satisfied with incremental product releases

• Delivering on time and budget

Motivations

• Continuing the contract through the high-value period

• Preserving profit margin through:

• High quality releases with few fixes

• Stakeholder satisfaction

• Maintaining a good relationship through strong delivery

Contract 1 Contract 2 No contract, customer only



There are a number of commercial techniques to be used to align motivations

Payment milestones (e.g. phase completion) and delayed payments

Risk / reward techniques align motivations between customer and supplier and support collaborative working

Fixed profit is a technique that lowers margin as the work is extended by Change Requests (CRs) or cost overruns

Combining fixed price and T&M models in a phase can give further flexibility

Quantifying via the contract how scope increases will be handled (e.g. function / story points) can reduce protracted dialogue when discussing Change Requests (CRs)

Fixed profit

Mixed models

Quantitative scope definition

Risk / reward

Payment milestones



Designing for exit during contracting

We have seen that Agile presents a more complex commercial and legal basis

A common result is that the balance of power ends up with the supplier, via an open-ended T&M contract

Designing for exit helps in two ways:

•  By making exit easier if required

•  By making a threat of exit more realistic

It is one tool in restoring the balance.

Think up front about the challenge of what to do with a part-live system and consider exit before too much risk is accumulated

Key considerations:

•  Access to documentation, data and the ability to use code and designs

•  Agreement on the support that will be provided on exit (e.g. employment, ownership of deliverables and the system, operational support for a part-live system)

•  Full consideration of IP ownership and agreement allowing another supplier to take over the development and operation of the customer’s deployed system

•  Knowledge transfer activities including producing new documentation if required to facilitate smooth transfer to the customer or another supplier

•  Continuous review and independent verification, to ensure what is handed over is of good quality and can be taken forward



6. Separate into two phases

7. Systems Definition SOW

5. Produce Indicative Price

Range

Epics

Features

User stories + delivery dates +

Acceptance Criteria

4. Develop stories from Initial Project

Brief

WO

RK

SH

OP

Agree risk share % and how much supplier can recover if System Definition Phase fails. Agree also who pays if Indicative Price is exceeded

Agile Two Phase Commercial Model

Use Capped T&M

1. Customer requirements

2. Client confirms

methodology

3. Waterfall

•  Top 30% scope by high risk, high priority

•  Definition of Done for each increment

We include within System Definition things which are:

•  High business priority or risk

•  High delivery risk from the suppliers’ perspective

•  Things which are the necessary foundations from a System Architecture’s perspective

In other words we do the difficult things first and bring risk forward in time

Option 1 – risk share means % supplier can recover - then consider 50% which means the supplier can recover 50% of the total Systems Definition cost in the case of its cancellation or failure Option 2 - use Capped T&M with provisions for 80% billing following supplier issuing an impact assessment



1. System Definition SOW (Capped T&M, not to exceed 20-30% of scope)

Outputs *:

- Reference Story A – built, tested and in UAT/Pre-prod+ – cost $xxx.xx

- Reference Story B – built, tested and in UAT/Pre-prod– cost $yyy.yy

- Reference Story C– built, tested and in UAT/Pre-prod– cost $zzz.zz

- Reference Story D – built, tested and in UAT/Pre-prod– cost $aaa.aa

- Reference Story E – built, tested and in UAT/Pre-prod– cost $bbb.bb

- plus Estimation model for use in next phase + traditional estimation will also be needed to make fully operational – this should be

rolled into estimation model for reference story

Payment Milestone paid when “acceptance criteria” met

System Definition (checkpoint) phase is contracted for using Capped T&M to fulfil the following: •  estimate, develop and build the reference stories •  build the estimation model for all System Acquisition (reference stories, story points and

criteria for assessing the fit of new stores to the reference stories) •  deliver an executable set of reference stories •  deliver an estimate for the full scope

Scope may not exceed 20-30% of the total program scope (defined in story-points) for functionality where new reference stories are needed

Part of the Acceptance Criteria for the System Definition Phase is that the Deliverables (reference stories, estimation model etc.) are fully capable of being handed to another Supplier for Systems Acquisition



6. Separate into two phases

9. Systems Acquisition

SOW

7. Systems Definition SOW

Move to Systems Acquisition once the estimates have been validated Ensure clarity around the following items: •  Who owns the library of reference stories? •  Can Supplier B use the reference stories of Supplier A? •  Who owns the IPR?

7a. Reference stories

delivered

8. Estimation model for ref

stories

7b. Disagreement

•  Estimates validated •  Price for System Acquisition is fixed

Linked SOWs

5. Produce Indicative Price

Range *

Epics

Features

User stories + delivery dates +

Acceptance Criteria

4. Develop stories from Initial Project

Brief

WO

RK

SH

OP

Moving to Systems Acquisition SOW

1. Customer requirements

2. Client confirms

methodology

3. Waterfall

Agree risk share % and how much supplier can recover if System Definition Phase fails. Agree also who pays if Indicative Price is exceeded

Use Fixed Price or Gainshare T&M

Risk brought forward and mitigated

•  Quick escalation •  Dispute resolution

•  Termination of SoW

•  Top 30% scope by high risk, high priority •  Definition of Done for each increment

Use Capped T&M (leave capping as is)

Option 1 – risk share means % supplier can recover - then consider 50% which means the supplier can recover 50% of the total Systems Definition cost in the case of its cancellation or failure Option 2 - use Capped T&M with provisions for 80% billing following supplier issuing an impact assessment



2. System Acquisition SOW – (Fixed Price1, 70-80% scope)

Output:

Stories F,L,Q are like Reference Story A – so each will cost $xxx.xx

Stories G,O are like Reference Story B – so each will cost $yyy.yy

Stories H,R are like Reference Story C– so each will cost $zzz.zz

Stories I ,M,N,S,T,U,V are like Reference Story D – so each will cost $aaa.aa

Stories J,P are like Reference Story E – so each will cost $bbb.bb

Payment Milestone paid when “acceptance criteria” met Payment Milestone – agreed

when “acceptance criteria” met but held back till full completion

(pragmatic position to protect the buyer)

* Suppliers will need to articulate top risks as Part of SOW for Systems Definition

1 The buyer to confirm whether T&M is a possible option for System Acquisition

System Acquisition is contracted for the rest of the project scope (increments F,G,H ….V) It is a set of Increments, each containing a set of stories, each mapped to a Reference Story Estimated based on the reference story implementation done in the System Definition phase If the supplier gets the Reference Story mapping wrong, they must absorb the difference if up, and reduce the estimates if down Each Delivery Increment has a price associated with it that is payable as a payment milestone following acceptance at the end of that increment The buyer will hold back e.g.the last 10-15% of the payments to be released once the full set of Deliverables is proven to work in a fully integrated system as agreed (in the Customer Requirements) The warranty period will start once the Deliverable is Accepted


Up front agreement on an escalation process will support collaboration

story estimate has gone up

Within deviation

limits?

Can story be

simplified whilst

retaining value?

Can another future

story be simplified?

Yes - proceed – fixed price covered by contingencies

Yes - proceed – fixed price met due to simplifying story

Yes - proceed – fixed price met due to simplifying future story

No

No

No – no agreement

Can scope steering group

provide a decision?

Yes – decision provided

No

– no agreement

Can executive

scope steering group

provide a decision?

Independent expert view No

- no agreement

Finish

Start

One of the characteristics of the Agile process is that requirements are not defined up front. This means a relationship of trust and respect is key to the success of the arrangement and this must be supported by escalation routes that support that relationship

Given that most problems in a technology project manifest themselves as some form of increased cost or time, a graduated escalation process helps to maintain the right type of relationship

Yes – decision provided



Summary

Agile adoption impacts other teams and processes, such as supplier management and commercial engagements.

Agile is a more complex approach, with more options available to project teams and vendors

Supplier management teams can add a lot of value by acting in a consultative style to projects

Use various techniques to even out the balance of power and to align customer and supplier motivations

Fixed price deliveries are more complex to configure but are an option all the same

Agile approach enables earlier intervention in poorly performing projects

With the right contractual and supplier management support, Agile will deliver good outcomes for the business, when it is used in the right circumstances

Summary


? Questions


For more information

Nick Semple [email protected] +1 213 479 2785

We are an employee-owned firm of over 2,500 people specialising in management consulting, technology and innovation.

INDUSTRY SECTORS Energy Financial services Life sciences and healthcare Government and public services

Defence and security Telecommunications Manufacturing Transport and logistics

PRINCIPAL OFFICES North America Europe Nordics

Gulf Asia Pacific 24

8

UNCONSTRAINED THINKING EXCEPTIONAL RESULTS Clients choose us because we are committed to bringing them the right expertise – unconstrained by conventional thinking we deliver exceptional results with lasting impact.

The PA Promise

The right team We focus our expertise where you need it most. Committed to a common goal, we are free to pull together experts from across our whole firm to ensure you get the right team.

Unconstrained thinking You get team players driven to understanding individual needs and finding new ways of unlocking your business’ potential – challenging assumptions, unconstrained by conventional thinking.

Exceptional results Our experience and commitment to doing things right mean we will overcome every obstacle and together deliver exceptional results for you and your company.

Lasting impact Our work goes beyond getting the job done – we share our knowledge to create a lasting impact and a brighter future for your organization, your people, your customers and you.

commercial engagement in an agile worldsig.org/docs2/commercial_engagement_pa_consulting... ·...

Documents