Written By: Lawrence Waugh, Founder at Calavista
I’ve a friend who’s a software architect for a large (Fortune-100ish) financial institution. If you ask him what his company’s priorities are when working on a software project, it’s simple. The number one priority is security. Scalability is a distant 2nd. Everything else is noise. If it’s going to cost $10 million to patch a potential vulnerability in their system, they spend it. If a scalability project will take 3 years, they go and do it. Money, time, and resources are just not their concern.
Must be nice. But it’s not the norm.
I’ve been with Calavista Software, delivering software projects to our customers, for nearly 2 decades. In that time, we’ve delivered well over a hundred projects for various companies. Beyond that, I’ve had conversations with hundreds more who’ve gone in other directions. I’ve come to develop a pretty clear picture of what’s at the forefront of a customer’s mind when they’re thinking about having a software project done for them. That’s pretty simple too. Generally, it’s
1) Price
2) Quality
3) Time to delivery
Each of these is worth a lengthy discussion, but in this post, I’m going to talk a little bit about price. Or pricing, anyway.
One of the first things that comes up in most prospect conversations is, “how do you price?” Generally in this business, there are 2 major pricing models: Fixed Fee and Time & Materials. The names are self-explanatory: with Fixed Fee, you agree upfront what you’re going to build and how much it will cost. There are acceptance criteria, warranties of workmanship, and service level agreements on how bugs will be addressed when they’re found. Since time to market is usually important, there may be penalties for late delivery. The idea is that you know what you’re going to get, when you’ll get it, and how much it will cost, so you can budget both time and money for it fairly easily. It’s a familiar and comfortable model, which everyone who’s ever paid someone to mow their lawn, or cut their hair, or build them a house, is familiar with.
Time and Materials is the opposite. With T&M, you pay for the effort, not for the results. If you have particularly unruly hair, maybe the haircut costs twice as much as the other guy’s. Or if it’s really hot, and the lawn care guy has to take more frequent breaks to avoid heatstroke, you pay for that extra time. If permitting is delayed, the house may cost another $10,000.
Given that, it might seem obvious that Fixed Fee is the way to go on a software project and a lot of customers come to Calavista looking for that. In general, we think that’s a huge mistake, and here’s why.
What’s Wrong With Fixed-Fee?
The advantages of Fixed-Fee are obvious. And if a builder can charge a flat fee to build your house, why shouldn’t a software company charge a flat fee to build your software?
In fact, at Calavista we often compare ourselves to a General Contractor building your house for you. Just as a General Contractor will bring together and manage the various skilled resources needed to build your house (such as carpenters, plumbers, electricians, stonemasons, and such), Calavista likewise provides and manages all of the skill resources required to build your software application (such as Software Architects, Development Directors, UI/UX Designers, Developers, Testers, DevOps Engineers, Requirements Managers, Business Analysts, and such).
So what’s the problem? The problem is, that unlike lawn care, or a haircut, software development projects change. A lot. Even building a house is generally a far more stable effort than building software. A house starts with a blueprint, which you’ve spent a lot of money on an architect to produce. The blueprints cover literally everything that will go into the house. Building materials, plumbing fixtures, where each light switch is, and how it’s wired. Very few software projects today start with that level of detail. Rather, most software projects today are developed using an Agile methodology¹, which embraces change. The truth is that even meticulously-planned software projects – which take months, or even years, to specify – will invariably change and evolve over the course of the development effort.
So, if a project is taken on as a Fixed-Fee project, that means that every time there’s a change to the original plan, the change needs to be evaluated, the scope needs to be adjusted, and the price for that adjustment needs to be agreed upon. On most software projects, this will mean innumerable delays, and inevitably, cost overruns relative to the original budget. In addition, it tends to put the customer and the software vendor into an antagonistic relationship. That is, the customer is always working to make sure that everything in the contract is delivered, on time and on budget – while the vendor is always motivated to make sure that they’re not adding anything at all that’s not in the plan, because finishing early saves them money, while finishing late is costly.
I usually summarize it to a prospect like this:
If you approach a builder who’s built houses in your neighborhood for the past 20 years, and say, “I’ve got a half-acre – I’d like a simple ranch home, maybe 3,500 square feet, a patio, and a standard pool out back…” – they will probably be able to give you a rough estimate on the spot. If you sit down and flesh it out a bit more, they can refine to something quite accurate. Because they’ve built a dozen of those houses in your neighborhood. They know the problems they’re likely to run into and how to get around them. So, their estimate will probably be pretty much on target.
If it turns out that you forgot to mention that you wanted marble floors throughout, they can still help you meet your budget. “OK, if those are important, we can do that – but we may need to lose the crystal chandeliers or maybe the hot tub. Let’s figure out what we can cut to make room in the budget…” If your contractor is good and trustworthy, they will work with you to get you the house you wanted, for the budget you’d agreed to.
It’s the same with software development. Calavista’s been doing this for so long that we can estimate most projects quickly, with high confidence of accuracy. If something unexpected happens, we work with the customer to figure out the best solution. Using this collaborative approach, we end up being on time, and on budget, about 95% of the time².
Contrast this to the customer who comes in with a 20-page specification and wants a Fixed-Fee price. We have to tell them:
- The spec they’ve written is fine, but it needs to be replaced with a 200-page version. It’s not sufficient to say, “there will be a connection to a 3rd party payment gateway a customer can use to make payments.” Instead, we’ll need to know which one they want to use and what SLA they’re signing up for. We’ll need to evaluate the 3rd party’s API and maybe prototype it out so that we know for sure it’s going to work correctly – because we’re on the hook if it doesn’t. And we’ll need to have at least wireframes of the payment page to see its complexity. Maybe even some high-res art.
- Then we’ll spend a long time scoping it out. We’ll go through each of the 200 pages in detail and figure out how much we’d expect to have to charge them to deliver that, and then we’ll need to multiply that by 1.x. Maybe 1.25, or even 1.5 – because now all of the risk is on us. If some piece of it is thornier than we’d realized, we’ll have to eat the extra cost.
- Finally, we’ll end up fighting tooth and nail about what’s in the spec, and what’s a change order. The customer will want to get everything we’ve committed to for the fixed price, and we’ll want to make sure they’re paying extra for everything that’s not in the spec.
- In the end, it’ll take much longer to start, will cost more (even without change orders), and we’ll be at each other’s throats the whole time.
It’s a horrible way to do business.
When Fixed-Fee Makes Sense
OK, there are some projects where it makes sense. In addition to the advantages to the customer listed above, Fixed-Fee allows a degree of flexibility on the part of the vendor as well. For instance, if we have extra development capacity, it might make sense to just put those spare resources on the project and finish early. If it’s T&M, I’d have to charge extra for those resources, but with Fixed-Fee, the customer gets the product faster, and I’ve increased my utilization rate for my people. Everyone wins.
So, for well-scoped, well-understood, and small projects – meaning they’re not big enough that they really can drift far – it can be simpler for everyone to just bid the price.
Caveat Emptor
Finally – this entire post has assumed you’re working with a reputable – and good – software company. If not, then T&M will just be a crapshoot. In that case, it might be better to invest in a detailed spec that you can live with and avoid changes. Or best yet, find a company that is good, and reputable.
How can you tell if a company’s good, and reputable? I’ll get to that when I talk about the “quality” priority in a later post…
Summary
About 90% of the time, Calavista engages customers in a Time and Materials model. This allows us to be less conservative with our estimates (i.e. lower the Total Cost of Labor) – not because the customer will pay for overruns, but because we and the customer both want to keep costs under control. On a Fixed Fee project, Calavista assumes all of the risks of unpredictable delays and must swallow any overage ourselves. So, we charge more. With Time and Materials, we can work with the customer to figure out the best way around an obstacle, rather than just paying to plow through it, so we don’t have to build those risks into the cost structure. For this reason, T&M estimates are generally 25-30% lower than fixed-fee bids, while still providing an excellent likelihood of success.
But again, finding a good, reputable company to work with is paramount. More on that later.
¹ en.wikipedia.org/wiki/Agile_software_development
² 94.4% at last tally
