AGILE IN ACTION

A short while ago I said that fixed-price contracts don't work . Over on the Scrum Development group there's a discussion about competitiveness, estimates and organization culture . Dave Martin said: People underbid because it gets them the initial contract as many clients will just go for the lowest bid. Once the project is underway, the costs start to escalate and the client has 2 options - pay up or write the project off and start again. The client is often better off writing off their initial investment and starting over but its amazing how often they don't do that and continue to burn money. Keith Sterling responded: This is why so many large consultancies stick to the waterfall method. By bidding low and stipulating a waterfall approach, yet knowing that 99.99% of all projects will undergo 25-35% change during its lifetime, they know they will be able to make up the shortfall in their bid with high value change requests. It's a well known fact, yet unwritten rule that most large consultancies in the UK base their business model on the volume of change requests they can generate during a project, and why most of these organisations have some of the biggest legal departments I have ever seen. Where is the sense in awarding business based solely on the price? Price is meaningless without a measure of the quality being purchased. If clients award business to the lowest bidder they're likely to receive low quality and high cost. You get what you pay for. And the client-vendor relationship will become acrimonious as neither party is satisified and it falls to the lawyers to fight it out. Deming predicated that driving down the price without regard to quality and service will drive good vendors and good service out of business . He was right but it's actually worse. As Keith describes, we now see companies making money from providing poor quality by charging extortionate sums for change requests. It's part of their business models. What a truly sad state of affairs. Wouldn't it be better to enter into and nurture cooperative partnerships for the long-term that are built on mutual loyalty, trust and confidence, and which share the risks and the rewards? If you treat your partners as extensions to your business and align incentives so that everybody works for the good of the partnership, then quality will return, cost will fall, speed of delivery will increase, customers will be happy and everyone will realise prosperity.

When you buy something, you want to know exactly what you'll get and how much it will cost. It makes sense. But this doesn't work when you're buying software development. If only it did. Writing software is a creative process and developing software systems is a complex undertaking. If you think it's possible to identify a single date, somewhere off in the future, upon which you'll receive everything you've requested and for a fixed price, then you're setting yourself up for failure and disappointment. To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can't define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn't be an estimate if it was). Let's be honest here. You're unlikely to know exactly what you want because visualisation only goes so far. You'll probably only know what you want when you actually get to play with it. It's only when you experience using a fully functional user interface, with working code beneath it, will you appreciate its usability and decide if it works for you and meets your needs. Now, maybe you can spend an inordinate amount of time eliciting requirements, analysing them and producing a specification, and possibly get close enough to what you really want. But you're still not going to eliminate uncertainty as the project progresses because when people read your specification they'll take away their own interpretation of what you want. If it were my money I'd want to spend it on working software that realises my needs incrementally and helps maintain my competitiveness and not on documentation. A change management process is a good way to ensure your product is built to specification. And your vendor will support this because, since you've beaten him down on price and then fixed it, he'll want to make money on the change requests. This motivates you to cram even more requirements into the specification (even if you don't really need them) just to cover all the options and hopefully minimise any changes down the road and avoid further expense. It rarely works out that way though. Change is still inevitable. A change management process just makes it more difficult to make changes, and consequently you're even less likely to get what you really want. Ironically, the cost of change requests is often responsible for forcing a project over budget. This defeats the purpose of fixing the price in the first place. You can fix dates (although it's not always necessary to do so). And there's always a budget. But when you fix scope too quality inevitably gets compromised. That's bad. Why would you compromise the quality of a corporate asset? You should never compromise on quality. If you acknowledge that you don't know exactly what you want, wouldn't it make more sense to vary the scope? Don't base the contract with your vendor on conformance to a detailed requirements specification. If you do, you're saying all your good ideas happen at the start of a project and you're effectively betting all your money on a hole-in-one. Insist your vendor use an iterative approach to software development so that changes can be accommodated at any time during the project. And have the contract focus on the relationship with the vendor, not on the desired results of the relationship. By that I mean base the contract on incremental delivery of functionality and specify functional goals, not specific functionality. This allows you to evolve the details of the required functionality as the project progresses. Prioritise the functionality by business value and have the vendor work on it in that order. Work continuously with your vendor. Frequently inspect what's been built, provide feedback that steers their effort towards what you really want and and pay per iteration. The Agile Manifesto says: Value customer collaboration over contract negotiation . Enter into and nurture a collaborative partnership with your vendor, which is built around common goals, and shares the risks and rewards. Reference: The consequences of fixed-price IT projects by Scott Ambler.