Fixed Price Agile Contracts

Join Murray Robinson and Shane Gibson in a discussion why projects with fixed price, fixed scope contracts often go way over time and budget. We talk about uncertainty, sales incentives and underestimating. How fixed scope contracts lead to big design up front, siloed delivery, authoritarian management and conflict with suppliers. We discuss how to use an agile approach to solve these problems. We talk about testing suppliers by starting small and scaling up. And we talk about agile contracts where you engage a supplier to provide a fixed team for a fixed time and budget to achieve a goal with a variable scope

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. 

I’m Shane gibson. 

Murray: And I’m Murray Robinson. 

Shane: Murray how are we today?

Good, thanks.

I think we’re gonna talk today about, fixed price, fixed scope contracts, And how they’re complete bullshit . 

Murray: Yeah. And how bad they are for clients. 

Shane: So where should we start? 

Should we start with you giving us a bit of a definition of what you mean by fixed time fixed scope.

Murray: So it’s very common for clients to put out requests for proposal and request for tender to build software. Government pretty much does that for all of their work. So they do a big upfront piece of work requirements and architecture and design, which takes a long time, costs a lot of money, and then they create a request for tender or proposal, and they get a bunch of people to compete to win the work. And then when somebody’s won it, they, agree to deliver a fixed scope for a fixed price defined in all of those big documents. Time usually isn’t fixed. So it’s a legal contract usually after a bidding process. 

Shane: Yeah, so what they’re asking for is certainty. They’re saying we want certainty of cost and they believe by doing some work up front. What I call the , big guess upfront but some people call requirements, by writing all those down, they have certainty of what they need and therefore they can get certainty of cost. 

And in my experience, we all know that actually nothing’s certain. So you can have a guess, you can write it down, but as soon as you start building it out or delivering it, all the surprises come out of the woodwork everything becomes uncertain.

Murray: I agree with you. 

I think a large part of the reason they do it is because they don’t trust their development partners. They’re worried that they’re going to rip them off . So they try and make the scope fixed. They think it’s gonna be the way to get best value for money . 

Shane: I can see how senior people would be nervous going to sign off on a solution without understanding what it might cost. One of the behaviors I see is, they go out to tender, they put their requirements into the tender. They get back a bunch of guesses on the cost. They talk to the vendor and find the one they like. They may or may not pick the cheapest price. 

So they all signed the lovely paperwork. The vendor comes in, they run a couple of initial discovery workshops. 

They then say, oh, well actually what you wrote down isn’t the actual scope of what you need, and let’s start the change request process.

Murray: Yes, the change request process which is always very painful, and usually they will charge you for the change request process itself. And to be fair, you’ve got business analysts and project managers who have to do work to understand the change. 

Shane: So workers need to be done, but then why shouldn’t the vendor get paid for that work? 

Murray: Then they tell you that this change you want. It’s going to cost a surprisingly large amount of money. That’s nearly always the way it works. And there’s a few reasons for that. So by the time you go through the project, you will have discovered, in my experience that 30% to 50% of your requirements, architecture and design will have changed by the end.

So there’s a huge number of change requests on these sorts of projects and how many there are, depends on how tough your service provider or partner is. Usually the big ones the tier one companies will raise change requests at a drop of a hat. The smaller ones will try and accommodate changes where they can. It really depends on how much financial stress they’re under as a supplier. 

So the big problem is that there are major tier one service providers who go into these contracts underbidding, knowing that they can make up their loss and make a profit on the change request.

And in addition to that, there’s a lot of people who don’t know that they’re underbidding, but they are because there’s just so much uncertainty about how much things cost. So once they get into it, they discover that they have to charge a lot for change requests to make money. 

Shane: Yeah, I’ve seen that. I’ve also seen the other side of the coin where. 

The requirements require interpretation. They’re written words. The context of those words is often more important than the words themselves. 

The vendors make some assumptions around those requirements about what needs to be done and what doesn’t need to be done, and that ends up differing to what the customer originally had in mind, and that’s where disconnect is.

So in that case, a change request is valid because, the work they expect to do is more than what they thought it was. So I’ve seen both sides, and it just comes back to the idea of writing some words down, giving it to a whole lot of vendors, expecting them to give you a price back that has any relativity, to the work needed being done. Is just bullshit. 

