Hourly or flat rate contracts – which one is right for your project?
Most vendor agreements are either fixed rate, where a payment amount is agreed upon up front, or time and materials, which entails paying for the accumulated time that the vendor’s team spends working, usually on an hourly basis. It’s important to match the right type of contract with the circumstances. This article lays out the details of each contract type and the cases for using them.
Because fixed rate contracts entail arriving at a cost up front, you need to base that cost on something. This usually means that an estimate of work is done before the project kicks off, which establishes the scope of work and thus the price. This estimate is usually done as a separate “discovery” phase in a different agreement than the main software development deal. An outcome of the discovery phase is a document, usually called the Statement of Work, that describes the work that will be performed and the solution that will be built.
If you are going with fixed rate, you should structure your agreement so that payments are made at increments throughout the project. For example, at the end of design, the end of build, the end of test and the delivery of assets.
Change is a big factor in this model. Software projects frequently have changes in basic requirements. If you are in a fixed price agreement, your vendor will likely invoke the change process when a change is requested. This process involves reviewing the requested change, evaluating the impacts, and producing a new price quote.
Sometimes you may decide to reduce the scope of work. For example, you might push a feature to a future release. I find that vendors rarely invoke the change process in that case. The onus is on you to invoke the change process. Have the vendor talley the work that will not be done as a result of the change, and adjust the price accordingly.
Time and materials
Time and materials means paying by the hour for the staff involved in the creation of the product. (Materials are rarely involved in a software project.) There are two ways to establish this hourly rate. One is that you are given a rate sheet for the various disciplines involved in the project. The rates reflect the market prices for the talent involved in your project. You will pay more for some roles and less for others. Another approach is a “blended rate” where a single hourly rate is agreed to for all participants.
Rates typically range from $100 to $250 per hour, but may go much higher for specialized work or work in an emerging field where talent is scarce.
Flexibility is a benefit of the time and materials approach. Change your mind whenever you want. You are paying your vendor by the hour. If you want to impose some controls, ask the vendor for an estimate before you start, and use that as a baseline as you go.
As a customer, I consider both fixed price and time and materials unsatisfactory because most of what you pay goes toward the vendor’s overhead and profit. There are a couple ways to hack the system and get your money’s worth. One is to do the project entirely with freelancers. I’ll cover that in a different article. Another way is to hire one or more freelancers alongside your vendor. In general, the cost of that freelancer will be less than half of the vendor’s hourly rate and give you additional options.
As a freelancer myself, I am biased. I’ll get back to fixed rate vs. time and materials now.
|Fixed Rate||Time and Materials|
|How you start||There is a phase where the vendor asks a lot of questions. They are sizing up the work.||A good project manager will start as soon as the first tasks have no predecessors. For example you might start with user stories or high level UX design.|
|How the bill is calculated||The total amount is known up front, aside from change orders.||You pay monthly for hours of work accumulated on the project.|
|How change is managed||When a change is detected, the vendor’s change process kicks in and the project cost is revisited.||There is usually no formal change process. The team just changes direction as the requirements change.|
|Integrating your staff developers into the project||Usually frowned upon by the vendor or even forbidden.||Usually OK with the vendor, since the vendor is not incurring the responsibility for the product.|
|Vendor profits||The vendor may profit or, less commonly, fail to profit. They incur the risk.||The vendor always profits since they always bill for the staff cost they incur.|
|Value||Usually less value for you, since the vendor needs to increase the cost to mitigate the risk of going over budget.||Usually greater value, assuming the hourly costs are reasonable.|
|Project dynamics||There may be tension throughout the project because the amount you pay is fixed but what you get back will be determined largely by the vendor.||Less tension since the vendor is sure to profit at a predictable rate and the client has control of the scope.|
|Development philosophy||Works best in waterfall environments since you need to “know everything” up front to know what the price is. Change is resisted to maintain that price.||The best option for agile and iterative methodologies since change is expected and encouraged.|
Anyone who has done software or a related field like construction knows that things change as they move forward and the management of change is critical. For vendors, change can be a huge source of revenue, sometimes larger than the original contract.
While you may or may not agree with frameworks like Agile Scrum, you will probably agree that the outset of a project is a time of uncertainty. Once you are immersed in the project, things become clearer. Also external influences on project plans occur, such as changed stakeholder requirements and new versions of software you are dependent on.
Change plays a part in this conversation because of the major difference in how it is treated. With a fixed price contract, the vendor has done their best to see the future. They have padded their quote as a way to mitigate the inevitable unknowns that lie ahead. As you discuss this thing you are building, you may hear your project manager arbitrarily deem things in or out of scope. If you have a detailed spec, you might be able to fall back on that, but those are going out of style. Scope discussions are among the most common and contentious problems in the software business.
Time and materials projects start off easy. If the client wants it, it’s in. There is no need to write up a change order estimate it and route it for signatures.
Plan to negotiate
Software agreements are like any other deal – look at several vendors and plan to negotiate. In the case of fixed price agreements, scrutinize the Statement of Work. Is it clear? Does it convey the product you have in mind? In the case of time and materials, evaluate the hourly rates. Ask for a discount if you feel they are too high. Look over other elements of the contract as well, and for goodness sake, make sure you own your the final product.