Successful projects, part 2: Paying for Deliverables

Clients love fixed-price projects, because they have transferred the risk of the unknowns to the vendor. Even so, if the vendor cannot fully handle those risks, the entire project might fail. Healthcare.gov is a great example of this -- poorly defined, rushed out project with no prior on-the-ground working system to uncover what was unknown before starting.

As a vendor, even with what seems to some clients to be high rates, I do not have a big margin on the hourly rate. I'm not getting rich here. I have to pay people to do the work, pay the rent, pay for benefits, supplies, servers, etc. At the end of the day if we screw up I don't get to take home a paycheck. I cannot afford to do a fixed price project unless I can be absolutely certain I'm going to make at least the same amount as I would on a time and materials basis.

That means the plan needs to be rock-solid, the deliverables extremely clear, all of the unknowns thought through, the problems anticipated. And even then, something always comes up that you did not expect -- I need to add a large enough margin to cover anything that does not go according to plan.

That leads to its own set of questions:

• To do proper planning, we're talking about 10 - 15 hours for relatively trivial enhancements, and regularly 40 - 60 hours for moderately complex sites. Who pays for that careful planning?
• Planning can actually take longer than assembling the pieces to implement the plan, and as much as 40% of the entire project -- is the client willing to pay for that?
• The more time spent planning, the more unknowns become known and the lower the cost of implementing, or at least the more accurate the estimate. How much planning is enough?

This is really the challenge of responding to RFPs (Requests For Proposals, the main way government projects are solicited) -- in many cases the client won't pay even for the proposal, or the planning that goes into it.

What we do for larger projects is put around 10 hours into trying to get at the heart of what is being asked for, recommend a budget that is 4 times bigger than we think we'll actually need, and make delivering an actual plan the first milestone of the project. Given how much work we potentially give away without even knowing if we'll land the project, we only do this when we think the budget we're asking for is reasonable for this client and we have a good shot at landing the project. Even so, if the budget is under $50K, it's probably not worth our time to put together any kind of fixed price project -- the potential up-side is simply too low and the risk of making less than we would with time and materials (and thus put the entire business at risk) is too high.

Given all of that, we have added some fixed-price projects to our mix. We have a basic business site, a basic event site, a site review, and maintenance plans all available for fixed prices. What's different about those? Basically all the planning is done -- these are turn-key products with clearly defined deliverables, no unknowns, and all custom work is done on an hourly basis beyond that.

How Interests Collide: If you're not doing the screwing, you're getting screwed

The problem with fixed price projects on custom work is that somebody nearly always gets screwed, and the incentives are completely out of line. Once the scope has been agreed upon, the vendor has a huge incentive to do as little as possible to deliver that scope, and any changes made by the customer have to result in renegotiation.

Inexperienced vendors might agree to do a fixed-price project, and then get in way over their heads. I can't tell you how many projects we've rescued after a previous vendor working on a fixed price basis failed to deliver and walked away.

Experienced vendors understand the risks, and if they successfully do fixed-price projects, it's because the customer is getting screwed by paying a much higher cost than they would on a time and materials basis.

And there's always a strong incentive to do shoddy work in the short term to get the project out the door, because long-term maintainability is never part of the scope of work.

For me to be interested in doing fixed price work, there has to be a much bigger upside potential for profit over time and materials, and if that's not a huge margin, I need to very clearly understand exactly what my costs will be to come up with any kind of bid at all.

How vendors can succeed with fixed prices

1. Work with customers who are not cost-sensitive, and agree to a price that puts a big grin on your face.
2. Create standard products and provide specific options, so that it's no longer custom work but configuration of something entirely known.
3. Do extensive planning, break down the problem into extreme detail, identify all unknowns, factor in the client standards, hassle factor, existing code, and chance of time-consuming conflicts or time-pits, apply a factor for profit and the cost of planning projects not landed, and then manage the project with strict adherence to every little detail and charge for any changes whatsoever.

The only way to succeed with fixed-price, fixed-scope custom work on this basis is to take the worst possible case imaginable for the project to go, and add a margin for profit and all the unknowns. We won't do fixed price custom work without at least doubling our worst-case estimate -- and we're generally not happy about it until we're at 3x or 4x what we think it will take.

How customers can succeed with fixed prices

Really the only way fixed price makes sense is when you can avoid doing custom work.

If a vendor has invested a bunch of time into creating a standard configuration, or tools that get the job done in a far quicker way, fixed prices become far more viable. When you use a Software As A Service (SAAS) product, the vendor has amortized the development costs across a bunch of customers, which means your share of the development cost is a fraction of the overall development cost.

This is where fixed price makes sense.

If you're trying to do a one-off custom project with a fixed price, you're headed for trouble, especially if the developer has not already built a site exactly like what you're looking for. (Which is pretty much the definition of a custom project). The developer will either underbid, or overbid the project -- the chances of nailing the bid so that it works well for both parties is practically zero. If the vendor overbid, you're paying potentially a lot more than you would need to. If cost is not a driving factor, that's fine -- and for many government projects, this is the only way they can do business.

If the vendor underbid, you still have problems -- you end up with an unhappy vendor, and if they underbid enough, it could drive them out of business and lead to failure of the entire project. Even if it's not a severe enough underbid to drive them out of business, you're going to see lower overall quality -- the vendor will have to take shortcuts that might lead to harder to manage sites, inability to edit things you might take for granted, poor security, or worse.

What we do with our projects is a mix -- we have fixed-price maintenance contracts, and fixed-price standard packages -- but then all customization beyond the options we provide is done on a time and materials basis. We find that there's a huge amount of value in deploying a standard package, and the faster we can roll those out, the more opportunity we have for profit, while at the same time delivering great value to our customers. It's a win-win situation.

Custom work on a fixed-price basis is either win-lose, or lose-lose. Successful vendors don't lose, so that means if you're going to do a fixed price project with a successful vendor, you're going to lose, at least if you're trying to contain costs.