Murray: It’s in the interests of the service provider to assume that every requirement is as simple as possible and to write that into their assumptions in their proposal. And it’s in the interests of the client to assume that every requirement is as complicated as possible. Because if it’s a fixed price for a fixed scope and you can make the requirement complicated, then you are getting more work for the same amount of money. Whereas if you can do less work, you’re better off as a supplier. And I’ve seen clients take that attitude if we’re paying for it anyway so let’s gold plate this requirement, 

Shane: And then the other thing that you have to do as a vendor if you’re doing that bidding process, is you have to bring in some fat. You put a percentage on for the risk margin and that’s normally hidden. You hide that margin from all those estimates from the customer and they dunno whether vendor A put 50% on and vendor PS put a hundred they don’t actually know those core assumptions. 

Murray: And there’s a good reason for that, Shane. I once did a more open tender for a, large car company where our team said we think it’s gonna cost between A and B. The difference is contingency cuz it could cost the higher amount or it could cost a low amount.

When, they told us we’d won the work, they said, you have to take out the contingency budget, we’re not giving it to you. And then when we were doing the work, we needed it. And they said now, you’re going over budget. 

And even if you are doing an internal project it’s, very common for some senior manager to promise something to some stakeholders for a certain amount of budget, and then for you as a project manager to find that it’s been seriously underestimated and it’s not possible to do. 

Shane: Humans are crap and estimating. So it’s always seriously underestimated. I had an experiment once where I said to a customer, so running a consulting business got asked for how much and all that kind of stuff. And so the conversation went well, what we’ll do is we will guess the worst case scenario dollars wise, and then as we deliver the project, you effectively set the acceptance criteria of what good looks like for us to pass the test, to push the prod for your features. And at the end of the day, the difference between what was spent and that worst case scenario, budget will go halves. So you save half of it and we get half of it. They didn’t take it. And I also wondered if that would’ve given us an incentive to cheat on some of the features. To low ball what we delivered to get it good enough to get across the line, but not great, but a technical debt cause it’s always hidden. So bad behavior may have come in. But , that was a interesting idea I had for more of an agile contract. 

Murray: Before we go into agile contracts and the solution I just wanna say that fixed price, fixed scope competitive bidding actually drives a lot of very, bad behavior . So the first thing is that there’s a very strong incentive for the sales partners in your service provider organization to low ball. 

And that’s because if they talk to delivery people at all, delivery people are gonna give them a range cuz of uncertainty, And the bid that the sales people put in is gonna be at the bottom of the range because they know that clients are always preferring the lower price. They also know that all of the other salespeople think that, so all of the sales partners are low bidding to win, and so they forced into it otherwise they’re not gonna win anything. And , there’s often a view amongst salespeople in these sort of situations that, oh, the delivery people can work it out. Because salespeople only measured on revenue. And frequently they don’t even talk to the delivery people at all.

I was working for a digital agency that was losing money on all of its projects cuz the sales people were estimating everything at half the real cost. 

Shane: Yeah, I’ve seen it. In the startup world, when I’m talking to founders of startups that are , starting their journey. I’ll often say to them, at some stage, you are gonna think that you’re not the right person to be selling to your customer. You’re wrong. But you’ll think that. Second thing is you think you need to bring on an experience sales professional to start driving that business in for you, and you’re gonna compensate that person on the amount of sales they make. And you shouldn’t. You should compensate them on the successful delivery to the customer in terms of customer happiness and in terms of profitability, because otherwise, they’re gonna go sell it for whatever they can get for it, and then you’re gonna spend more money delivering it than what you got.

You’re gonna make a loss and it’s gonna kill your startup. So seeing that time and time again, what’s the sales people compensated on? They’re compensated on revenue, on sales made.

Murray: Yeah. 

let’s say it’s done in good faith and they’re not deliberately low balling. They’re just trying to put in the lowest price they think is realistic. But then what happens is that it gets handed over to a delivery team with a delivery project manager measured on profitability, and if they make a loss, there’s a very good chance that they’ll get fired. Project managers get fired a lot. What happens is they’ll start off wanting to have a good relationship and being nice about the requirements And as they’re going through they’ll start to realize this whole thing has been drastically underestimated and we are going to lose a lot of money and I could get fired.

