Fixed Price Vs Hourly Rate- The Dilemma of a customer

You have thought of the idea – Step 1 Achieved. POC document is “almost” ready – Step 2 Achieved. Found an outsourcing/development partner – Step 3 Achieved. And this is where the confusion starts. Fixed bid or Hourly agreement for development???

The Impasse of choosing between Hourly Rate (also known as Time and Material) and fixed price contract is eventually one of the most important decisions that need to be made at start of the engagement. Whilst most software development companies offer both types, some agree on either of the two. There are many discussions on which contract type is best, I am giving a perspective why and when is either of the two better.

In this article, I will try to compare the two types of contracts, which might help you make an informed decision which one fits you best.

Simple to start things off –

T&M (Time and Material) are generally short, simple and relatively modest to achieve results. T&M contract would include hourly rates, IP rights and protection, NDA’s and payment terms. The contract would not include a scope of work (SOW) as the scope can change and as a Product Owner, the customer enjoys the flexibility to include scope creeps during the development of the projects. Scope changes are communicated to development teams and are decided based on priorities of the tasks.

Fixed priced contracts, due to fixed project scope, require extremely detailed description of what has to be delivered. You need to be really careful to cover everything you want and include it in the scope. Any changes usually result in time consuming renegotiations of the contract, estimating additional requirements and changing the price. So eventually, in fixed price – you should be clear on what to achieve on day 1 with a view of let’s say 6 months down the line and no changes are to be accepted midway of the project. So most of software development firms opt to ask for detailed requirement specification documents, IT architecture diagrams, project timelines and build delivery frameworks before kicking off the project.

If you prefer to invest your time and budget on actual software development and seeing things in action instead of lawyers and contract negotiations, the time and material contract might be your pick.

T&M by definition means you only pay for time spent on development of the project. Contracts generally don’t have start and end dates bringing in the flexibility to end the contract within agreed notice periods. This puts contracting companies in a position to work better to retain the customer and gain long term trust of product owners for further development

Fixed price are usually signed for longer, specified period of time. No flexibility is at hand to change contractor’s mid-way and has financial penalties. Products terminated before logical closure has earlier resulted into no ownership of code and lot of wasted time and money.

Having given the above view, it is also true that as a product owner you can divide the project into smaller components and start treating each component as a fixed bid entity with your software vendor. This will bring in more clarity on pricing, time and cost associated but will also increase your effort towards software delivery.

 Flexible Scope brings freedom to innovate

With 2 major types of software development still followed across the globe – Agile and Waterfall ( and some offshoots of it), the choice between the two should help you decide forward with what contract model you want to move with. While Agile is best suited for T&M, Waterfall has more relevance to Fixed Price.

With Agile bringing in flexibility in the scope, no one has the answers till some solution/ POC is launched and feedback is attained. You want to deliver what’s best for the market you aim for while learning and building at the same time. Agile will allow you to realign your goals with additional market changes, feedbacks and the best part – you don’t have to pay for anything upfront.

Waterfall with Fixed price will keep time and scope fixed to predict the total price upfront. It is assumed by development team what the customer wants and knows exactly what is to be built. Now we all know that is not usually the case in software development and dynamic startup nature.

Software Development team has no incentive to lower the Quality of deliverable or the product in T&M engagement

While working on T&M – it means that contractor will get paid for how much time they have spent on the project. No incentive for them to take shortcuts, reuse crappy code and let quality suffer. Contractors realize that code quality is to be kept high and deliver exactly what is required.

In Fixed Bid – contractors will receive fixed amount of money – no matter how much time they spend, what level of resources they put, what is quality standards of deliverables etc.

The less time spent on a project means higher profit margins. This might bring poor quality and mismatch of expectations.

There could be counter arguments as to fixed bid can be time bound and code quality standards could be negotiated upfront but we all again know that despite a detailed product specification at hand during the time of contract, there is always space for discussion and that can be leveraged asking for more time and money by contractor.

 Pick what’s good for your Budget

In T&M contracts, budget is customer responsibility. Most development companies will provide estimates of time required to deliver your project based on initial scope. As requirements are preliminary, so are the estimations. It helps give you an idea what to expect, but in the end all is up to you on further course of action. As the Product Owner, you are in frequent touch with delivery team, contributing in sprints, feedbacks, modifying scope etc. While keeping Budget on top of your list, you can always trade off on scope Vs cost Vs deliverables Vs priorities. No matter what decision you make, you are only investing for time spent on the project.

With Fixed Price, you know the budget upfront and that becomes one of the strongest advocacies for fixed bids. As Development projects are next to impossible to predict accurately, Software development contractor will pump up the numbers by including risk elements on the project if it takes longer than anticipated to deliver. This means a you are paying for a premium for agreeing on fixed fee for the services.

It eventually also depends on what is the project you want to achieve – a simple example – if you have a project and application available on iOS but want the same to be replicated as is to other platforms, Fixed bid sure is the way to go. However, if starting a project with idea In mind, some white boarding of concepts and workflows done, some documentation achieved, you know T&M is the route to take.

 Transparent Development Process is the Key

Transparency is key in T&M projects. You need to know what the invoice covers and what has been done during that time to be sure the amount stated is fair. Most development companies working on time and material will provide you with a report stating how much time was spent on each task – the Time sheets that you approved before raising the invoice. Ideally you should get access to the internal development and tracking systems, and updates by contributing in daily standups, weekly sprints etc. making you up to date Always.

Fixed price contracts do not require reporting the time spent on tasks. You are paying a fixed fee, so it is up to the contractor to make sure the project is profitable for them. Often the product will be developed for a longer period of time, after which you will see the deliverables. This increases the risk of going in the wrong direction, as the Product Owner is likely to be excluded from the process. The team will build what they understand is described in the requirements and only present the end result. Sometimes vendors doing fixed bid try to bring a level of transparency but when compared to T&M, it is very minimal.

Conclusion

In the end, based on reasoning stated above, I feel that it entirely depends on the time, situation, solution, clarity of thought, involvement level, money involved and predictability a product owner wants – that defines the next logical step of engagement model. It is in best interest of the product owner to keep things in perspective, do due diligence with a SWOT analysis based on his constraints and then take an informed decision on the path forward.

Some things while considering the engagement model should be clear – no compromise on Quality of code, usability of the application and a timely Go To Market are aspects that should stand non-negotiable.

Thanks and Regards

Dipankar Gupta