During two separate meetings with potential new accounts this week, milestone-based payments (sometimes also called fixed-bid payments) came up in conversation. One potential customer was interested in working this way; the other one had just been burned by it. These conversations reminded me of the reasons milestone-based payments are a bad idea when you’re building a custom software project.
The Right Circumstances
Milestone-based payments can work well under certain circumstances–typically for smaller projects (say, less than $25K) or when a service or solution is straightforward almost to the point of being commoditized. In such situations, there are no unknowns, the work to be done is very clear, and there is almost zero chance of running into anything unexpected.
A website for an independently-owned restaurant is a good example of a technology project that could safely be structured with milestone payments. The structure of such a website is very well-known: It probably has a homepage, some information about the restaurant and its cuisine, a menu, contact/location information, and maybe online ordering (handled by an existing software product).
The Wrong Circumstances
Custom software development, by nature, is the opposite of straightforward and commoditized. When you set out to build custom software, the scope isn’t well-defined (even with the most detailed of wireframes and requirements documents). It’s guaranteed that you will run into caveats, risks, and issues.
We tell our customers that on every custom software project, something will go wrong. Under such circumstances, milestone-based payments are a horrible idea. They cause stress, and somebody always loses.
Milestone-Based Payments Make Things Harder
Don’t believe me? Here’s why milestone-based payments aren’t right for custom software engagements:
1. Milestone-based payments make project estimates inaccurate.
It is nearly impossible to know everything about a software project before it begins. Therefore, in a relationship structured with milestone-based payments, the vendor is incentivized to buffer estimates in order to cover the risk of unknown requirements. However, they can’t buffer too much, or they risk being the most expensive estimate on the client’s desk. An estimate for a milestone-based project becomes less about true project cost, and more about the vendor’s ability to target the right number that the client is willing to pay. And that brings me to the next issue…
2. Milestone-based deals are a risk to vendor longevity.
With this type of deal, the vendor holds a lot of risk. In Agile project estimation, it’s generally observed that on some features, you win (come in under budget) and on others, you lose (go over budget due to unseen complexity), but it all evens out in the end. Vendors who agree to milestone-based deals are staking their company on this principle.
But what happens if a few projects in a row turn out to be more complex than you expected? Suddenly the company is behind schedule, but you still have to pay people. Do this too many times, and the company is losing money.
Because of this, companies who work in a milestone-based way are going to be less inclined to take on innovative projects (too much risk), so they fall behind and lose business. Or if they do take on innovative projects, they are at a very real risk of failure because the risk is all on the vendor, while the reward is all with the client.
This last case is exactly what happened to the potential Atomic client I mentioned earlier in the post—their vendor had politely requested that they take the half-finished project elsewhere because it overextended their capabilities. My colleague and I were puzzled about why a vendor would make this request, until we learned that it was a milestone-based engagement. Then it became clear to us that the vendor probably needs this relationship off their books—they underestimated the complexity of the project, and now it’s way over budget.
And this is related to the third issue I have with milestone-based payments:
3. Milestone-based payments cause misaligned incentives between client and vendor.
When relationships are governed by milestone-based payments, the vendor is incentivized to minimize the time spent on a project. The less time they spend on the project, the more money they make. The client, on the other hand, is incentivized to maximize the vendor’s time, or at least not to respect it, because there is no extra cost to them.
This misaligned incentive structure shows up in a variety of areas. It can affect quality of design and code, degrade quality of client experience, and make vendors resistant to changes in project scope, even small additional features or tweaks. That’s when it’s time to start negotiating the change orders. Everybody loves those (not!). Which leads me to my last big issue with milestone-based payments:
4. Milestone-based payments can create an adversarial relationship between vendors and clients.
When every feedback item has the potential to escalate to a change order, software teams spend less time collaborating with their customers and more time on the defensive against inflation in cost. The vendor will actively discourage changes and tweaks throughout the process, while the client may choose not to accept the milestone (and release payment) until the changes are made. The vendor will argue that a change order is necessary, along with an increase in cost. The client may grudgingly agree. The client spends more than they expected in the end (which is what the milestone-based payments were supposed to avoid, in the first place!). Talk about frustrating, for both parties.
A Different Way
In short, milestone-based payments are a bad idea for custom software. So, what’s the alternative?
At Atomic Object, we work with prospective clients to set a responsible budget by looking at the project from many different angles and walking clients through our thinking. Then, we work with clients during the project to control the software scope to meet their budget.
Throughout the project, we model different options for our clients and make recommendations based on our years of experience. Our goal is to help them make smart tradeoffs and invest their budget wisely. We call this a fixed-budget, scope-controlled approach, and it’s worked well for our custom software projects.