In some industries, it’s easy to calculate a price for a product sold or service rendered. Often it’s cost plus some margin, or time spent and the cost of the raw materials used.
In software development, it’s usually hard to do, and for a simple reason: it’s very hard to accurately estimate the cost of a project. There are a number of variables affecting the cost. For example, the project requirements or scope might not be precisely known, the technology used can have varying quality of implementation, documentation or fitness for the project, or the developers may have an inadequate understanding of the problem domain.
While some reasons can be mitigated with more research or education (better understanding of the technology and the problem domain), project requirements issue is practically unavoidable. So much so, that there’s an entire slew of agile software development methodologies that attempt to address the problem: Scrum, Kanban and XP being the more prominent ones.
While the agile methodologies show a lot of success, they require a buy-in from both the client and the developer. This is easier to achieve on in-house projects (where the client is typically the management), than to impose on a client for a consulting agency or a single freelancer.
The fixed-price project
In our experience, most clients still prefer the waterfall model, or, as it’s called in this case, the “fixed-price project”.
The ostensible benefits are easy to see: they can plan the cost and project timeline easier. Any risks in overruns are carried by the contractor. Some clients even require penalties for deadline misses, in which case the contractor carries double the risk: extended project means more cost and additional cost for the penalties.
In theory, fixed-price project could work if the project scope and requirements are perfectly known and never change. In practice, this is never the case. Often the requirements are vague with a lot of edge cases (sometimes important, sometimes not) not being described. Sometimes the client and the developer have differing views of what’s obvious and sensible. And sometimes, the scope and requirements are changed based on the new knowledge gathered during the course of development.
To protect against these risks the contractor has no other choice but to estimate the risk, add a padding to the project cost and hope it wasn’t underestimated.
So the hidden costs for the client of the fixed-price contract are the increased cost, a real probability of the project slipping and missing deadlines, and the inability to adapt the project as new requirements are uncovered.
The time & materials project
Time & materials projects, also known as hourly (or daily, or weekly) rate projects, on the other hand, pass the risk on to the client. If the project requires more time and resources, the client will pay more. It’s easy to see why clients are vary of this approach, as both the cost and the delivery time seem unbounded, and practically no guarantees can be given.
This may not necessarily be the case, and the agile methodologies mentioned before provide some good pointers into how to address these drawbacks. It all boils down to improving communication between the developer and the client, and avoiding doing unnecessary work.
Good communication between the client and the contractor is crucial for all types of projects. In fixed-price projects, the responsibility for this is pushed to the client, who is expected to provide a perfect documentation that the contractor can just take away and return with a finished project.
In time & materials projects, the communication must go both ways and happen throughout the project. This means client choosing and updating their priorities (“everything is a must have” won’t work), and the contractor keeping the client up to date with the ongoing progress, giving feedback on the cost (or any potential risks) for all the client’s requests, as well as reporting any problems as soon as possible.
In an essence, the time & materials project allows for splitting the work into a lot of related mini-projects (tasks, backlog items, iterations) that can be easier to estimate, prioritize, build and deliver.
This way, the client keeps control over the project time, budget and scope.
The issue of trust
This does require that the client trusts the contractor. In particular, that the contractor will be able to give good estimates and feedback for each task. But this trust is needed in any kind of project.
Even for fixed-time and payment-on-delivery projects, the client must have confidence that the contractor can complete it on time and that the end result will be of adequate quality and maintainable.
Fixed or agile?
Fixed-price project might still make sense in some cases: when the project is small, the requirements precise, and the outline of the solution already known. What is “small”? In our experience, up to a month of work for a single person. Ideally, a week. Everything larger than a month includes a fair amount of guesswork, and is better suited to time-based project cost structure.
This rule of thumb comes mainly from our experience in writing web applications, so of course it doesn’t apply to all kinds of projects, so take the conclusion here with a grain of salt. But it’s a good starting point when considering whether to set up a project as fixed or time-based, whether you’re a client or a contractor.