Stack Exchange

Fix Price vs. Time and Material Contracts

August 13, 2012 by . 8 comments

Post to Twitter Post to Facebook Post to Reddit Post to LinkedIn Post to StumbleUpon Post to Digg Post to Delicious Post to Technorati

Some time ago, the development team at my firm staged a revolt against the sales team and senior management: our demand was that no Statement of Work was to be sent to a customer without first being reviewed by a member of the development team.

The message was clear: “We refuse to be held responsible to deliver on terms in which we had no say”. Today it’s not uncommon for a senior member of a development team to author a SOW in its entirety. In many ways they are better equipped than sales staff to write a SOW. They are good with documents (questionable), are very detail oriented, are great at finding loopholes, and at breaking down large ideas into small, manageable chunks. Today I would like to explore an important aspect of any Statement of Work: the pricing model.

Though there are countless pricing models in use throughout the world, the two that are most prevalent in the IT world are:

  • Fixed Price (also referred to as Fixed Fee)

Both the price and the scope of work are set in the SOW and neither change without agreement from both parties. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A.

  • Time and Material (T&M)

The buyer agrees to pay a set amount per hour plus the cost of materials and other expenses. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A per hour of effort needed to produced, Y and Z. You (buyer) will also reimburse me (seller) for any expenses I may incur (Hardware, travel etc.).

The major difference between these two is who bears the risk if you exceed the estimate. With Fixed Price, it’s you the IT professional who bears the risk. With T&M it’s your client. Regardless of what pricing model you choose, you will need to estimate what it will cost to perform the work (even with a T&M contract the client is going to want an estimate before signing it). As the professional, it is you who are responsible for the estimate, and logic would follow you should stand by your estimate and accept responsibility if it is off.

That said, any time you take additional risk you should be compensated for it. As a rule of thumb I would recommend charging a 20% premium on a fixed price contract over a T&M one. So the same contract under a T&M pricing model (assuming you are spot on with your estimation) will be 20% less than a fixed price one.

Based on the premise above, I propose the following: You should adopt a policy of always choosing Fixed Price over T&M unless you have a good reason not to. Before I delve into the details of what exactly is a good reason to choose T&M over Fixed Price, I want to dispel a few myths:

Myth: Risk is bad

Fact: Risk is an opportunity to make (or lose) money. It’s neither good nor bad. As I have stated above you can easily earn 20% more just by accepting the risk associated with your own estimate.

Myth: T&M pricing protects you if you exceed your estimate.

Fact: If you exceed your estimate, even with a T&M pricing model your client will fight you tooth and nail over the overage, even small overages (This is even more true in today’s world of tightened budgets). Often he will refuse to pay above the estimate forcing you into a compromise. Getting new business from this client will be substantially harder next time.

Myth: With T&M you don’t need a change control process.

Fact: You will need to show hard evidence explaining why your estimate was wrong. The only evidence worth anything is client signed change control documents that clearly outline the cost of the change.

Myth: With T&M, the client benefits if you are under your estimate.

Fact: Consulting firms will simply not leave money on the table.

Myth: Incompetency in your firm’s ability to accurately estimate is a good reason to choose T&M

Fact: Unless you are upfront with your client about your inability to estimate a project choosing this reason for T&M is unethical. You (your firm) are professionals; you sold yourself as experts with statements like “We’ve done this kind of stuff a hundred times before!” If you cannot properly estimate a project, you have no right to call yourself experts on the subject matter. If you would never tell your prospective client the real reason you are proposing T&M, your reason for choosing T&M is simply not valid, and likely unethical. You did the Estimate, you are the expert, and it’s your job to know how long it will take and what problems may arise. (I’ll say it a second time: You are a professional; accept responsibility for your estimates)

Myth: Double your estimate, just to be safe.

Fact: This myth comes in many varieties, which can range from adding 15% to quadrupling your estimate. The truth is, doubling your estimate will simply make your bid uncompetitive (or unrealistic), and you will lose the contract to a competitor. (Three’s a charm: You are a professional; accept responsibility for your estimates)

Myth: Developers don’t need to know the pricing model.

Fact: Everyone on the team needs to know the pricing model. It effects every decision the team makes that involves effort. Who is paying for the effort is always a factor in such decisions.