So they start being extremely controlling because they want to charge the client a lot for changes. They start telling all of the bas and the designers and the architects, we’ve gotta get very strict about changes. Don’t commit to anything in meetings. Come back, we’ve gotta review it all to raise change requests. And they set up a change request factory. Somebody will say, it could be one day to 10 days work and they’ll say, all right, we’ll make it 30 days work. A major insurance company I know got a quote from a tier one consulting company to do a piece of work for 30 days, and it turned out that one of their own staff was able to do it in two hours. 

Shane: Question I’d have is what did the velocity of that vendor working with that customer look like in the past. Yeah. It’s two hours if you’re internal, but if you’re external As a vendor, you’ve got all these gates to go through. You can’t get access to the right people in the right time. So you’re burning people on the bench sitting there charging, but not delivering because of the customer. So maybe that’s where it comes from, but that idea of I can walk into a meeting as a part of the delivery team and I have no power to make any decisions. All I can do is write something down and hand it off to somebody else that’s in another process to come back with a guess of the number before I can actually deliver that value. How un Agile is that?

Murray: It’s extremely un agile and everything that’s written down in the beginning there’s a wide range of interpretations possible for it when you come into it. But if you’re in these unprofitable contracts that you’ve got into it’s better to build the wrong thing that because it was written down and you are contractually required to do it, even if you know it’s wrong, and then build it again, but do it profitably. That’s much better for the supplier. It’s bad for the client though.

Shane: When you force the partner you are working with to do some work that becomes unprofitable they’re not gonna go under. So you are gonna get something that has massive hidden technical debt. It’s one way they can save it.

Murray: Yeah. By delivering crap. 

Shane: Yeah. Or you are not gonna get the features you need, to be successful because they have to reduce the work done.

Murray: I agree that’s exactly what happens. They’ll start off positively, cuz they don’t usually know that it’s gonna be unprofitable and then they start getting super strict. The decision making power gets taken away from the people interacting with the customer except for the project manager. The estimates for change requests get ramped up dramatically. The project manager starts giving people a lot less time to do things, so they start delivering crap. I know one project with a major indian company where they delivered code modules into tests that were just copies of other code modules from other areas. They just didn’t do anything like what was expected. I found out later on that their managers were telling them just to deliver something because after it failed in test, they could fix it then like they’d have extra time then. 

Shane: Yes I’ve seen that behavior as well where, the relationship between the vendor delivery team and the customer was so bad that the milestones were now the important things and the milestones were so poorly worded. The acceptance criteria was woeful. And so yeah, it was deliver something and then treat everything else as a bug.

Murray: So what I’m saying is that these fixed scope, fixed price contracts force the client and the supplier in different directions. 

They, instead of having a common interest to, to deliver something of value, the supplier becomes completely focused on making money and the client, ends up fighting with them the whole time. And it’s just leads to a whole lot of very negative behaviors, which are very common in waterfall projects.

Shane: Yeah. And that’s where there’s a whole lot of uncertainty, 

Murray: Well, I would say every software project has quite a bit of uncertainty.

Shane: So I’ll give an example of where fixed price does work, but there’s consequences. So , previous life we had identified a piece of enterprise software that was relatively hard to manage and maintain. Customers were spending quite a bit of time upskilling their staff to maintain this stuff or hiring vendors to come in and maintain it for them. And it was quite an expensive space. We found a way to reduce the uncertainty of managing that software. There was quite a bit of work upfront for us to go in and deploy our automation cuz every customer’s site was different but there was enough standardization because of the enterprise software vendor that we could go and deploy some of our automation techniques. It would take us couple of months to get the platform healthy, for all the problems to disappear. And then we just charge them a fixed monthly fee for maintaining that platform in a healthy state. Now what’s interesting, is after a while the customer worked out that we weren’t actually spending a lot of time looking after the platform anymore because we’d automated it.

And so they started saying , we don’t think it’s right we pay you that fixed monthly fee because you’re not actually putting the hours in. And then they wanted to reduce the bill. And so for me, that wasn’t right because we’d spent a lot of time investing into that automation. had a, fixed price that we all thought was fair at the time we solved their problem. And if our margin was higher because of it over time, then good on us. Or if there was an alternative in the market that was cheaper that did the same thing, go for it. So yeah, it comes back to that win-win, as if it’s fixed price and they happen to make a hundred percent margin on the work they’re doing, and you are getting what you asked for in a good way, and that’s okay.

