The real cost of fixing price

We operate in an economic, wealth-maximising world, and cost is an important factor when a company is looking to purchase an IT solution. A buyer will probably want to know what they are going to get, and by when… but they will almost always want to know how much it will cost.

It’s still standard practice to try to fix a price for a solution when engaging a development team or company, before work has started. There are some understandable reasons for this approach-

• To reduce financial risk. By agreeing a set price, financial outlay is capped and risk is moved to the supplier.
• For accounting and planning reasons, for example to support budgeting.
• To influence the supplier to design, estimate and plan in detail up front, on the assumption that this will mean the solution is ‘well thought through’.
• To conform with policies. Some organisations (particularly public sector) have a defined purchasing process that insists a fixed-price approach must be followed.
• To choose the ‘best’ available option with the highest ROI. Typically this is where a purchasing process will compare numerous vendors, and this has the secondary effect of driving competitive pricing.
• Where the purchasing/procurement process is driven by traditional thinking – for 30 years software engineering theory has been based on formally estimating work up front. The industry itself has influenced buying behaviour.

So why is fixing the price such a bad thing to do?

Because fixing the price typically leads to fixing the scope. These two constraints have then to be managed by the team developing the solution, which drives behaviour contra to principles of creativity and innovation. To give a fixed price, the team must estimate the work to be done, and this means designing the solution to a good level of detail through an architecture and design process. Broadly speaking, there are two approaches for a supplier in this situation – either to estimate using analogy or expert opinion (‘guesstimates’) and add a percentage of contingency to account for the risk, and/or design the system and attempt to work out how it will be built in detail, and put this detail into the specification as part of the contracted deliverables. Even if the spec doesn’t find its way into the contract, expectations will still be set as to what can be delivered for the price.

These specifications will be based on the current understanding of what the client thinks they want, which may be incomplete and may not take into account the real wants and needs of the users, the business problems, and the possibilities presented by technology in solving them.

The problems with written specifications.

• The articulation of solution architecture and design in a written document can only ever be – at best – an incomplete picture of created ideas; writing it is one abstraction, reading it is another; therefore assumptions are made and expectations set.
• Requirements can (and will) change over time – this is particularly true for larger more complex solutions that take many months to deliver. So the larger and more complex the solution, the less likely you are to agree a specification that won’t need to change.
  *
  Designs and technical specifications often can’t be interpreted by management and end users.
• It is impossible to predict the future – there may be unforeseen technical issues, and the people you plan (in your estimates) to do the work may not be available.
• It assumes all the good ideas will have been accounted for before work has even begun.
• Design documentation can be interpreted in a number of ways (or not read at all until things start to go wrong).

Once the scope and price is fixed, the supplier is then forced to manage them as the project progresses. Not only is change management itself an overhead, but any changes will require all the requirements, design and specification documentation to be revisited, and any code will need to be refactored/retrofitted into a part-developed system.

When problems do occur, schedules become challenged and a supplier has no choice but to manage cost ever more tightly by adjusting resources and complexity which can result in lower quality output, inflexibility in accommodating change, a reduction in functional complexity, and a blinkered focus on delivering a solution according to the word of the specification; whether or not it’s what the client really needs.

The development team, working within imposed constraints, are likely to be subject to carrot and stick methods to ‘get it done’, will eventually become demotivated, undermining any intrinsic motivation that would otherwise have brought creativity and innovation to the solution.

Therefore the real cost of fixing the price is a high risk of delivering the wrong or incomplete solution that doesn’t meet expectations or end-user needs, and completely bypassing any opportunity to introduce innovation through the creativity, knowledge and skill of the development team.

That said, fixed price is still a reality and, depending on the type of solution, there are ways to handle it without resorting to detailed upfront design and hardcore change control.