Fixed Price - Good or Bad?
Scott Ambler’s article on the consequences of fixed-price IT projects gives some good coverage of the high level issues with fixed price (or fixed bid, if you prefer) projects. I wholeheartedly agree with what he’s saying in principle, but what about in practice?
The comments below the article certainly have some resonance :
So, I’m meeting with a guy who runs a small chain of sporting goods stores. His cousin threw together a site for $5k but he needs more complex commerce features and integration with MAS90. He’s got three fixed bids ranging $25-$45k for the very loosely specified project.
He doesn’t have an IT manager (the receptionist can figure out installing outlook), he has an hour for the meeting, and no interest in learning about the business of software development. So, how exactly do I convey the benefits he’ll get from not knowing what he’ll get for his $25k, and given we’ve not worked together, how do I convey he can trust me that the hours I bill are the time I’m spending. He wants to know what features he’ll get (as that drives his return) and what it’ll cost (as that affects his expenditures.
So, what do I say and still get the project (given that 85% of my target audience fit into this general category). Ideas appreciated!
Of course, he get’s no direct help other than support that his situation isn’t unique :
…that’s spot on. I have yet to read anything from the agile community that squares agile practices with the reality of fixed price contracts. Customers simply aren’t interested in time & materials contracts (and neither should they be - why would anyone expect the customer to happily take on all of the risks of someone else’s software development effort?!?).
And herein lies the problem; as an industry we’re a bunch of untrustworthy mongrels, only out to make a quick buck by selling the next silver bullet solution. Consider the damage done to our reputation by the dot-Com boom and bust, where gazillions of dollars were given to spotty kids and slimey sales/marketing guys, only to deliver a few web pages that didn’t increase businesses revenues / profits or deliver real business benefit.
My perspective on this is one where I’m paid to make money for my company by delivering software solutions for clients. Because it’s perceived that we can’t be trusted and will rip off our customers we need to be constrained, hence the fixed price. Of course though, all that does is ensure that businesses control their initial financial expenditure; it doesn’t ensure they’ll realise the desired business benefit that the system should deliver. Decisions start to be made differently. No longer are you driven to purely help the business; you’re driven to minimise commercial exposure whilst ticking the necessary requirements boxes… and personally, I find that really uncomfortable and unethical. The businesses (i.e. clients) are just as bad though, they become driven to ensure that they make their supplier deliver what they’re supposed to… “it doesn’t matter if a feature isn’t required anymore, make them deliver it, because we’ve paid for it.“. What a farce!
The delivery of software projects under the cloud of fixed price isn’t as bleak as Scott makes out though; we battle hard against the pressures of BRUF and BDUF because they are key aspects that are likely to ensure failure. By avoiding BRUD and BDUF, even though it may provide some additional commericial exposure through feature creep, it means you’re delivering more closely to what the businesses want; the problem is when you do this under a fixed price scenario you’re showing weakness and some businesses will exploit this to their own ends.
The key is to ensure that you follow some of the really good practices, such as constantly delivering an executable solution, prioritisation of features and requirements so that, as you find new features, you trade them off against features that are not really required anymore or are a lower priority and work iteratively towards the solution. By doing this you will enable yourself to deliver something that is closer to the solution the business really wants within the constraints of the fixed price deal, without clobbering the clients with too many costly changes. If done carefully, by proper negotiation to ensure you’re trading features and not merely giving them away, you’ll demonstrate that as a supplier you can be trusted to deliver and maybe next time your client may allow a more flexible contract. Is this Agile? No, but it’s probably as good as you can get given the constraints.
In essence there has to be a solution that ensures IT and businesses can work together collaboratively, without one trying to ‘get one over the other‘. We, as an industry, need to begin to slow the pace of change, ensure that we build on good engineering principles and consistently deliver. Businesses must appreciate that below the thin veneer of sales and marketing, the software development community really does strive to deliver business value to our clients… enforcing fixed price on us merely helps prevent us from doing it.