Agile and Fixed Price?
First, let’s pin down what “fixed price” actually means. It’s not just that the customer demands to know as precisely as possible how much they will have to pay for the project (which, on the surface, is not an unreasonable request).
First, let’s pin down what “fixed bid” or “fixed price” actually means.
It’s not just that the customer demands to know as precisely as possible how much they will have to pay for the project (which, on the surface, is not an unreasonable request). Usually, the customer will also want to fix what it is that they are going to get - the scope. Often, the customer is interested in getting the deliverable by a certain date, thereby fixing the time as well. In reality, therefore, it often makes sense to speak of “fixed iron triangle” projects.
On the surface there is nothing unreasonable about wanting things done this way. We all act like this when we want our kitchen remodeled, for example. So, why isn’t this approach working very well on software projects? As a recent study conducted by McKinsey and the BT Centre for Major Programme Management at the University of Oxford of more than 5,400 IT projects demonstrates, software projects (especially large ones) on average run 66 percent over budget and 33 percent over schedule. In reality, fixed-price contracts hardly “fix” project costs or schedules.
Scott Ambler analyzes in detail both why customers demand fixed price and why fixed-price contracts tend to set projects up for failure. One reason is that the software profession as a whole is not exceptionally good with estimations, making the predictability of a fixed price project an unattainable illusion. Also, as Martin Fowler points out, fixed scope is really not so fixed in most cases, as requirements tend to change over time, plus there is always a discrepancy between how the requirements are understood by the business and by the developers. Moreover, being held to a fixed estimate motivates IT providers to adopt strict change management policies, reducing customer motivation to change their defined requirements, even if their requirements have in fact changed. Thus, as Scott Ambler argues, the ethics of fixed price projects are questionable because they essentially motivate customers to pay for functionality they really don’t want.
Another problem is that when a project is slipping and pressure is put on developers to still deliver on time and on budget, they begin to cut corners, and quality is the first victim. As Ken Schwaber continually observes in many of his books, articles, and talks, customers often don’t want to hear the harsh truth (e.g. that the deadline is not going to be met), and developers are afraid to tell them: “The [customers] want to believe in magic, and the developers support the belief by lying. ‘Can you do this project by this date?’ ‘Sure, no problem.’”
The consequences of disrespecting the iron triangle are always dire. One way agile may help bring the desired transparency in terms of project costs is by replacing “fixed price” with “fixed budget”. Your financial outlays are capped, and the deadline may be fixed, but you get to vary the scope and make changes to the requirements based on the reality of how the project is actually going. Some agile companies offer customers the opportunity to introduce new requirements on the fly but at the cost of giving up blocks of outstanding lower value functionality.
What is your experience with fixed price, fixed budget, and agile?
This post originally appeared on TechWell.
Need more details?
Fill in the form and we’ll contact you as soon as possible.
David Tedford has over 20 years of sales experience within the IT/software industry. He excels at sales, business development, channel development, sales cycle management, negotiations, and sales team management.
Senior Vice President
As the head of business development for First Line Software, Vladimir heads up business development in Western Europe and Russia.
Vladimir began his career in IT in 2002, when, as a student of Faculty of Automation of Computer Science of the First Electrotechnical University (ETU “LETI”), he began his work at The Morfizpribor Central Research Institute (CRI). Vladimir joined the StarSoft team (predecessor of First Line Software) in 2004 as a Junior Software Developer. As he gained experience with more and more projects, he was promoted to leadership roles.
The Hague, Netherlands
Praha, Czech Republic
UK Business Development
Richard has over 15 years of sales and account management expertise in the IT and Tech sector. He has worked on many outsourcing engagements with global companies.
Gloucestershire, United Kingdom
David is a business development professional with more than 20 years’ experience as a specialist in the acquisition of partnerships and IT/software services for associations, not-for profits and corporations in Australia, New Zealand and USA. He has specific expertise in the healthcare, legal and hospitality industries.