Lean-Agile Contracts

Continuous Customer Collaboration

As a transformation coach/consultant, one of the questions that get most frequently when talking to the program and accounts is, Okay; even if we implement some of these agile practices (yes practices, they don’t talk about culture, values, principles, and mindset yet) internally for our technical delivery teams how do we take this to our customers?

Our customers are not asking us to be agile. They do not want to change. We see the risk if we try to impose the internal drives/initiatives on them. And many more !!

And even if we think to initiate these conversations with them how do we manage the contracts with them? Commercial agreements? Pricing policy? Engagement model and so on.

Here are some of my views based on my reading, learning, and experience so far on this transformation journey.

What is a Contract?

1. A contract defines the collaboration between two entities and reflects not just the project goals of the parties involved but also their values and mindset.

The contract defines the playing rules, which in turn drive people’s behavior.

2. A contract substitutes for a lack of trust. The more trust exists between client and supplier, the less you will need to write down.
3. Contracting with an Agile partner will work best if both parties apply the Agile values and principles, and if the contract is compatible with those values and principles.
4. Supplier Management is a “continuous procurement process that ensures suppliers – and buyers – adhere to their agreed contractual obligations, along with negotiating any future changes that need to take place.”

 

Why a Contract (or what goes in the contract)?

1. People come and go, so the people you are dealing with now may not be the same decision-makers in the future. And even people at the top of the organization have ups and downs in their power and influence. A contract offers continuity in the face of changes to organizations. (legitimate)
2. To bring a common understanding and hence risk handling. (understanding about the scope, budget, timelines, quality, vision, direction, etc) (legitimate)
3. Risk management, most risks occur when you must make a decision based on incomplete information. You make an assumption, take a decision, spend the money, and hope for the best. Sometime later the facts will emerge (validation phase). (can be addressed in better ways)

If your assumptions were correct, then you get the return or other benefits you hoped for. If not, your time has been wasted and your money is lost.

4. A contract manages some risks but not all of them. A good contract won’t compensate for bad collaboration, though good collaboration can render a bad contract irrelevant.

 

What are some of the risks?

1. Delivery Risk: Will I get anything usable at all?

 

What if you don’t have to wait for the entire duration of the project to get the delivery? And you get small deliveries frequently and validate the usability. 

2. Time and Budget Risk: Will it be delivered in the time frame and budget that was promised?

 

While there are other factors, the cost usually depends mostly on the number of people involved and on the length of the project. A fixed price is easy to achieve if you limit the time on the project but leave the scope open and definable in the project.

2. Scope Risk: Will I get everything I asked for?

 

Obviously, getting everything would have been the best solution, but if you had to choose between ‘things for next week’ and ‘things for tonight’, which is more important? Which alternative gives you better options?

Risk Handling in Agile

1. In Agile, you handle risks by limiting your commitment to a particular course of action to a relatively short period of time. During the timebox (PI/Sprint), you are committed. At the end of the timebox, you can change direction if necessary. (Budget Risk)
2. Fail gracefully. If you can’t do everything, deliver less but stay on-time and in-budget for the sprint/PI, and deliver features, with quality, that are most relevant for business. (Scope, Time and Quality Risk)
3. Time, budget, and scope are the classic measures of the success of a project. Is it on time and budget? Did it deliver all the features? Of these three, the scope is probably the least important.

Being on time with the most important features is usually better than being late with all the features

4. When buyers say “fixed-price project”, they usually mean fixed-time, fixed-scope and fixed-price. Surprisingly, they don’t often talk about fixed quality, which is unfortunate, because poor quality can have a huge impact on the total cost or even the success or failure of a software product. (Quality and Budget Risk)
5. From the perspective of the total cost of ownership, emphasizing the number of features delivered over the quality of features delivered is an expensive choice. (Delivery and Budget Risk)
6. A contract that focuses on delivering scope without a corresponding emphasis on technical excellence and internal quality could result in a product with high “technical debt” that is expensive to maintain. (Quality and Budget Risk)

 

BID (RFP/RFI/RFQ) And Estimations

1. The current approach to sourcing, based on Requests for Proposals (RFPs) or Requests for Quotes (RFQs), works well for complicated projects, like the runway project, but does not work well when uncertainty dominates before the project starts.
2. The reality is that all estimates are lies. To get the business, the client must pretend to know what they want, and the supplier must pretend to know how much time and money it will cost to deliver it.

If they don’t play the game, they can’t get the business. Their relationship starts with a lie.

3. Ultimately, estimates are just a guess, not a commitment. The reality will be different. Converting that guess into something robust enough to predict effort is a challenging problem
4. If the supplier has to make a fixed-price bid, they will probably take the upper limit (of their estimations) to cover their risk and/or may only commit to delivering a subset of the desired functionally. These are called buffers and are the supplier’s primary tools for mitigating time and budget risk.

Will supplier focus on technical excellence and internal quality in fixed price engagement (technical debts)?

What Agile Contract might look like

1. An agile team usually works from a goal and vision and a product backlog. The goal describes the desired impact of the product. The vision is a short description of what the product is (and often what it is not)
2. The product backlog is a feature-level description of the capabilities of the product. 
3. The “Sprint contract”/”PI Contract” or Managed investment can be referenced in the commercial contract. Generally, after a couple of releases, the commercial contract can reduce to a one-page Time & Materials agreement, maybe with a cost ceiling for the quarter or next major release.

From a contracting point of view, any contract that requires fixed scope is either non-agile or fake agile

4. The missing scope is relatively easy and inexpensive to fix. Just add another sprint, if it is worth the money. Or don’t, if it is not.

The best way to know you can release at the deadline is to have released two weeks before the deadline. And two weeks before that. And two weeks before that.

Which projects are right for Agile Contract?

Engineering type of project. How can you tell if your project fits into the category of engineering projects? Here are some tests: 

1. Do you still need to explore the customer needs? Are there significant open questions about what to build?
2. Do you still need to validate your solution hypothesis, potential market segment, value exchange model?
3. Have similar projects in the past failed because of user acceptance issues, change requests, or changing requirements? 
4. Do you feel a strong need for a change management process?

 

Final words

If the problem you are trying to solve requires an agile approach, the side-effects of applying a non-agile or fake agile approach will likely be a cumbersome and expensive “change request process” and a product that “misses its target market”

If the contract constrains the ability to implement improvements (review and retrospective), it will also limit “Team Performance” to a sub-optimal level and eventually impacts the motivation of the team and everyone else involved in the transformation initiative.

We (our needs, our society, our customers, technology, business dynamics, and the list goes on) are going through huge transformations where things are changing very fast. And the only way to survive and thrive is through “Continuous Customer Collaboration” (CCC)

I would love to hear your comments.

 

You may also be interested in this webinar recording where we explored agile contract.