Contract Pricing: Time & Materials

No Tags | Industry Insights

The topic of the last post was fixed fee pricing and when it’s appropriate, what the benefits/drawbacks are, and what one can expect regarding pricing terms.  As stated in that post, regardless if the software provider is in the US, offshore, or nearshore, the only alternative to fixed fee pricing for most mobile app development or web development engagements is to pay by the hour at an agreed upon rate (or agreed upon rates). This is referred to as Time and Materials billing and is widely used within the industry.

When Is Time & Materials Billing Appropriate?

Paying by the hour for Web development projects can be tricky. If overall requirements are understood up front by the vendor, and the project is managed and monitored closely by both the provider and the customer, the customer can potentially save money during the development process. However, if left unmanaged and if the requirements are not well documented or understood up front, paying by the hour can quickly topple a budget and exceed the expected cost for a solution.

Why is this? Software providers generally love to get paid by the hour…preferably on retainer. In many ways, it makes a lot of sense. You are only paying for the service received and almost all providers in my experience keep great records and are very honest in the time that they track and bill. This model, though, tends to takes certain healthy pressures off of the provider that are appropriate during an engagement. It will only work if an estimate is given up front and an expected billing range (above and below the estimate) is acknowledged by both parties.

What are the benefits?

As stated above, the benefit of this model is that you are only paying for hours worked and for any materials used. Period. So if measures are in place to effectively manage and monitor the work, then the project has a chance to even come in under the estimated budget.
Another benefit to this model is its inherent fluidity. Given that the customer has agreed to pay for all hours worked, then the provider is typically very willing to work with fluid requirements that change or update during the engagement. NOTE: this is also one of the biggest risks to this model! Scope creep is one of the biggest sources of frustration by clients that pay for custom software development services.

What is the drawback?

The biggest drawback to this model occurs when the hours required to deliver a solution to a client exceed the estimated hours originally provided. This happens every day and even with the very best providers in the industry. Custom development projects are complex and even the most well planned projects experience issues that were unforeseen prior the project starting. That is why you sometimes see a “Not to Exceed” clause in contracts for well-defined requirements.

The client agrees to pay by the hour, but the provider also agrees to a price ceiling on the project in this instance. If things go very well, the project comes in under budget. If things do not go as well, there is some protection for the client with the pricing ceiling, and some room for the vendor to make additional money for unexpected work. It should be noted that providers will have strict language around the Not to Exceed clause, as they will not allow themselves to get into a situation where they are addressing new features during the engagement that were not understood in the beginning.

When is the money due?

Typically, nearshore partners bill monthly for t&m projects. Some require retainers up front that the project works against.

What should be included in a t&m contract?

Although certain project parameters embedded in the contract become less important compared to fixed fee engagements, it’s still recommended that the following terms are well defined just to ensure that both parties are on the same page:

  • Specifically list the project deliverables (i.e. source code, project notes, any training, etc.)
  • What application platforms will be supported (i.e. if you are building a mobile app, is it for an iPhone? Android? Both?)
  • What browsers, devices and operating systems will be tested for compatibility with the application or website?
  • Specifically list any project exclusions
  • If there will be a warranty period, list the specific terms (typically, a warranty period will exist when an “application” is being built)

Is the fee negotiable?

Often times, yes (same answer as for fixed fee projects). Expect to pay different rates for different levels of engineering skillsets and experience.

No Comments