Murray: Yeah, I think so. The other thing you mentioned was changing suppliers midstream. So generally, once you’re in the middle of a development contract with a supplier it’s impossible to get a second price on changes, cuz nobody else knows what’s going on and they couldn’t come in and do it cause the first supplier would refuse to cooperate with them.

So what happens is that these fixed scope projects, tend to go way over time and way over budget. And they’re not delivering much. And at some point the client says we’ve lost faith in you. But then what happens is they have to go through the whole process again. And so that might take six to 12 months . And the new supplier comes in and they say, oh, everything the previous supplier did was shit and we’ve got a different solution. And so they have to start again. They won’t use what’s been done, they’ll just delete it. And that can happen three times. The first consulting company, they get fired after you’ve spent most of your money. Then the next big consultancy comes in and they delete all the old code, start again.

After a long time, you find they’re behaving exactly the same as the first one. So there are plenty of big projects that have been done three times. 

Shane: There’s also some examples on your side of the Tasman where they carry on with , the first one, right? And end up with hundreds of millions or billions of dollars. And the platform never works especially in government, because then it becomes visible. 

Murray: The Australian Census done by ibm couldn’t handle the load that was on it. So as soon as people started to use it it all fell over. IBM said it wasn’t their fault because there was another service provider that the government had commissioned to do the platform and it was their fault. And then there was another one that was supposed to do all the performance testing, so it was their fault. So they all just pointed fingers at each other. 

Shane: Yeah, which actually gets us to the idea of a systems integrator, a consortium, one throat to choke. 

Murray: IBM were the systems integrator in this case. 

Shane: But we double down on the stupidity of fixed price upfront where we say, okay, so you are the systems integrator. You take the risk for all the fixed prices, and then you get a bunch of other vendors to fix price parts of the solution to you. But we’re gonna hold you accountable for their fixed price and your fixed price. 

Murray: What happens is that the client wants to contract with all of the other parties separately because it’s cheaper, it takes the margin off the system’s integrator. But then the system’s integrator says we can’t be held responsible for that because they contracted with you, not with us. We are only a coordinator.

Even if they do take responsibility for all the subcontractors, and pay them themselves, they’ll say that we were blocked by your internal infrastructure department, which is often the case. It’s a difficult being a provider because the client often stuffs it up themselves.

Shane: I agree. 

So apart from me saying the idea of fixed pricing, uncertainty early is bullshit and you should never do it. Have you seen Any agile techniques or practices that give us a little bit of hope? 

Murray: Yes. There’s a couple of solutions. 

The first one is to build some trust with the supplier before you engage them to do something big. It’s amazing how many companies will give a 10 million project to one of the big consulting companies with never having worked with them before. What you should do is do something small with a supplier to establish trust and to see that you can work together and to understand how they work and they can understand how you work. So start small and, multiply up. Do a hundred thousand dollars piece of work, then a million dollar piece of work, then a $10 million piece of work. 

Shane: So, that’s exactly like the conversation we had around scaling, don’t go and try and start off with a hundred squads and scale your delivery out on day one. Start with something small, prove it’s working and you’re happy. Then deal with the scaling problem. So same pattern, start with a small piece of work, figure out how you’re gonna work together. Then figure out how you can scale to do bigger pieces of work 

Murray: Yeah. The second thing is if you’re going to do fixed price fixed scape, keep it really short, like one month or two months. Suppliers are pretty good at estimating for one month of work and reasonable for two months. After that, it becomes quite difficult. So I would say if you’re gonna do fixed Price, fixed scope. Do really short ones. And then once you’ve got to know your supplier a bit, move away from fixed scope all together. Move to fixed price, fixed time for a fixed team to deliver on a goal with variable scope.

Shane: So I’m gonna disagree with you on that one. Teams who start out are crap at estimating even a month. So I think what we should do is we should work with the supplier on a small piece of work and we should fix price it, and it should be fixed price because we are saying there’s gonna be four of your team and four of our team, and we’re gonna work together for a month. 

Murray: Is it fixed scope as well? Shane 

