How a PM can manage the contract aspects for Scrum projects with outcome-based pricing?

Question

Outcome-based pricing is becoming more popular in software development. And Scrum is applicable to such projects. How a PM can manage the contract aspects for such project types?

Answer 1

The best software solutions are built when the software vendor and the customer that ordered that software collaborate to make it happen. "Customer collaboration over contract negotiation" says the Agile Manifesto. Of course, the two parties involved in building the software (vendor and customer) need some legal agreement in place. They need a contract.

For Agile methods, the contract tends to focus more on the terms and conditions of the collaboration. For what I might call more traditional contracts, the focus tends to be more on deliverables (what should be delivered, when, at what cost, penalties or delay fees).

With traditional contracts, the customer tries to pass most of the risk on the vendor while the vendor tries to protect from that risk. So a negotiation tends to happen, while both parties try to screw each other up, or avoid being the ones screwed. Once the contract gets signed, the customer kind of exists the picture and waits for the software to be built for them. Projects like these tend to fix scope (by the customer needing to provide detailed specifications, fix schedule (from an estimate based on the requirements) and fix cost (resource capacity over the estimated schedule). The victim of all of this is often the software itself who turns out badly as it becomes secondary to schedule and cost.

With an Agile approach, since the contract should be more about the working relationship, both the customer and vendor share the risk. They are in it together. Scope, schedule and budget are not fixed. What's important is providing the best value first. The software tends to turn out better because the customer is involved, receives working software every iteration, and can always adjust course based on the feedback.

Now, outcome-based contracts make perfect sense from a business point of view because the focus is on getting successful results. They also look like a good fit for Agile projects, because Agile projects deliver "value". Outcomes and value are synonymous if you think about it. But outcome-based contracts also have some nasty ties with the traditional approach of building software. And that's because it puts most of the risk on the vendor, fixes the scope, the cost and the schedule, and to top it all of, it's a form of "money back guarantee" agreement that can hurt the vendor. It's a wolf in sheep's clothing. I'll explain in a bit why that is.

Outcome-based pricing is becoming more popular in software development.

IMHO that's not necessarily a good thing. My personal opinion is that Time & Materials contracts work better for software development. But that's the whole point with outcome-based pricing: customers don't want to pay for work, or programmers, or man hours (i.e. don't want to pay for time and materials). They want to pay just for outcomes. And if those outcomes are not met completely, they also want to pay less for them. If the vendor doesn't make the outcomes happen completely for the customer, why should the customer pay full price, right? So the vendor needs to protect themselves from this occurring. And it's back to traditional contract negotiations while doing so.

The problem with outcome-based pricing is in its name. It's the "outcome"s. Whose outcomes? Those of the customer of course. For all of this to work properly, the vendor needs to have control over influencing the outcomes of the customer. If they have full control over influencing outcomes, then the result may be a positive one. If they do not have full control, they are simply set up for failure. And the reason is that outcomes are in fact business goals. Sometimes they may be vague terms like increase our customer base by 25%, increase customer satisfaction, increase revenues by 50%, etc. And often times these involve much more that building software. They involve advertising, marketing, etc. If the vendor builds an application that can increase revenues by 50% but the customer doesn't promote the app, thus clients are not aware of it to use it, and the outcome of increasing revenues is not met, whose fault is it? Should the vendor be payed full price for their work or not?

If outcomes, and most importantly, how you measure and determine the outcomes are a success or not, if these are not properly defined, then the vendor carries all the risk, including the risk of not being payed in full for their work. So before any work starts, the vendor needs the customer to exactly define the outcomes and how the result is evaluated. That means having no surprises. The vendor can't risk having unknowns when they start with this project, so they want exact requirements or they want full collaboration form the customer all throughout the projects, in case something shows up. The second approach is desirable and is Agile, but because they are negotiating a contract and don't want to get screwed, they most likely will fall back on exact requirements. This now basically fixes the scope. The parties then agree on a cost that's fixed (with penalty fees if outcomes are not met), then fixing the schedule becomes just a matter of time.

OK, enough with the rant. Back to your question:

How a PM can manage the contract aspects for such project types?

You need to have outcomes and the way you measure them exactly defined and agreed upon by both parties. Then you need to make sure that you can influence the outcomes. If large part of making the outcome happen also depends on the customer, you need to make sure they are responsible for doing their part. And you need to formulate your contract towards shared risk and collaboration instead of deliverables, schedules and cost. How you do that exactly will depend on what kind of customer you are dealing with and how many lawyers they have. You need legal support, and you need it from someone that understands what outcome-based, fixed-price, and time&materials contracts mean.

A project manager might play a big role in this inside a small vendor company, as you say, but if they play it the wrong way, then a badly written contract can have you absorb a lot of loses, sink the project, and maybe even the company.

Answer 2

Outcome based pricing is popular for service contracts but seems less well suited to software development. As Bogdan suggested, many people will prefer T&M pricing and iterative delivery for development work because that usually gives the best balance of flexibility, collaborative relationship, price and risk.

If you want to make the contract outcome-based then I expect you would have to measure the output of each sprint somehow and base the pricing on that. However, that kind of arrangement would seem to tip the balance of risk to the contractor's disadvantage and they would presumably want to charge a higher price than they would for doing the same work in a T&M arrangement.

There is no PM role in Scrum and usually the Product Owner would be the person accountable for costs.