The fixed price conundrum

The following is a reflection over delivering complex software in a changing world under a fixed price waterfall regime. I've come to the realization that in such a setup, there will always be a winner and a loser and the conundrum that, while you may win the contract, you may also lose your livelihood!

In software, as in other industries, we’re often faced with the difficult task of providing a binding price up front of the total cost of delivery, known simply as a fixed price contract. Customers love fixed price contracts, because it means they think they can plan long term with high degree of certainty with the added bonus of being able to play contractors up against one another in an effort to drive down the price. As such, it’s easy to see why this is a desirable approach to anyone wanting a problem solved in the most economical way - you really can’t fault the customer who’s tempted to think this way.

The problem is, however, that software is such an intangible thing full of assumptions, unknowns, traps and pitfalls. While we in the industry learn, to some degree, to expect the unknown, even with many years of experience, we will always be too optimistic and forget the many moving parts even the customer is likely unaware of. An iceberg is often used as an illustration within software engineering, and it would seem appropriate here as well. It’s not until you do a deep dive into the water it becomes clear what exactly it is you are dealing with.

This is not necessarily a problem by itself, after all, I have no idea what goes on under the hood of my car and I would also have no clue as to the work involved in putting a car together - this is where I have to choose to rely on my mechanic.

Too much detail up-front

The thing is though, I never ask my mechanic to build me an entirely new car from scratch - and this is essentially what we are often asked to do within the software industry. Yes we will use pre-fabricated components such as wheels, transmission, power-steering, suspension etc. but the unique wiring together means we never develop the same thing twice and is always faced with a new untested vehicle. It takes many millions of dollars to come out with a new car because of the complexities involved, op top of the functional and non-functional requirements. In other words, it would be a bad idea to go to even the most skilled mechanic, order him to build a car from spare parts and ask him to do it as cheap as possible. I would not ride in that car and I recon dear reader, that neither would you?

In order to truly construct a car from scratch successfully to your needs, you would need analysis and specification in excruciating detail - essentially you would have to spend more time on this than the actual building it in the first place. On top of that, you would have to hope that your skills as a mechanical, structural and electrical engineer are just as stellar as you ability to keep up with technological and regulatory changes happening while you are busy writing down all of these requirements. Bottom line, you clearly can’t analyze, specify and design everything up-front - those who try will fail. There is such a thing as too much detail - at some point the overhead becomes too great for a successful delivery and the whole idea of one final delivery becomes a theatre void of practical matters.

Of course, most people simply purchase a commercial off-the-shelf car, tweaking only a subset of options made available from the car manufacturer - but swap the car out with a 5’th generation F-35 fighter jet built by top CMMI 5 contractors like Lockheed Martin, Northrop Grumman, BAE Systems etc. and remember they are more than $200 billion over budget - and you can hopefully see the relevance of my point; that it doesn’t matter how good you are at what you do, no one can predict the future, foresee all complexities nor their consequences.

Too little detail up-front

I have already used two metaphors in the above. Allow me to bring in a third one, one that I have never personally met but that I thought of because me dad is within the catering business. Imagine the following: A customer calls a caterer to get a quote for a birthday dinner. The customer is not particular specific and in a hurry, so the caterer only gets told generic info such as to expect about 2 dozen people and to deliver a mid-range birthday-dinner for a given budget. The caterer accepts the job and based on past experience he has already outlined some ideas in his head of how to deliver sufficient quality within the budget and constraints - while still being able to earn a living for himself.

At the day of the birthday dinner, it turns out that the people are from a retirement home so not people with the greatest appetites. The two dozen became 20 since one died and some fell sick. Being senior citizens, half of them have fake teeth so have trouble chewing hard food. 5 of them don’t eat pork for religious reasons. 4 have diabetes so for health reasons prefers to stay away from the dessert. 3 of them are practicing vegetarians for ethical reasons so don’t eat meat. 2 are lactose intolerant so won’t touch milk products, 1 is allergic to nuts and another is allergic to fish. Needless to say, there is way too much food and the dining crowd is not truly happy with the the menu.

What went wrong here is too little information up-front and wrong assumptions applied. In order for the chef to truly come up with a suitable dinner composition, he would need to know about these age related, dietary, religious and medical concerns. So clearly there is also such a thing as a minimum of detail required for successful outcome.

Something has to give