Shane: No. Cause that’s when it hits us. So it’s just fixed price. Four of your people, four of our people, for a month. They’re gonna build some staff. We’ve got some vision, but we have no idea what we’re actually gonna deliver, because we haven’t worked together. As a result of that, the team will know how to work together a bit more. We’ll get better at estimating. When we actually get good at it, then we can start fixing scope because we know the team have velocity. They have practices which are repeatable. So some of that uncertainty’s been disappearing. And then the only thing left, which is uncertain is what’s gonna be delivered

Murray: How are you fixing scope? Are you fixing it by velocity? 

Shane: So I think a repeatable velocity gives us more certainty on what we could deliver in the time we have. Working together and building stuff out gives us better estimates because we are having better conversations. So I think we can get to more of a fixed scope when we have maturity amongst the vendors team, with our team.

Murray: Yeah, they do get better at estimating, but fixed scope means that we commit to delivering all of these features of the product in this time period to a level that’s acceptable to the customer. And even when the team’s been working together quite a long time, that’s still got a lot of uncertainty and variability . If you haven’t done those features before there’s still quite a lot of exploration. There’s just a few words about what the feature is and it’s hard to know what that actually means. And if you’re doing fixed price, fixed scope. It brings back the incentive for the client to say, you agreed to do this. So now I’m gonna put all the bells and whistles on this that I thought it would have because you’ve already agreed a price for it. 

Shane: Yeah. 

And we do it into our internal teams as well as our vendors, so bad human behavior. 

Murray: I agree it does happen to internal teams. So what I like to do is to say to clients, we’ll charge you a fixed price for, two weeks or four weeks of scoping and planning and then out of that, we’ll have a release plan, and then from there on we’re going to do fixed price for a fixed team, but the scope won’t be fixed. In other words, we’re gonna take the roadmap and the design concepts and everything and we’ll start working through them.

But we all agree that every two weeks we’re going to be changing our priorities and some things will get bigger, some things will get smaller, things will get added in, things will get taken out. What will happen though is that we will always be showing you things and we’ll always be working together to work out what to do, and then there’s a strong incentive for both parties to align around the best value for the client because, the project is gonna end on a certain time. And so the client has to try and get, not the most work, but the highest value work out of the team. The team knows it’s going to end there’s a certain number of hours effectively. And so therefore, they want to provide the best value to the client. It’s not about somebody trying to get more hours or do less hours. The hours are there. You’ve effectively bought hours and team and You’re looking to get the best value out of it. So that brings everybody together in collaboration, I find. 

Shane: Yeah. so what we’re saying is feel free to fix price it, but never fix scope it. But over time, as you work together, you can get more certainty about the scope that might be delivered with that time. We gotta remember that our stakeholders are saying, I’m really uncomfortable with this open checkbook. You can’t tell me how long, how much? And that makes me feel nervous.

Murray: The approach I’m talking about Is not open checkbook, because it’s a fixed time, fixed price for a fixed team. 

Shane: Yes. But if they’re building a product, the product has to get to a certain level before it provides that value back to the organization. 

Murray: I agree. In your initial planning, which should never take more than a month, you work out, the right ballpark for what they’re talking about. And there’ll be some combination of what they are prepared to spend as a client, what they can afford, and what they want. So you end up agreeing on an amount and you end up saying, we think we can do at least two thirds of these things in this release plan. So that should give us enough confidence to go ahead with it. But we all agree that what comes out at the end could be different to this plan. 

Shane: As it should be. The business changes sometimes while we’re building these things. So if I bring it back to that procurement process, we can still provide a light list of requirements or scope things in our rfp. Here’s some choices we’ve made of what we think is important. And the vendors can still come back with a guesstimate price of what it might take to deliver that. But what we should do is tell them, That we’re not focusing so much on the number, we’re focusing on the workings. Don’t just give us the answer. Show us how you got there, because that’s going to let us know how you estimate. And that’s one way of comparing vendors. 

Murray: Yeah, tenders are not a good way to pick the best vendor though because you don’t really have much exposure to them. You put out a document, you have a meeting with a bunch of vendors, and then they present. It’s actually a very bad way to get to know your suppliers, you’ll ask them a thousand questions and the sales people will go through and agree with you on everyone cuz they know that they have to get the sale, whether it’s true or not. 

Shane: Actually having been a pre-sales or sales engineer in a previous life, It’s a bit like the pricing thing. You never wanna be the highest, you never wanna be the lowest.

Murray: I have been in pre-sales too, so you end up saying yes, but yes, we can absolutely do everything you say, but. 

