In Part 1 (“what do I sell?”), we looked at what most service businesses sell, and why selling hours can be a bad idea. In Part 2 (“what do customers buy?”) we looked at why customers buy outcomes, not hours. In Part 3 (“what should I sell?”), we looked at why you should sell outcomes. Now, in Part 4, we’ll look at ways to mitigate risk for both parties.
The Outcome-Based Proposal & Risk Reduction
The big problem for outcome-based projects (or “fixed bid”, as they are more commonly called) is that while the fee is fixed, the scope may not be. How can you CYA, and also set the project up for success?
Timelines & Deadlines
First, when you deliver a outcome-based proposal, in addition to an outcome and a price, you need a timeline. This provides a boundary on how much you commit to do. In part this is because you have an end point, and also because the customer can only absorb so much so fast. The timeline provides a firm end date for the project, describes the final deliverable, and provides checkpoints along the way. (Weekly is best, IMHO, but use what works for you and your customers.)
If the project is “too big” or doesn’t have clearly defined deliverables, break it up into smaller chunks. A common first phase for me is “figure out what we should be doing with our pricing and give us your recommendations.” Even this is ambiguous, so I have to be careful to spell out the scope of what we can investigate when, and what the customer’s responsibilities are. In other words, don’t set out to do a big, uncertain project with a fixed bid. Do a small, somewhat uncertain project (the assessment). Then lay out the next phase. This will have the same impact on the customer’s budget and schedule as hourly billing, but it will be less paperwork for them to manage.
When you set the deadline, by realistic. Many entrepreneurs are driven and want to do things faster than most, sometimes faster than possible. This is great, but often companies don’t care. If you’ve just killed yourself to deliver what should be a two month project in one month, and then you see the customer sit on it for a month because they can’t actually do anything until the end of the quarter, you get pretty frustrated (so I’m told). Give yourself a bit of extra time. Things happen. Kids get sick. Customers don’t deliver data. Something doesn’t go as planned. The idea that you can truly and consistently devote 8-10-12 hours per day of productive time to the project is unrealistic. Better to have a little bit of room in the schedule. Sometimes even have time to go back and do something a little better, so you can be really proud of your work. You’ve built in enough money and time that you don’t resent the extra effort, you’re excited about it. And sometimes, particularly if you are waiting on input from the customer, you can actually work on something else in parallel, which is essential to escaping the feast and famine cycle of many service providers.
Remember that the customer often doesn’t know exactly what they are trying to buy, so you, as the domain expert can help them. This may mean doing several phases. If you go the doctor with a heart problem, you may need the doctor to figure out exactly what the problem is before trying to solve the problem. You can do the same thing with your clients.
Describing Deliverables
The biggest problem for fixed bid projects is defining deliverables. You might promise to deliver “a web-based CRM system with the following features…” The customer’s Japanese sales office might simply assume that the system will be localized with Japanese currency, language and more. When they see everything in USD and English, they can’t use the system and don’t sign off. Part of the assessment has to be figuring out what success really means for the customer– which often means multiple constituencies that may have different needs. You must define deliverables on your customer’s terms, not yours.
For example, instead of delivering a piece of software (“a web-based CRM system”), you may deliver software that “lets sales reps do X, Y, and Z, while integrated to systems P and Q.” Instead of delivering a “pricing training class, focused on value-based pricing”, the customer wants “to arm each sales rep with a system to present quotes leading with value instead of price, and to handle price objections.”
It’s just taking the deliverable up a level or two. What the customer is buying is not the exact service you’re selling. They are buying the reason they need that service. (See the previous parts.) No one wants to buy a training class. They are buying a training class because they want to make their sales efforts more effective. Your deliverable should provide a clear answer to the need.
It’s also helpful to explicitly define what you’re not delivering. Even if it seems obvious to both you and your client counterpart, there may be other people who assume that the CRM system will include Japanese. If you know that it won’t, say so. Anything you can explicitly exclude is good not only for you, but for the customer, as well. They will appreciate the clarity, and having a clear answer for their boss, when someone asks why Japanese isn’t available (“future phase”).
Of course, you can’t solve all needs at once. Your assessment only addresses an intermediate need. A prototype might demonstrate the feasibility of a concept, or allow executives to select a course of action. Stepping stones are good, not bad.
Brining It All Together
If you manage your timelines, deadlines, and deliverables carefully, you can avoid most of the risk of fixed-bid, or “outcome-based” projects. Will you occasionally have to take on more than you wanted? Yes, probably. In my experience, the average estimate is pretty good, but sometimes it’s over and sometimes it’s under. Overall, the results have been positive not just for me, but for customers. Everyone knows exactly what the goals are and I get to spend my time and effort working towards them, with minimal administrative overhead. Situations where we have gone back and done another iteration or added a feature, or otherwise done more work were more often driven by my desire to do things right than the customer asking. In some cases the customer may not have even noticed or cared, but I like to feel good about what I’m doing.
Remember, customers don’t buy hours (I’ll post a counterexample in a follow-up). They buy outcomes. If a group of trained monkeys could deliver the same results and get paid in bananas, you’d be out of a job. But if you can sell (and deliver) outcomes, you can do more satisfying work and make more money. So now when you put together your proposals, you can sell outcomes. Instead of 40 hours of earth moving, you sell beautiful new landscaping. Instead of 200 hours of software coding, you sell an integration to salesforce.com. If you can take it up a notch, you can sell 20% more selling time, not just an integration. What you sell should be as close as possible to what the customer is trying to buy– the real outcome that they care about– which increases your chances of winning, the meaning you create while delivering, and the value you can capture as a reward.