Fixed Price Pricing Model: Failed Expectations
Within 15 years we’d been working in software development we had tons of projects with different sizes, application fields, technologies and business models. Notable part of them were Fixed Price.
It’s a wide known secret that software developers are not happy with this business model. It brings heavy management overhead and exposes severe risk of negative profit due to efforts underestimation. Still our clients love it so much, that it would be wiser to master Fixed Price rather than refuse it at all. That’s the way we did it - built internal processes, defined artifacts and activities, trained project managers and developers. Everything to make FP projects run smoothly and finish successfully. Did it help? Yes. To some extent. And this extent is not that big as we expected. FP projects still fail. Fail by very different external reasons, but quite similar internal rootings. Fail due to false business expectations our client have about Fixed Price. In this article we’ll go through typical clients’ considerations about business model choice and make corrections to the expectations.
We need Fixed Price because we have limited budget and want to be sure that we will fit in it.
It may sound a bit strange, but Fixed Price does not guarantee that the budget agreed at the start will remain unchanged till the end of the project. Why is it so? Because of the changes to the original scope of work.
You can be absolutely sure that each particular change will be added to the bill. You want this button to be blue instead of green - that’s a change. You want to log in with Google+ in addition to Facebook? That’s definitely the change. No matter of size or complexity every change will make the price to grow.
Can’t you just add some buffer for those changes, let’s say 10% or even 20%?
Of course we will. There are internal risk specific to Fixed Priced projects and we will definitely cover them by buffers. But we can never know in advance how many changes you would want.
Let’s look into the statistics.
This chart shows the budget deviation in hours occurred on 100 FP project. From this chart we can say that you have a good chance to fit in 20% buffer. But it’s only a chance. You know exactly that throwing 6 on standard dice has probability of ⅙. But would you commit that you will get it in 6 trials?
Heil to the brave!
OK. But we can define everything in advance with all necessary details, so there won’t be many changes beside small tweaks.
It’s great if you come to us prepared. It clearly shows the strength of your intention and serious approach to the business. But it won’t protect your project from changes no matter how focused you are on keeping the original scope. In fact, scope shouldn’t be protected, it should be managed. Changes are very natural for the software development. There are a lot of external actors who influences the project and generates changes - users, competitors, 3rd party systems etc. Apple announced new OS version? Competitors implemented modern technology? Users require new feature? Social network changed API? Say ‘Hello’ to the changes. And success of your project depends more on your ability to adopt those changes rather than reject them.
We have planned our budget considering changes. Change requests processing will be fluent. (Oh, really?) But at least budget will be spent in a more controlled manner. Developers won’t drink coffee instead of programming, because Fixed Price put a pressure on them. We’ll get our project done faster.
Hey, coffee is already in your bill. No joke. It’s an integral part of the development process.
Actually there are 2 misleading concepts.
First, we are doing business as well as you do. Faster we get the job done, faster we get the money and release resources to do a new job. Therefore our schedule performance doesn’t depend on business model chosen. In fact, sometimes we are even more focused on schedule than our clients.
Second, choosing Fixed Price as a business model you put additional organizational overhead to your budget and schedule. Let’s take a look to a simplified example.
Imagine you requested an application with 2 features. Each one is estimated as 240 hrs of work. We provide you with 2 developers to do the job. Normally you would think that it should be done in 6 weeks for the price of 480 hrs
But with Fixed Price it would be a bit different.
Fixed Price projects are typically divided into several phases with duration about 4 weeks each. At the end of the phase we run transition procedure: formal acceptance, invoicing, SoW for the new phase signing. All these organizational activities take some time. Usually we plan a week for it and you would be surprised to know how often it lasts longer. For this period team engagement falls very low, but we can’t dismiss it because of the new phase coming. Sure you understand who will pay for those idle hours.
As a result you will get your project done later and at higher cost. Note, that in real-life projects all those organizational overheads intrinsic for Fixed Price projects will be even more intensive. Do you still want it?
We are not sure.. Even with all those things mentioned above it still seems that control over the budget is better with Fixed Price.
We provide merely similar budget visibility on Fixed Price and Time&Material projects. You get same tracking for tasks and hours spent. Same reports and estimations. Main difference is that on FP projects we actually limit your control to protect our business from possible damage. You have urgent need for a feature to present to investors? No, no, no. Let’s write down requirements and formally approve hours for it. Your CFO is on vacation and can’t approve payment? No problem! We’ll hold team idle even if your schedule under pressure. What a fruitful soil for disputes and conflicts!
Hell! Does this FP work at all?
Though we consider FP to be the worst possible model for software development, there are still cases where it’s applicable. FP can work in the fields where formality is a cornerstone - healthcare, military, law. It can work for very well-defined system having external limitations on possible changes - low level hardware, security application.
Ha-ha! We know all those consideration. Just wanted to get more work done for less money!
Good luck! ;)