While somewhat contrived, the two examples above serve to showcase the two extremes between too little and too much detail. Both scenarios can be attributed to a waterfall approach rather than a more agile mindset, where feedback is a continuous thing and where final delivery is entirely up to when the customer sees his problems solved to a satisfactory degree. This plays nicely into another view I have, that the software lifecycle is only complete when there are no users left!

When challenges arise within a project, something obviously has to give. The agile perspective teaches us that scope prioritization driven by business-value is the best way forward and the infamous project triangle teaches us how we can have development speed, cheap price or high quality - but never more than two of these at the same time. Period!

So this is where the trouble starts to unfold for the, by definition non-flexible, fixed price contract. If customer and contractor are bound by such a contract; neither scope, deadline nor price is readily subject to change!

The customer will typically refer back to the contract forcing the contractor to spend his own time/money, and likely also deliver subpar quality. To protect against the latter, some tenders I have worked under contained a clause for mandatory minimal SIG scores in order to qualify the quality of the software delivery (which of course becomes subject to gaming, but that is a story for another day).

The contractor may potentially go bankrupt leaving the customer to try to pick up the mess and seek out another supplier who can take over, hoping the previous contractor left documentation and escrow keys around. For this reason, it's not uncommon for a tender to contain insurance stipulations about the size of a contractors wallet to guard against this outcome - as if being good at making software is somehow related to being good at making money.

So when the shit hits the ceiling, the contractor has no other choice but to try making up for the losses in changes or long-term support contracts, there simply is no easy escape hatch to cut losses and part ways without someone loosing!

As if that isn't bad enough, no sane developer will thrive delivering inferior quality for very long or work permanent overtime, so this is usually also a very effective way of sending your best developers away given that these can get good paying jobs everywhere.

Who’s the winner here? No one… except perhaps lawyers and other non-productive elements of the corporate undertaker world.

The right amount of info at the right time

I realize some projects are just bound by tender constraints so it’s not always possible to avoid fixed price contracts. However, I consider it nothing less than gambling and refuse this modus operandi when I do consultancy myself. The downside of this is that I may not make a lucrative profit on an easy delivery by giving an expensive price, but on the upside, I also don’t run the risk of being tied down to some idealistic and unrealistic illusion in the customers head. What's even better, it turns out, when you have demonstrated being able to deliver and have earned the trust of a customer, they will actually come back to you for more automatically! So over the long run, you're better off simply charging an hourly rate for your work. Good business relations is thus more reminiscent of a marathon rather than a sprint.

Of course this doesn’t mean there is no work or negotiation involved in keeping the customers expectations in line, but I find that this can be mitigated by being transparent and documenting challenges along the way. Ending each meeting with having the customer prioritizing the next handfull of features to be worked on is also an excellent way to moderate and impose a WIP limit so expectations for the next delivery becomes realistic and achievable. This is essentially the stop starting, start finishing mantra of lean and agile.

I’m not going to lie, as a software craftsman, it hurts inside when the customer looks indirectly at the project triangle and for the next iteration decides to sacrifice quality or go for a cheap solution. However, he is the one paying and you have to remind yourself that he will most likely come back to you if he later regrets and wants it rectified. Classic examples here are internal refactoring or maintenance of test-suites - especially if the customer is foreign to, or just immature when it comes to software engineering. Occasionally I will take a hit here and not bill if I deem it too complex or troublesome to explain, but it remains a rare occurrence - most people actually wants you to build the thing right if budget allows.

It also hurts when having to give estimates - a notorious difficult and risky craft. However, the same thing about transparency as before applies; break stuff down into digestable bundles (features, stories, tasks) and don't be afraid to slice both vertically and horizontally (I'm a bit fan of user-story mapping) and outline challenges and risks - and use this to drive the estimate and project. I often end up with presenting multiple solutions to a problem as options on top of one another. Not only will this provide me with a means of delivering a piece of functional software faster, but often it also becomes obvious to the customer that the fancy complex feature he though he needed is no longer really a necessity. I have even used this to my advantage, since often the best solutions are also the simplest and thus cheapest. In other words, as much as I hate to admit it, estimates can actually help in building the right thing.

So to summarize, if the customer believes an iceberg is only the visible part over the waterline - no problem, let him gradually become aware of the truth as you journey into the project together. This is the only way to ensure that everybody wins - customer, contractor as well as end-user. Most importantly however for you and your livelihood, you won't ever become the looser of this gambling game.

The usual disclaimer applies here, the above does not necessarily reflect the views of my employers but of me as an individual.