Fixed Price Contract

TomStambaugh inserted this brief definition to provide context for an exchange in PercentCompletedMyth.

A fixed-price contract obliges the supplier to deliver a defined work-product to a consumer at a predetermined price. Many such contracts include significant penalties for non-delivery. A fixed-price contract shifts most or all risks from the consumer to the supplier, and simultaneously shifts the management burden from the consumer to the supplier.

Generally, a fixed-price contract will be more expensive than its TimeAndMaterialContract counterpart (for the same project), at least at the outset. The difference in initial price represents the value assigned to the risk by both the supplier and the customer.

I'm coming to believe that letting fixed-price contracts (FPC) for development of new software is very tricky, if not inherently evil. Please help me explore when and how fixed-price development can be a good idea for the buyer.

The context is that the customer has a large problem, perhaps some existing software that needs replacement. There's a lot that "could" be done, and, as usual, no real sense of where the value lies among all this "could". The customer's upper management wishes to "minimize risk" by letting a FPC to develop what is needed.

Setting up such a FPC puts an inherent tension between developer and customer: developer wants to maximize profits; customer wants to maximize software developed. This leads to heavy-duty change control, increasing resistance to change, acrimony, dissatisfaction, finger-pointing; lawyers, warm heat death of the universe.

XP (though this is not an XP ad) sets up a surprising situation: customers and developers are on the same side of the table. Developers push to the release date by building customer-specified functionality. Customers push to the release date by selecting functionality that will get a successful product out by the release date. The planning/reporting process builds confidence in the customer that development is proceeding at pace that is generally reasonable and at least predictable. This helps and encourages the customer to make rational decisions to get useful functionality built within the allocated time and budget.

An XP project is built on the assumption that the project is about learning: learning how to build the software, and learning what software is really needed. The process is inherently dynamic:

What form of FPC relationship would have the same sort of dynamics? Could it And how could it do these things, and how could it do it without there being a built-in incentive for the contractor to put fewer and lower-price people on the project, and for the customer to jam more and more function into the increments?

Is fixed-price contracting inherently evil for such situations? Help me out, please. -- RonJeffries

A fixed-price contract is one form of a RiskSwap. Aye, cap'n, it is. And when I have one, how can I give it decent learning dynamics (for a project where learning is important)?

A fixed-price contract can be useful if it is done in a different way. A group of ExtremeProgrammers would set up a fixed-price contract like so:

You'll note that the above sounds remarkably like ExtremeProgramming within the context of a fixed budget. In fact, the contract writers should strive to create a contract in which both the developers and the company agree to take responsibility for their roles within the framework of an ExtremeProgrammingProject. -- MichaelDillon

The tension between developers and customers in a fixed-price contract is really the result of distance between customers and the people who hold the money. One approach would be to let the people who hold the money determine a cap, and let the customers negotiate price with the developers on a feature by feature basis. But, as I write, I notice that is really a mechanical approach and it has its problems as well.

There is no substitute for people skills, earnestness, disclosure and forthrightness. Customers have to trust you and have confidence in you and your estimates. If you can't establish that trust and goodwill, and keep it, things will be hard no matter what else is changed.

-- MichaelFeathers

For those of us who have seen the benefits of OO, there's a natural affinity to explore FPC. I actually started running into trouble doing time and materials - someone estimates a task will take six weeks, I'm done in seven days - and he gets mad and tells me to get lost for a couple of weeks!

Thought: "All or none". If you have a team, all should be on fixed bid, or none. I watched one company fail spectacularly with a fixed-price contract, and I suspect it's because they'd negotiated a fixed bid, but used employees who were on salary, who didn't have the experience nor the same motivations that people on fixed contract have.

In terms of dynamics between fixed-price contract and XP - XP is an effective stepping stone to developing those estimation skills and is probably the best method we have to mitigate the downside risk. And I would avoid fixed-price contracts using new technologies for which I have little real-world experience.

Conversely, there are potential upside benefits on the development side. If we base our price on value, we'd be rewarding ourselves for learning to be more efficient and flexible. IF we could work out the dynamics, I would think FPC would make the industry more efficient - there would be more motivation to build reusable frameworks, toolboxes, etc.

-- EileenSauer?

The first question to ask about a fixed-price contract: "Is it a fixed amount of work?" Very seldom is the answer truly "yes," in my experience.

-- BillTrost

In a fixed-price contract, the typical scenario is that an agency specifies the work to be done and the time period to complete the work. It then accepts bids for the cost to complete the work. Once your bid has been accepted, it is difficult, if not impossible to decrease the amount of work to accomplish, increase the time period, or increase the cost. To do so would result in lawsuits from the other bidders.

In a fixed-price contract, the developer assumes all risk for deviations from estimates. Fixed-price contracts usually result in much higher price tags than cost plus or time and material bids because the bidder needs to estimate the upper bounds of his development effort.

Fixed-priced contracting removes almost all negotiation options between developer and user, but is a reality often imposed by contracting offices.

-- WayneMack

Three variables: price, effort, deliverables. Price is set from estimated effort, and we've fixed this. Effort is defined by the developers, deliverables by the customer (in theory; in practice you'd better involve the developers too).