Okay, so what is a good reason to choose T&M? A good rule of thumb is “If you are unable or unwilling to give your client a solid estimate AND you can explain the reason you can’t (or won’t) in a way your client will understand and respect you should go with T&M”. Keep in mind that just because you can’t (or won’t) estimate a particular task, doesn’t mean that the entire SOW must be T&M. You can specify T&M for some tasks and Fixed price for others). Here are the most common examples:

  • Insufficient data to properly estimate it: Your client is asking you to migrate data from an internal proprietary system to a new system you are implementing. Your client says the data is clean and properly normalized. Because you have nothing other than your client’s words to go on, your client should accept the risk of his information being wrong.

  • Your client wants to take part in the project in any way: If he is providing resources (ie internal developers or another vendor is participating that the client is managing) or if you are working on site, you should go T&M. You should not be held accountable for the performance of your client’s resources where you are obligated to ensure they succeed. Chances are high that you will wind up performing this work in its entirety, while fearing to tell the client that his trusted employees are incompetent.

  • Your client has a culture of excessive meetings and bureaucracy: This kind of culture tends to exist with larger fortune 500 type firms. The only way to work with this kind of client on a fixed price basis is to specify in the SOW exactly what kind of documents will be submitted and how many hours of meetings will be attended. Often the client has to do days research just to get you a list (and templates) of documents that need to be submitted in order for the system to move from one environment to another. Unless you have a history with the client this is hard if not impossible to estimate.

  • Your client insists on T&M: This usually happens after you have built a relationship with your client; he trusts you and no longer wants to accept the risk and rewards (the 20% discount) of T&M.

  • Your client is looking for a support contract: With support contracts, instead of defining specific work to be done, only the type of work to be done is specified, and it is performed as needed.

The last point I want to make is this: if you are bidding on a very large project I would strongly suggest that you split the project into phases with separate contracts. The first phase will deal with requirements gathering and system design. Once that phase is done, you will be in a much better position to properly estimate the effort required for the development phase.

When your estimates are accurate everyone wins.

Post to Twitter Post to Facebook Post to Reddit Post to LinkedIn Post to StumbleUpon Post to Digg Post to Delicious Post to Technorati

Filed under Project Managment

8 Comments

Subscribe to comments with RSS.

  • Joel Brown says:

    I don’t like fixed price contracts, regardless of the opportunity to be rewarded for assuming more risk. As soon as you go fixed price, you make the nature of the client-consultant relationship adversarial. Fixed price is a zero sum game. The client’s motivation is to stuff as much extra scope into the project as possible and the consultant’s motivation is to be as intransigent as possible about dealing with the inevitable scope creep. No SOW is ever perfect so there will always be arguments over interpretation. If you work T&M instead of fixed price, then both parties are motivated to work together instead of against each other. The client won’t over-pay because they will only pay for what they see as being worthwhile and the consultant is motivated to do great work so that the client sees enough benefit to keep working.

  • Morons says:

    Joel,

    As soon as you go fixed price, you make the nature of the client-consultant relationship adversarial. Fixed price is a zero sum game

    I adamantly disagree with this here’s why: Myth # 3 – With T&M you don’t need a change control process. – The fact of the matter is that discussion of cost will take place regardless of the pricing model. If those conversations become adversarial it has nothing to with the Pricing Model.

    The client’s motivation is to stuff as much extra scope into the project as possible and the consultant’s motivation is to be as intransigent as possible about dealing with the inevitable scope creep.

    This is simply not true, Even with T&M Projects, Clients push to get free stuff, and YES even with T&M Projects Vendors give in and give away freebees. I will make preventing this the Topic of a future Blog Post.

    Without more information I can’t explain why you are experiencing T&M projects to be less adversarial, but I suspect one or more of the exceptions I mentioned, namely

    • You are working Onsite (Exception #2)
    • Your client insists on T&M (Exception #4)
  • Both of them are bad.. it makes only one side win/exploit.. e.g in Fixed Fee Provider Suffers which results in inferior product to clients. In T&M Provider is Safe and can continue to enjoy complicating things to Customers and would result in infinite list of bugs, regression and too brittle code.

    We recommend Services 2.0 model for IT products to win (making either side win and feel responsible for World class results)

    sandhill.com/article/the-tcs-story-%E2%80%93-qa-with-vice-chairman-s-ramadorai/

    nasscom-emerge.groupsite.com/beta/discussion/topics/531869/messages

    Regards, Raja Nagendra Kumar, TejaSoft

  • Sharma says:

    Good Post. Estimation is the weakest area in the IT industry. especially the objective and scientific estimation. I completely agree, ownership of estimates and visibility to customer enable long term relationship.

    regards

  • Arthur says:

    Interesting article. And I do understand and appreaciate the approach of owning up to your words/promises/estimates and delivering based on that, with possible rewards to be had.

    However, my own article on the topic suggests completely the opposite – always go T&M, and don’t waste time estimating. Fixed price thinking lies on all the wrong premises..

    http://wp.me/p2sZBz-7o

  • Shannon says:

    This is probably one of the oldest arguments around in the Consulting world. For me, it really depends on the industry, some industries fixed price makes the most sense, other T&M makes the most sense. For custom software applications, IMHO T&M is the only way to go, too many unknowns. Here’s a blog I wrote on my T&M really is customer focus. http://www.panopticdev.com/blog2013/why-billing-time-and-materials-basis-really-custom/

  • Athiq says:

    I would like to know on how do we calculate the Actual Cost, Planned Value, earned value for Time Material projects

  • Leave a comment

    Log in
    with Stack Exchange
    or