Shane: Yeah. Yeah. Or and then you look at it and you go, oh, we’ve said yes a bit too much. Let’s find the ones that actually we’ll probably know anyway. And we’ll just make those nos. So we have a 95% yes, Fit. Cause a hundred percent looks dodgy. 

Murray: Clients always say you have to have at least 85% fit or it’s not worth it. 

Shane: Yeah.

Murray: So I think Small pieces of work to get to know suppliers and then have your suppliers on a gradation. This one proved themselves to be good on a hundred thousand dollars piece of work. So that’s a precondition for them to be able to bid for this other million dollar piece of work. I would qualify suppliers over time. So I really strongly recommend that people do not go and hire one of the giant service providers for a great big piece of work straight away. Cause you’re gonna have a bad experience. 

Shane: Yeah. I like that idea that then having a startup myself, I hate it because that means actually getting the ability to come into these companies that have already got preferred partners makes it really hard. But I think that. Key point you made just then, which was nobody should ever kick off a billion dollar project because it’s just too big. 

Murray: It’s extremely risky. 

Shane: We should never start with a hundred squads of 10 people because it’s just too big. So start small, figure out what works, inspect, adapt, change. Get better at it. 

Murray: Yeah, and then what you can do is you can have two or three suppliers that you know that you are working well with, that you can trust, and then you can work out what you wanna do. You can get them into a room. Even together, there’s something called agile procurement. which There’s this guy in from Netherlands, I think, who advocates it but basically he says pick your three suppliers that you like and you worked with before, and bring them into a room together and spend two days with all of them at the same time doing an estimate. Open estimates where every supplier sees what the other supplier estimates, and they all see what the assumptions are. So one supplier can say that assumption’s wrong. Yeah, that might produce a low price, but we didn’t assume that because of this. It’s a very interesting open book bidding. 

Shane: I like it. There’s a whole lot of commercial problems of it potentially, but if your suppliers wanna work with you going forward, it’s exactly the same as never have a business team estimate on their own for delivering something that involves technology. Always have somebody that has the technology skills or , if you’re running a siloed hierarchal organization, have somebody out of the technology side of the business come in as well, because everybody’s view has value and working together you remove so many barriers, you get a better estimate. So I think for me, in summary, I thought I was gonna say never fix price, never fix scope, because it’s just bullshit. I’m actually gonna change my mind. I’m gonna say fixed pricing’s fine, but it’s the fixed scoping that’s the problem. So never fix scope.

Murray: Fixed scoping is very bad for you as a client, even though it feels better at the front. And it’s bad for the supplier. I think you could fix scope, small things. The risk Is pretty low there, but I’d only do that to get to know people really. 

Shane: I’d say start as you mean to go on. Don’t fix scope it Don’t waste your time. 

Murray: I’d prefer not to fix scope it, but fixed price for a fixed team for fixed time makes a lot of sense to me, and it also works very well in my experience.

Shane: Because it’s a agile mindset, it’s what a lot of the agile patterns and practices are based around , that very philosophy. 

Murray: Yeah. The agile values are collaboration over contracts, 

Shane: yeah.

Murray: That’s what we’ve been talking about. What else? Working software rather than documentation. So these fixed scope contract projects they’re all about deliverables and a lot of those deliverables are documents.

Individuals in interactions over processes and tools. If you’re in a difficult fixed scope contract, you gotta focus on processes to make money. You don’t want people to collaborate because you can’t make money that way.

Responding to change instead of following a plan. The thing is there’s always gonna be change. I think what’s happening, is that a lot of managers have this factory model ; which has as an underlying assumption that there’s very little uncertainty about anything. They use the same process for buying, 10,000 reams of paper as they do for buying, customized software development. It’s just completely wrong. The whole factory mindset is completely wrong. Cause it’s all about assuming that. Things have no change. You do step one, you do step two, step three. Everything’s the same all the time, and just software product development is not like that. It has far too much uncertainty, far too much change, and far too much learning

Shane: And it’s not just the customer. It’s also the vendors, so, take the large global E R P vendors. The bullshit they sell is it’s all out of the box. As long as you follow our best practice implementations, it’s all easy. And I have yet to see one of those implementations where there hasn’t been some sort of change required. So this nirvana of there’s no uncertainty when you’re deploying these out of the box. ERP systems is bullshit as well, 