So, developers get unhappy if the effort changes (upwards, anyway :-). This can come from erroneous estimates (developer's risk) or changing requirements (customer's risk).

Fixed-price works either when deliverables don't change (Ron's "warm heat death of the universe", i.e. not good in practice) or if when work changes, effort doesn't, i.e. something else gives (MichaelDillon's ExtremeProgrammers example above). In either case the customer knows and agreed to what they got, and the developer makes their margin.

The first case doesn't require the customer to trust the developer's estimates, but restricts the ability of the customer to change the deliverables (i.e the developers must trust the customer on requirements).

The second case doesn't require the developer to trust the (stability of) customer's requirements, but restricts the developer's ability to change their estimates (no good coming back and saying it will take 6 more weeks when the customer hasn't changed anything) - the customer must trust the developer on estimates.

Unfortunately, both requirements and estimates will change in the real world. However, it's possible to build some slack into estimates (just double it, round it up to the next units, or whatever). I can't see how to build slack into (must have) requirements up front. That says to me that requirements will change but estimates don't have to (they can be padded).

However, that's the scenario where the customer must trust the developer's estimates. If you do, then why do you need a fixed-price contract?

So I'm with Ron, it's evil :-)

However, one legitimate reason for having a fixed-price contract is that it's fixed. In some company environments, getting signoff is a lot easier with a "guaranteed not to exceed" figure - even if that's larger than a time and materials contract would be.

-- PaulHudson

There are models which attempt to blend fixed- and t&m price structures; I've used one I call "Shared-Risk pricing", the core elements of the software are developed for a fixed price, then the "rest" is done for time & materials. That way, the development firm takes the risk that they will have difficulty developing a working system, while the client takes the risk of scope creep. More details are here:

http://kylecordes.com/story-182-shared-risk.html

-- KyleCordes

Try looking at this from the other side. Someone needs to have some work done. He has a limited amount of money to spend. Is it unfair (or evil) for him to ask "Can you do this work for this amount of money within this time frame?" -- WayneMack

Is it unfair (or evil) for us to answer "We may be able to but we can't guarantee anything. What we can guarantee is that we will produce the most possible value that we can produce within that time frame." Paraphrasing Alistair, it's better to be uncertain and have a strategy of correction than to be certain and wrong. -- JasonYip

Yes, this is an unfair response in that it does not convey any information at all. At some point, a decision must be made on whether to pursue a course of action or not. Is there risk the answer may be wrong? Yes, but at least we have determined if the project is likely to succeed within the planned time frame and budget. Software development is no different from any other aspect of business; prediction is necessary. -- WayneMack

The response is not that unfair when you consider that the amount of work in "this work" usually increases after you gave the answer, while "this amount of money" and "this time frame" remains unchanged. -- OliverChung

You need to plan for variation when you give the quote. In a fixed-price contract, the customer takes the risk he will have to pay more than necessary should the work go smoothly, while the provider takes the risk he will provide free service if the work proves much more difficult than he expected. This is why fixed-price contracts are more expensive than cost plus contracts.

Would you expect to buy anything else on a "it will cost what it costs and will be done when it is done" manner? Don't you expect to get a quoted price before remodeling your house? Some other US based examples: internet service has gone from pay as you go to flat fee, phone service is switching from per minute rates to block rates. Software needs to get beyond the notion that development is completely unpredictable and provide the level of estimates we expect from car mechanics and pizza deliverymen. -- WayneMack

The aspect that makes software development uncertain is that it's very hard (and rarely cost-effective) to provide all the information required. An analogy in many cases is building a house, when you're not sure how many bedrooms you want, how many stories it's allowed to be, and you haven't got any idea of how big a block of land you're going to build it on. Fixed-price contracts are fairly easy to estimate when the customer doesn't have the right to change their mind about anything, or the right to correct an interpretation of their requirements. -- RobertWatkins.

Most office buildings are built without knowing how many rooms are required. Later, the rooms are built to suit a tenant as needed. Adding rooms to houses is a fairly common improvement. Adding stories is less common, but still done. Software is not that different. We don't know up front everything that will eventually be in the software or even in the initial release. That is very different from saying we know absolutely nothing and cannot make any reasonable forecasts. I know of no project that is started without some type of estimate about when something will be accomplished, how much it will cost, and how many people and resources are needed. The type contract is merely a way of deciding who will accept the risk for over estimates and who will accept the risk for under estimates. -- WayneMack

Has anyone tried to correlate FPC's with OrdersOfIgnorance and FourLevelsOfCompetence? It seems like you could target a particular type of contract based on what you don't know and what you know you don't know.

A recent CACM issue had a correlation between OrdersOfIgnorance and process. I think the gist of it was to use light-weight processes when you have a higher order of ignorance (high risk), and a heavy-weight process when you have a lower order of ignorance (lower risk). -- EricRunquist

Shouldn't it be the other way around?

-- anonymous

