I still run into a lot of companies that have the expectation that software development can be done on a fixed-price basis. They’re either still used to waterfall management style, or dealing with goods vendors, or, maybe a few are still running into software developers willing to work on a fixed-price basis.
On this blog, we’ve talked about the dangers inherent in fixed-price development services. How companies willing to offer an FPB will triple their hourly rate for change requests in order to make up the margin they already know exists between what they think the project will cost, and what it actually will end up costing. How every project, no matter how well planned out, rarely looks the same at the finish as it did at the start. How the number of unknowns at the start of a development project could fill a dump truck. What we haven’t talked much about is when it is reasonable to ask for, or expect, a fixed price.
It may come as a surprise to our regular readers that there are some times when a fixed-price bid for development services is the best thing for all parties involved. There are two circumstances where I’d be willing to offer a fixed price to a client:
Number One
The project’s goals are very small in scope. Software developers are good at determining the effort involved in small, discrete sets of tasks. No one is good at estimating large projects. All the data show that in most cases, you’re lucky to get within 50% of the actual cost based on estimates delivered at the start of a project. It’s simply impossible to determine the scope and risks involved a multi-month project, even if there’s only one developer working on it. Yet we have potential clients who want us to build a multi-faceted ERP engine in the cloud complete with fully customizable reporting in 6 months and expect us to know exactly how much it will cost before we’ve even begun real requirements discovery. That is just never going to happen.
Now, if you want us to give you a fixed-price estimate on a small proof of concept, or a discovery phase, a code review, even a small development project, we can do that. Most developers can be pretty accurate as long as the development scale is about a month’s worth of work or less. So if you’ve got a small, single-function project, it may be reasonable to negotiate a fixed price with your developer. If you need to pull data from a single database and display it in a visually pleasing manner, we can talk about FPBs. If you need to trigger an email based on data being added or subtracted from a database, you could reasonably expect your dev company to give you a fixed price.
Number Two
Which brings me to the second circumstance where fixed price bids are reasonable, and this one may appeal more to those of you in need of large scale development. While we may not be able to tell you exactly how many months we expect your project to take, we can tell you accurately what a month’s worth of development costs will be, at pretty much any scale. We can know, say, that X developers, working full time for a month in conjunction with a project manager and tester will cost $N. That is quantifiable. More than that, we can reasonably parcel out a discrete set of tasks that will keep those developers busy for the full month. And, in that way, we can provide you with a fixed monthly cost. And by treating each month as a single milestone, basically a mini-project, we can provide you with the economic certainty you need to feel comfortable allocating budget to the project for a particular fiscal period.
Now, to accomplish all of your goals, your project may require ten mini-projects (month-long milestones). It may require 15. It may require seven. It’s going to be very hard for any developer to answer that question with any amount of certainty. But by reorienting the scale of your project, we can tell you that your project will cost you, say, $30K/month for some range of months, and you can plan fiscally around that. You can deploy your new software incrementally in fully developed usable packages, and utilize the feedback derived from its live use into further development. And you decide when it’s complete, rather than some arbitrary list features and tasks that are written months in the past that may or may not accomplish your end-goal.
Some software developers get downright prickly when they are asked to provide fixed cost estimates for projects. They might artificially inflate the numbers, and even when they do so, they are likely to underestimate the total cost involved in a development effort. Which promises to lose them money, and make you angry. So instead of making everyone upset, let’s strive together to keep our projects small, our increments reasonable, and our expectations open.