Murray: Yeah. And I’ve been on the client side and seen this. Let’s say you buy, something from one of those big software product companies. What you bought is a toolkit like you bought like a Lego kit. A big box full of Lego that maybe you could do this, maybe you could do that. But there’s always a lot of customization and configuration. Like it’s very common for you to spend half your budget on customization cuz it turns out it doesn’t do what you were promised that it would do. 

Shane: And I don’t mind that we’re buying lego, because it’s better than buying a bunch of rein and having to make my own block put together. But we’re not buying a prebuilt transformer model. We’re not buying Buzzy Bee. And the problem is they’re selling us Buzzy bee. So again, where there is uncertainty, we just have to be clear there’s uncertainty. And , the agile way of working allows us to deal with that uncertainty in so many cool ways. It adds massive value. So we should just not pretend that there is no uncertainty. We should not allow fixed scopes because, we are lying to ourselves, we’re lying to our customers, and that’s why the problem happens. 

Murray: When I was discussing this on LinkedIn recently, some people really railed about it being unethical. So sometimes it’s deliberate and unethical and sometimes it’s just inadvertent. You just got yourself into a difficult spot. I think that happens a lot but I would say that the Agile way is far more honest and collaborative for everybody. 

Shane: Yeah, I suppose if I liken it, to a surgeon who’s going and do heart surgery they’re not gonna fix the time. They’re not gonna fix the scope because they’re walking into a massive uncertainty. 

Murray: Yeah. 

What I’d really like is for these contracts to focus on outcomes. Imagine if you contract a supplier to build you a marketing website because you want to generate inquiries and leads and You tell them the things you want and they say it’s gonna be X million dollars and you do it in an agile way. 

Really what you’re doing is you’re working, through a product roadmap and if you’re doing it properly then everything changes and the backlog changes. But wouldn’t it be better if the contract was all around, how many leads can you get? And I want you to show me at the end of the first month that you’ve generated some more leads. In the second month, more leads after that third month more leads. So every month you are showing that you are actually helping them achieve the business objective that they want to achieve rather than producing a bunch of features. That then gives a team a lot of flexibility to say, we could do this but this thing over here actually looks like it will be simple, an easy way of getting more leads. 

Shane: So it’s really interesting cuz then what happens is the psychology of fear of missing out happens. So that example I used about fixed monthly fee where we were delivering the outcome, but people then started worrying about the effort. Another example is when I was working for a large analytics vendor, they determined that they had a really good solution around fraud detection. And they had done enough of them with customers that they had taken out a lot of the uncertainty of what you needed to deliver a fraud solution. So they would often go into a large enterprise and say, we’ll deliver our fraud solution. We’ll benchmark the amount of fraud you have now. When we’re running our solution, we’ll benchmark over time the amount of fraud you get as you’re running it. And that drop in fraudulent transactions will take a percentage of it and you will not pay us any other money. But that percentage of drop in fraudulent transactions is an outcome or it delivered.

Murray: Did clients like it? 

Shane: Very few customers would pick it up. They then said, they somehow talked to themselves and said if you can do it, we can do it. So we’ll just pay you and then you’ll build it. And then we’ll run it and we’ll take all the money. And so that idea of a win-win, that idea of a shared outcome where you’re both successful for some reason didn’t happen. 

Murray: I’ve had this discussion. I haven’t got anyone to sign up for it but still, I think it would be better because you’ve got a bunch of really smart, creative people If you just say, build me this widget and this widget, you’re really limiting the value you’re getting from them. They might have a lot of good ideas about how to generate leads that your product people haven’t even thought of.

Shane: And it’s what we coach our teams to do, when we’re coaching them on an agile way of working. We’re saying as a team, work together. Listen to your product owner about what the outcome the organization’s looking for. Iterate with them on the things you can build to help them achieve that outcome and then work together to deliver it. It’s exactly how we want teams to behave. So why don’t we do that with our vendors. 

Murray: Yeah. All right. 

Shall we summarize? 

Shane: Yeah. So fixed price is okay. Fixed scope is bullshit. 

Murray: I agree with you. Fixed scope drives a massive wedge between you but fixed price, fixed team brings you together.

Shane: Yeah. So let’s make it happen.

Murray: Yeah. All right. Shane.

Shane: Catch you later.