When budgeting for a software development project, the client typically prefers a fixed price budget. They want to know what something is going to cost to build upfront and that that number won’t change.
The developer, on the other hand, typically prefers hourly. They want to know that they will get paid for the work that they do and that if there are unknown complexities or change requirements down the road, they won’t get stuck doing extra work without being compensated.
The question is - which one is better for the project? Let’s reason.
The case for why fixed-price is better for the project
Deadlines are powerful motivators. They force us to hunker down and produce a finished product within a limited timeframe. By committing to a fixed price, the developer can be more productive in less time. The client also wants to roll out their new digital product as soon as possible, so both sides are incentivized to get the work done as quickly as possible.
Fixed price also adds a safeguard against jumping into the build phase before clearly defining the scope. In hourly, a developer might shoot first and ask questions later. In fixed price, the developer is incentivized to take the time to understand the work upfront, or risk underestimating the scope.
Business planning is more straightforward in fixed price because you know for certain how much you will spend. You budget that amount and can turn your attention to other areas.
The case for why fixed-price is worse for the project
Fixed timelines create pressure to deliver quickly. That increases the likelihood of error-ridden work products. There will be no time to write unit tests or try peer programming. Refactoring will likely get pushed off to a secondary stage or omitted altogether. In the race to deliver features, quality and thoughtfulness will constantly be devalued.
In fixed-price contracts, there is little room for change requests. Through the development process, new information will be uncovered that, as product lead, you will want to act upon. You may forget that Apple’s new OS is releasing in a month and you should be compatible for that. Or you may encounter new functionality in the onboarding process that feels critical for launch. If the contract is fixed-price, it will be a constant battle to swap one functionality for another. More likely, you will have to negotiate and estimate multiple project extensions. This process is extremely inefficient for both client and developer.
Fixed-price estimates have to build in a buffer for unknowns, so are often 30-50% higher than hourly estimates. If they finish below the estimate, developers are rewarded the extra budget. If they finish above the estimate, they are penalized with uncompensated work, which is never good for the quality of a project. This dynamic incentivizes the developer to spend the least amount of time on the work, which also contributes to poor quality work product.
Finally, fixed price contracts create opposing interests between client and developer. Client wants the developer to write good code and be flexible to change requirements. The developer is under extreme pressure to deliver quickly, at all costs, and to resist any change that comes.
The case for why hourly is better for the project
Due to the inherent complexity in software development, estimating work effort is a risky proposition. This is especially true at the outset of a project, when developers have the least amount of information. If they spend an hour looking over some hastily assembled requirements then shoot out an estimate of 2-3 months with 2-developers, the risk factor is much higher than if they spend a month going through requirements, researching, and testing out platforms, while continuously refining their estimates.
With hourly, developers are compensated for their estimation time and thus encouraged to be more thoughtful about it. They can take the time to really go through each feature and functionality, even testing out a few third-party platforms to assess how they can improve work velocity. This brings the risk level down significantly, making it easier to manage budgets and timelines.
The case for why hourly is worse for the project
Software development is an exercise in learning. You’re always learning new functions, integrating with new platforms, building new functionality. When learning, it’s easy to get lost in the rabbit hole, chasing after tutorials, reading every comment in a thread, and putting off the part where you make the thing work. If not managed well, hourly projects can drag on.
If you believe pressure is an important factor in producing quality work, there is less pressure on an hourly commitment. The developer knows that as long as they clock in and out, they will for the most part be meeting their expectations.
Their incentive structure isn’t tied so much to deliverables as it is to spending time working on something. Meetings that take hours pop out on invoices as wasted time. Research feels like a time sink. As a manager, you fret about time, all of the time.
The case for Agile with Not-To-Exceed budgets
In agile, you try to account for the strengths and weaknesses of hourly and fixed-price through the Sprint system. No matter your fee structure, stories will be estimated and prioritized, put into a sprint, and delivered at the end of that sprint. Velocity is measured based on past work and process improvements are discussed throughout the project. When change requests are needed, you can simply take another story with similar velocity points and swap it out of the sprint with the new change story. In a way, each sprint is a mini fixed-price project.
When you add in Not-To-Exceed budgets, you maintain the benefits of hourly. At the outset of a project, you agree to a fixed number of sprints and a generalized set of features. The only absolute is that you will launch a viable version of your product at the end of that period. Which specific features will make the cut becomes a collaborative negotiation between developer and client. This provides the benefits of fixed price in that the client knows their bottom line budget at the beginning of the project, while incorporating the benefits of hourly by enabling flexibility in change requests.
Teams are incentivized to work together to prioritize features, to work through unexpected challenges, and to adapt throughout the course of the engagement. The sprints build in two-week checkpoints that ensure process breakdowns or setbacks are caught and addressed early on.
Related: 7 Types of Agile
Which fee structure do you prefer? Shoot me a note at Andrew@sfappworks.com, or on twitter @abgr26.
.png?%20White%20Bake%20Sale%20Promotion%20Facebook%20Post%20(4).png&width=290&name=Simple%20Pink%20%26%20White%20Bake%20Sale%20Promotion%20Facebook%20Post%20(4).png?%20White%20Bake%20Sale%20Promotion%20Facebook%20Post%20(4).png)
COMMENTS