It’s common knowledge that there are many different pricing schemes that IT consultants can submit to clients. One of those, fixed or “not to exceed” pricing, is beloved by clients for many reasons. Many need to be able to present their managers with a firm budget for a specific result. Some like it because they believe it protects them from being preyed upon by rapacious and unscrupulous contractors. More experienced clients are aware of the risk and uncertainty inherent in IT projects, and want to shift the risk to the consultant. I find, however, that the most sophisticated clients are the most likely to understand that they pay a premium for the assurance of a fixed price.
In part one of this column, we looked at time and materials and retainer-based engagements. In the next installment, I’ll examine the rest of the pricing structures, and then wrap up with a discussion about fitting the price structure to the project.
Consultants take many approaches to offering a fixed price to the client, but they all are focused on doing the same thing: balancing the risk fairly between consultant and client, by adding in a “risk premium” to cover contingencies and uncertainties. I’ve seen approaches to fixed pricing that vary from the wild guess with 25 percent tacked on, to the very methodical and structured approach taken by some Big 5 firms. No matter how structured or unstructured the process, however, it consists of a couple of steps:

  • Creating an estimate of the time and materials required to deliver the project.
  • Adding a risk premium to insure against the undiscovered “gotchas” that inevitably arise in every project.

Clients take estimates seriously
Since every fixed price begins with an estimate, let’s talk about project estimating. This is a topic that could easily fill a couple of columns, but for this discussion let’s just mention some baseline estimating disciplines.

As I mentioned before, estimates are sticky. They stick in the client’s mind forever, and so should never be delivered lightly. ”Whisper” estimates often get conveyed from sales folks to the client in the form of something like, “I’ve never seen a project like this cost more than X dollars,” or “The last time we did an Oracle conversion it cost the client Z dollars.” Some consultants are also guilty of this, as clients can be very persuasive in the sale process when they want to get a budgetary number.

Obviously, it’s critical to avoid this kind of selling, as it sets up an expectation in the client’s mind that can be impossible to erase, even though the current project may have no relation to the last one that cost X dollars.

Playing by the pricing rules
It’s also important to follow some simple rules when creating estimates:

  • Unless this is a packaged solution that’s been delivered many times before and has no risk factors, it’s impossible to do an accurate estimate without preparing a task list for the project. I prefer a full-blown project plan, but not every consultant can afford to put forth the effort to develop a complete plan, especially in the proposal stage. A detailed list of tasks and materials, created by the technical team, is the first element in any estimate.
  • Estimating must be participatory. Those tasked with delivering the project must be the ones making the estimates. This serves a number of purposes, both practical and psychological. On the practical side, it’s clear that the ones who actually do the work know what it takes to do the work. Their estimate is the only one with any experience behind it. Psychologically, this gives them a chance to buy into the project, and it commits them to the estimate they’ve created. It takes away the excuse that “someone else built the schedule without consulting me.”
  • Conflicts must be resolved before the estimate becomes a component of the fixed price. If Joe thinks it takes 12 hours to build a UNIX server, and Jane thinks it takes 12 minutes, hashing that out beforehand is crucial to ultimately delivering a fixed price everyone supports. This may seem obvious, but I often find groups of project managers and salespeople estimating projects with few or no technicians in the room. PMs and sales teams can participate, but technicians must own their estimates.
  • Risk must be analyzed. This doesn’t need to be a complex risk-mitigation process, but someone better ask the question “What can go wrong?” so everyone has a chance to note, for instance, that we’ve never actually done an Oracle conversion before. Every project should be rated as a high, medium, or low risk project, so that an appropriate risk premium can be applied. Also note that there are different types of risk. There’s technical risk, such as the risk of using a new piece of software, and there’s organizational risk, such as the risk that a client has never used a consultant before. Each must be assessed and built into the rating.

Give yourself a cushion
Once an estimate is reached, two additional calculations must be done. A risk premium must be added, and a contingency fund must be created. Some firms will add 50 percent for high risk, 35 percent for medium, and 20 percent for low risk. Others will make an off-the-cuff determination for each project based on their gut feel. Unfortunately, the only way to get this right is through experience, as you gauge your ability to estimate and to assess risk. It hurts to eat the difference when you estimate poorly, but those are the ones you learn from, and you get closer each time.

I recommend creating a separate contingency fund. If contingency money is just added into the fixed price as a “fudge factor,” it immediately becomes part of the base budget and is not available for real contingencies. If it’s held separately, it’s available if needed, and the client gets the psychological benefit of feeling like she recouped this money if it’s not used.

So, to reiterate, fixed price deals require a detailed task list created by the delivery team, an estimate based on that task list that the delivery team signs off on, a risk assessment, and then the creation of a price that includes the estimate, a risk premium, and a separate contingency fund.

Some final words on fixed pricing: Most consultants try to avoid fixed prices, and I agree. Fixed price makes sense only when you’re dealing with a client you know well—someone who understands the system development process, is experienced working with consultants, and has a stable and well-documented environment. I find it easy to convince clients that fixed price is not in their best interest by reminding them that price is only one element of a satisfactory outcome, and excessive focus on price can put us in the position of sacrificing quality, timeliness, and creativity. As Alan Weiss describes in his insightful column, it’s important for consultants to sell the value of their work and not merely the price.

Rick Freedman is the author of The IT Consultant: A Commonsense Framework for Managing the Client Relationship and the upcoming The Internet Consultant, both by Jossey Bass. He is the founder of Consulting Strategies, Inc., a training firm that advises and mentors IT professional services firms in fundamental IT project management and consulting skills.

Do you offer fixed pricing to your clients? Are there times when it’s appropriate, and other times when you shouldn’t? To share your opinion, post a comment below or send us a note.