rss feed
developer: Oh that's not a problem. We have a very simple network protocol, so you can write your own client-side program for whatever operating system you happen to have.
customer: Oh yeah?
developer: Yup, it's easy. You just open a socket and send the data as...
customer: Uh, a socket?
developer: Yeah, you know, a TCP socket?
customer: Oh.. Well, I don't think we have those.
developer: !!!It finally came out that the customer was using a mainframe with an OS that simply didn't support sockets! Our sales guy had signed up this customer without giving even a cursory thought as to whether the customer could actually use our service. Now the burden was on our developers to either figure out some technical magic for a completely new platform very quickly, or risk making the customer very angry that they had given us money for a service we couldn't deliver on.Although this sort of disconnect between sales and software development is all too common in the software industry, it's not the only way to do business. There are basically three ways to sell consulting or some sort of service to a customer:1. Do all the specification and planning up front, with a fixed price tag for the development.
2. Skip the specification and planning up front, with an open-ended hourly price tag for the development.
3. Skip the specification and planning up front, with a fixed price tag for the development.The first option is the best from a developer's perspective, as long as they're actually in on the design and planning. Customers often like this option too, since they know exactly what they're getting and exactly how much they're paying for it. The idea is you sit down with the customer and hash out their requirements in great detail, whether that includes screen mockups of the application you're developing or simply details on all the platforms they need to support. After everything is written down and agreed upon, and only then, do you start coding.The problem with this approach is that although developers like it, and customers like it, many salespeople hate it. The job of the typical salesperson, especially one that operates on commissions, is to reduce the amount of time between initially contacting a potential customer and cashing a check from that customer. Any time spent between those two events is time that's not being spent also convincing other customers to empty their wallets. The highest volume salespeople in a commision-based environment operate by selling quickly. As soon as one customer's in the bag, they're on to the next.So salespeople often hate the first option above for two reasons. First, it increases the amount of time between the initial contact and the check cashing. If requirements gathering and specification take an additional three weeks, that's an extra three weeks before they see their commission bonus. That three weeks could be the difference between getting that customer on their January numbers instead of their February numbers.But perhaps more importantly, often the result of requirements gathering, specification, and planning is that you find out you simply can't meet the customer's needs, or that meeting the customer's needs will cost the customer a lot more than they had originally thought. It's in the specification and planning phase, if there is one, that little minor details come out like the customer's OS not supporting sockets. So by allowing developers to spec things out for several weeks before the deal is signed, the salesperson increases the chance of that deal evaporating and the customer walking away with their bulging wallet intact.The second option for consulting or selling a service is to skip the up-front specification phase, and charge an ongoing hourly rate for any development work. Salespeople like this option, because without spending time on specification and planning, they see their bonus check sooner and can move on to the next customer. Developers often don't mind this option too much, because even though they're working with zero specs, at least they can take as long as they need to figure out what the customer actually wants and develop it for them, billing them all the while. But as you can expect, customers usually can't stand not knowing how much they're going to end up paying for something, especially if they're a small company. Customers have this thing about wanting to know what price they're agreeing to before agreeing to it.The third and final option is to also to skip the specification phase, but then include a fixed price tag for the development work. And therein lies madness. Salespeople get the same benefit of getting the customer's cash sooner, and the customers are more likely to spring for it because it's got an actual price tag on it, but then the developers get royally screwed. Here's how: As soon as the sales guy hangs up the phone and does a little dance around the office to celebrate his victory, the clock starts ticking. The developers, starting with zero specs, have to figure out what the customer wants and build it in a very finite amount of time. Even worse, that finite amount of time wasn't determined after sitting down and figuring out how long the task will actually take. The development time is based on a number that the sales guy pulled out of his ass, hoping that it'd be equal to or slightly lower than the highest price the customer would be willing to pay.So then the developers have to squeeze in what little amount of design, planning, and implementation they can into that fixed-size window of time, and once the time's up, any additional development they do isn't being paid for by the customer. Suddenly, there's a whole lot of pressure to just polish the turd as well as they can, and ship the damn thing so they can move on to the next customer. As you can imagine, this approach isn't terribly conducive to producing quality software or services that customer's love.Unfortunately, this zero planning with a fixed price approach is one of the most common consulting models in the software industry. But if it ends up working so poorly for the developers and the customer, why exactly is it so common? Simple: Many software shops are run by salespeople. I've worked many places where the CEO is essentially the head of the sales department. And often the other salespeople are the CEO's buddies. So what you end up with is the sales team dictating what sort of consulting approach is going to be taken, and so naturally they choose the model that's most likely to make them sales: Zero time "wasted" on planning, and a fixed price tag to convince the customers to open their wallets.So the next time you're asked to port your program to a completely new platform after one of your sales guys has convinced a new customer to sign up, and you're told you only have eight hours in which to do it, you'll have a pretty good idea as to why.
blog - software consulting and the fixed-price contract
posted by witten on February 27, 2007
I once worked for a company with a pretty basic service-oriented business model. Customers downloaded a small client program that allowed them to connect to our servers via the internet, and we charged them for the privilege on a recurring basis.Our potential customer base used all sorts of operating systems, so we had ported our client program to just about all of them. After we'd gotten a new customer signed on, we'd send the client program to the customer's engineers, and quite often, they'd figure out how to get it up and running without any help from us. They'd start happily using our services, and we'd happily take some money off their hands every month.However, not all of our customers proved quite so self-sufficient. One day we got a call from a new customer that one of our sales guys had just signed up for service. Here's how the conversation went with one of our developers. (I got most of this second-hand.)customer: We just signed up for your service, but apparently your client program doesn't support our operating system.developer: Oh that's not a problem. We have a very simple network protocol, so you can write your own client-side program for whatever operating system you happen to have.
customer: Oh yeah?
developer: Yup, it's easy. You just open a socket and send the data as...
customer: Uh, a socket?
developer: Yeah, you know, a TCP socket?
customer: Oh.. Well, I don't think we have those.
developer: !!!It finally came out that the customer was using a mainframe with an OS that simply didn't support sockets! Our sales guy had signed up this customer without giving even a cursory thought as to whether the customer could actually use our service. Now the burden was on our developers to either figure out some technical magic for a completely new platform very quickly, or risk making the customer very angry that they had given us money for a service we couldn't deliver on.Although this sort of disconnect between sales and software development is all too common in the software industry, it's not the only way to do business. There are basically three ways to sell consulting or some sort of service to a customer:1. Do all the specification and planning up front, with a fixed price tag for the development.
2. Skip the specification and planning up front, with an open-ended hourly price tag for the development.
3. Skip the specification and planning up front, with a fixed price tag for the development.The first option is the best from a developer's perspective, as long as they're actually in on the design and planning. Customers often like this option too, since they know exactly what they're getting and exactly how much they're paying for it. The idea is you sit down with the customer and hash out their requirements in great detail, whether that includes screen mockups of the application you're developing or simply details on all the platforms they need to support. After everything is written down and agreed upon, and only then, do you start coding.The problem with this approach is that although developers like it, and customers like it, many salespeople hate it. The job of the typical salesperson, especially one that operates on commissions, is to reduce the amount of time between initially contacting a potential customer and cashing a check from that customer. Any time spent between those two events is time that's not being spent also convincing other customers to empty their wallets. The highest volume salespeople in a commision-based environment operate by selling quickly. As soon as one customer's in the bag, they're on to the next.So salespeople often hate the first option above for two reasons. First, it increases the amount of time between the initial contact and the check cashing. If requirements gathering and specification take an additional three weeks, that's an extra three weeks before they see their commission bonus. That three weeks could be the difference between getting that customer on their January numbers instead of their February numbers.But perhaps more importantly, often the result of requirements gathering, specification, and planning is that you find out you simply can't meet the customer's needs, or that meeting the customer's needs will cost the customer a lot more than they had originally thought. It's in the specification and planning phase, if there is one, that little minor details come out like the customer's OS not supporting sockets. So by allowing developers to spec things out for several weeks before the deal is signed, the salesperson increases the chance of that deal evaporating and the customer walking away with their bulging wallet intact.The second option for consulting or selling a service is to skip the up-front specification phase, and charge an ongoing hourly rate for any development work. Salespeople like this option, because without spending time on specification and planning, they see their bonus check sooner and can move on to the next customer. Developers often don't mind this option too much, because even though they're working with zero specs, at least they can take as long as they need to figure out what the customer actually wants and develop it for them, billing them all the while. But as you can expect, customers usually can't stand not knowing how much they're going to end up paying for something, especially if they're a small company. Customers have this thing about wanting to know what price they're agreeing to before agreeing to it.The third and final option is to also to skip the specification phase, but then include a fixed price tag for the development work. And therein lies madness. Salespeople get the same benefit of getting the customer's cash sooner, and the customers are more likely to spring for it because it's got an actual price tag on it, but then the developers get royally screwed. Here's how: As soon as the sales guy hangs up the phone and does a little dance around the office to celebrate his victory, the clock starts ticking. The developers, starting with zero specs, have to figure out what the customer wants and build it in a very finite amount of time. Even worse, that finite amount of time wasn't determined after sitting down and figuring out how long the task will actually take. The development time is based on a number that the sales guy pulled out of his ass, hoping that it'd be equal to or slightly lower than the highest price the customer would be willing to pay.So then the developers have to squeeze in what little amount of design, planning, and implementation they can into that fixed-size window of time, and once the time's up, any additional development they do isn't being paid for by the customer. Suddenly, there's a whole lot of pressure to just polish the turd as well as they can, and ship the damn thing so they can move on to the next customer. As you can imagine, this approach isn't terribly conducive to producing quality software or services that customer's love.Unfortunately, this zero planning with a fixed price approach is one of the most common consulting models in the software industry. But if it ends up working so poorly for the developers and the customer, why exactly is it so common? Simple: Many software shops are run by salespeople. I've worked many places where the CEO is essentially the head of the sales department. And often the other salespeople are the CEO's buddies. So what you end up with is the sales team dictating what sort of consulting approach is going to be taken, and so naturally they choose the model that's most likely to make them sales: Zero time "wasted" on planning, and a fixed price tag to convince the customers to open their wallets.So the next time you're asked to port your program to a completely new platform after one of your sales guys has convinced a new customer to sign up, and you're told you only have eight hours in which to do it, you'll have a pretty good idea as to why.