I believe their point was projects where you don't know the technology, the scope, or some other fundamental facet, require the ability to dynamically change direction. Agile processes like XP allow this, while Waterfall-type heavy processes do not. The heavy processes put emphasis on a lot of up-front analysis, design, etc. before you ever write a line of code. That builds inertia by creating lots of documents before you really know where you are going. This presupposes that the best way to decrease your ignorance on a project is to focus on making something that works, even if it doesn't work very fast, isn't very robust, etc. The sooner you get something working, the sooner you can give the users a chance to find out whether you are going in the right direction.

-- EricRunquist

But what happens when you take other factors in account, such as requirements volatility, program size, criticality, innovation, schedule, cost, development team size, number of involved organizations, development team characteristics and experience, geographic dispersion, laws, standards, cultural differences, other projects, application domain, system complexity etc.?

-- anonymous

That's a lot to digest... too much in fact.

Many of my clients are non-tech-savvy clients (my last was a cosmetics company), and they seem to like FixedPriceContract because it means they don't have to think too much about what's actually being done. There's a simultaneous disdain for and resentment of the work, and if you start explaining too much they might roll their eyes and fall asleep ...

TimeAndMaterialContracts seem ideal, but they also seem to demand a client who's familiar enough with technology to trust you. My clients can't really trust me since they have absolutely no inkling of what it is I'm doing or whether I'm ripping them off. (The dot-com boom seems to have created a lot of these clients, and quite a few of them are still around.) So as much as I'd like to work on TimeAndMaterials?, I'm not sure how to get there.

Unfortunately, a TimeAndMaterialContract places the burden of project management - what shall be done and not done next - on the consumer. Risk is transferred from the supplier to the consumer, and the supplier can therefore reduce the initial proposed cost (since any unexpected overruns will be paid for by the consumer at the agreed hourly rate). Even if you were to succeed at negotiating a TimeAndMaterialContract with one of those clients, I suspect you would quickly discover that their "simultaneous disdain for and resentment of the work" will quickly lead them to make disastrously uninformed and naive decisions about the project. I strongly suspect that the approach you sketch in the following paragraph is about as good as can be done give the current state of the art. -- TomStambaugh

But certainly, that burden is there no matter what form the contract takes, no? Only the client can know for certain what he would like to pay for. The contractor can offer choices and ramifications, but it's the client's responsibility to make those choices. Because those choices will get made, and you'd rather the client do it than the programmer.

Oh my friend, you are describing reasonable choices that the client should of course make. Those aren't the "disastrous" decisions I mean. I mean decisions like "You must use VisualC++ because that's what our IT department specifies for all software". Like "You must use this P200 running Win95 because that's what all our contractors use and all company software must be done on company-supplied hardware". Like "You can't use Linux or UNIX for the server because we use only Microsoft technology". That sort of thing. You're absolutely correct, of course, that the risk can't be avoided. Perhaps the myth is not so much the PercentCompletedMyth but instead the good-software-cheap lies that segments of our industry have been selling cosmetic companies for years now. The part that requires courage is the part where we stand up and say "This is risky and might be expensive however we do it". Unfortunately, we live in a culture where consumers prefer to do business with suppliers who lie to them (with fancy webpages full of smiling properly-diverse happy faces) instead of with suppliers who tell the truth (that almost any new software takes at least six months to get right and costs at least tens of thousands to finish). I mean customers who say "Good software has to be documented and so I want javadoc for every class, method and variable of your code, and no there is no more time in the schedule and no there is not money in the budget for tech writers and no there is not money for more developers and no I will not authorize payment until it works.

My solution has been, instead, to only make estimates for very small chunks of work -- about 2 months at a time max. Sometimes my estimates are still off and I end up making a lot less per hour than I'd like; but at least this way I'm minimizing risk per iteration, and hopefully my next estimate will be more sensible. -- francis

With a FixedPriceContract, the customer usually has an irresistible (and perfectly understandable) urge to attempt to "get the most for his money" by deliberately instigating ScopeCreep. Shrewd customers will not present this as adding features but rather as "clarifying" the hidden meanings that "should have been obvious" in the original spec. If developers protest too much, the customer can escalate to hardball tactics of intimidation, nonpayment, and threats of lawsuits. When a small developer goes up against a big customer in this situation, the developer will usually cave in and double the scope of the project for the same fee.

-- anonymous

Another problem is that when you have less-tech-savvy customers they see technology as an all-or-nothing proposition: Either the whole dang thing works or it's all worthless. Most programmers understand that features can be added piecemeal as long as each individual feature is bug-free, so a piecemeal requirements process like the XP PlanningGame makes a lot of sense to them. Buy new features by keeping an eye on your cost-benefit analysis, and when the cost exceeds the benefit, stop buying.

But many clients don't think this way. They imagine that adding a new software feature is an arduous, difficult process -- perhaps the software industry shares some of the blame in fostering this belief for short-term gain -- so they feel much less secure if they can't buy software from you in large, difficult-to-digest chunks. And maybe software requisition looks more impressive to your higher-ups if it's accomplished in huge, impressive iterations?

See:FixedPriceContractsWithChangeControl

CategoryDiscussion CategoryBusiness

EditText of this page (last edited November 16, 2014) or FindPage with title or text search