Insane Programming

My CSM (Certified ScrumMaster) trainer is probably going to kill me after reading this title, as one of the things she kept repeating during the CSM course was that you don’t sell Scrum, and as such, pricing strategies . You sell a product to a client, and Scrum is a means to an end to get that product to that client in the most efficient way possible for all parties involved. Scrum focuses on content, early delivery and providing as much value as fast as possible. It also factors in the certainty of change.

However, this doesn’t go well with traditional pricing strategies for software product as they are sold most of the time nowadays, which is fixed pricing for a fixed scope. Personally, I can count the fixed price projects I’ve seen that haven’t gone over-budget on one hand (come to think of it, a single finger will do). And it’s not really a surprise, if you take a step back: fixed price projects are inherently wrong for software projects. Fixed price can be done for a manufacturing process, in which there is a clear blueprint, a set of predefined resources to be used optimally and where there is no deviation whatsoever during the process. Software development is nothing like that! It’s a flexible process (in spite of what users think, there is a huge difference between what they think they want, what they actually need) with resources that are defined during the process and where deviation of the original idea (blueprint, if you will) is a daily reality.

The consequences are a sad reality: most fixed price projects factor in the possibility of these changes through either a arbitrary multiplier to the price of the project when it would go as planned (pi is a popular multiplier) or by tightening the process in such a way that each and every deviation is quite costly (most of us know this as signed change requests). As a client, either way you’re screwed. You’re either paying more than you should up front or you’re setting yourself up for a Chinese water torture. In the end, the net result is always the same: the project costs a lot more and chances are, because of the tension these kind of projects create, you’ll end up with a project which isn’t entirely the thing you had hoped for.
So why is the entire industry so focused on fixed price projects? Well, time and material, the alternative which is very flexible, worked but proved to become extremely expensive. The reason for this is the fact that time slips in software projects are a reality and in time and material project time slips are very costly. This made some projects spin out of control and almost the entire industry abandoned time and material for the more safer, yet very naive, fixed price projects.

So is there an alternative? Well, this weekend, based on some pricing strategies used in Scrum articles, I may have found one.

Scrum focuses less on time than it does on content. Hell, Scrum projects aren’t even calculated in man-hours, but in points (and no, there is no direct correlation between points and hours, you need to exactly know the velocity of your team in advance in order to make that conversion)! So let’s split up the pricing into the time and content, making time a whole lot cheaper than content. Let’s do a (simple) example: you have a project of 200 points and a team of 2 developers (each costing $35 an hour) which are assumed to be able to do 20 point 2-week sprints (in other words, a 20 point velocity team).

Traditional pricing would calculate that the project would take 1600 man-hours, which are billed at $75 per hour. Total price of the project would then be $120,000 with a profit of $64,000 if everything goes as planned. If the project without scope changes takes 50% longer than planned, the profit plummets to $36,000. If it takes more than 2 times as long, you’re looking at a loss. The reason for this is that it is a fixed price for a fixed scope, where time is money.

Now let’s try an alternate approach. Say you’re dropping your hourly rate under the basic cost of your developers ($25), but you’re additionally asking $380 per delivered point. Hours are billed as they are performed. You also introduce penalties and bonuses, 10% less if delivered late, 10% more if delivered early. If the project takes as long as planned, the cost for the client would be $116,000 at a profit of $60,000. However, should the project take 20% longer, the client would pay $111,600 with a profit of $44,400. If it takes 50% longer (which in a Scrum project means you or the client doing something seriously wrong), the client would pay $122,400, while you’re still making a profit of $38,400. Off course, this also goes the other way around. If the project is delivered 20% faster than predicted, the client would pay $118,800, resulting in a $74,000 profit for you.

This creates some interesting dynamics. Even if a project is delivered late, it’s still cheaper than a fixed price project for the client and as a provider you’re still able to make a nice profit. It also makes schedule slips less of a problem, as time is cheap. In the end, it’s the delivered value that matters and that’s exactly the thing the client will be paying for and wants to pay for. It forces the client to think about what he really wants, as functionality (points) is expensive and not to fixate too much on the schedule, which at best at the time of an offering is a estimate. Off course you can say that the time-based invoicing should then be dropped altogether, but that creates a dangerous situation: time doesn’t matter anymore. You could deliver a project 2 weeks late, or 2 years late, it wouldn’t matter to the client. You’ll be invoicing the same amount, with a steeper decrease of your profit over time as a consequence. Any smart client realizing this would order fine tuning within the bounds of the project scope until the provider eventually had enough. Time should always be something to consider, but it shouldn’t weigh as much as the demanded value. It should be large enough to make sure slips over 2 times the time needed become expensive for the client so that he doesn’t asks for too much cosmetics and fine tuning, but small enough for the client to accept some time slips when they happen. You can play with the ratio between time and value, but you’ll see that that the cheaper time becomes, the more profitable it becomes compared to traditional pricing when you’re able to deliver somewhat faster than predicted. It’s also vastly more profitable if your project takes way more time than predicted, but normally, this shouldn’t happen. But again, if it does, it’s not that big a deal, because time is cheap. Overall, you need to make sure that the point component of your pricing is always larger than your time component.

It also makes for some nice customization: you could vary the price of the time component as the project progresses. For example a linear evolution from -30% to +30% during the entire project life cycle. This makes time in the beginning of the project, where there’s a lot of uncertainty, the most important things should be delivered and slips are more likely, an even cheaper thing. This is off course compensated at the end of the project (doing a lot of tinkering, cosmetics and fine tuning) where the price is higher. Off course, it’s also a nice incentive for the client to step into this pricing system.

Well, that’s it. Looking back at it, it’s some sort of a fixed price, time and material hybrid. It’s an idea, mostly based on some articles I’ve read. Feel free to comment and share your thoughts!