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.
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)
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.