May 8, 2005 | John Rusk | 1 Comment Awarding contracts to the lowest bidder is optimistic at best, dangerous at worst. So why do we keep doing it? There are many reasons. To pick just one: we believe it works in “real” engineering – making bridges, roads and buildings. But it doesn’t. Although it is widely used in engineering; it’s not widely successful! The Truth about Engineering The latest issue of e.nz, published by New Zealand’s Institute of Professional Engineers, reports that “the indiscriminate urge for lowest price” leads to “late and unsatisfactory completion, disputes and litigation”. (Almost sounds like software!) The New Zealand Construction Industry Council says that “the lowest-bid approach is compromising design quality and integrity, health and safety, training, the environment… [Furthermore,] the lowest bid approach encourages unsustainable markets” [1]. Discussing solutions to these problems, e.nz explains that: “A substantial culture change is involved in progressing towards best practice in procurement. All stakeholders must accept that they have a duty to collaborate towards a common objective: the full satisfaction of the project’s objectives, in exchange for fair rewards for all who contributed.” [2] Why is the Lowest Price Dangerous? The lowest price is dangerous because you don’t know why it’s low. In the software industry, a company may offer a low quote for any of the following reasons: They have misunderstood the difficulty of the task [3]. (See this post too) They understand the task; the estimate is low simply because software estimation is inherently difficult. They understand the task, and are deliberately bidding low because they’re eager (or desperate) for your business. They understand the task, and have outstanding skills and technology which will allow them to complete it quickly. Only the last reason is a good one. The others, to greater or lesser degrees, may all threaten your project. Yet in terms of price, they look the same. So How Do You Tell the Difference? You have to base your decision on assessments of the supplier’s capability: the quality of their staff, the quality of their technology, and their track record. Price tells you nothing about capability. A low price may signal superior capability (reason 4), inferior capability (reason 1), desperation (reason 3), or nothing (reason 2). A Better “Real” Engineering Practice to Emulate If we want to emulate “real” engineering, we would be better to take our lead from the US federal government. Since 1972, price-based selection for engineering services has been prohibited for federal government agencies, with selection being based on supplier quality instead [4]. The approach has proved highly successful and has been widely emulated by state governments. I believe the US approach reflects an understanding of the risks noted above – that price tells you nothing about capability. The US approach may also reflect an awareness of just how embarrassing price-based selection would be after a major engineering disaster. Imagine a TV interview shortly after the collapse of a bridge: Reporter: So how did you award the contract? Official: We… errrr…chose the cheapest. Indeed. Why don’t we ask the same question after a software project collapses? References [1] The Construction Industry Council (CIC) document is available here (700k PDF file): https://www.nzcic.co.nz/CIC_Procument_document_internet.pdf Although it is entirely about construction, it makes interesting (and surprisingly relevant) reading for IT professionals. The CIC points out that government, as a major purchaser in the sector, must lead the way. The same applies in IT. For another perspective, see this Canadian document: https://www.peo.on.ca/publications/DIMENSIONS/marapr2001/ma01price_consult.pdf Like New Zealand, Canada has experienced a “leaky building” scandal in which price-based procurement was a contributing factor. [2] Ernesto E. Henroid (FIPENZ, FICE), writing in the March/April 2005 issue of e.nz. Magazine web site: https://e.nz-magazine.co.nz/main.htm. [3] Well-known author Steve McConnell documents a case study in which the highest bid was actually the best, because the other bidders misunderstood the task. Needless to say, the high-yet-accurate quote wasn’t chosen and the project went on to overrun its (unrealistically low) budget by 1400%. His description covers many relevant issues and can be found here: https://www.stevemcconnell.com/sg-complit.htm [4] Price-based selection for engineering services was banned by the 1972 Brooks Act (the second Brooks Act). I was going to ask my American readers why the same rule was not applied to IT but a little research unearthed a surprising fact: for IT, price based selection was required by the federal government. The legislation was the 1965 Brooks Act. Yes, that’s the same congressman Brooks! It seems Brooks had a very active interest in procurement, an interest which he expressed in two quite different laws. The earlier (IT) act was designed to promote competition to break IBM’s stranglehold on the industry. It achieved that goal, became widely disliked, and was repealed in 1996. The second (engineering) act still has widespread popularity and success – and that’s an important lesson for today’s IT industry. More on the Brooks Act(s): https://www.asce.org/pressroom/news/grwk/event_release.cfm?uid=1777 https://www.gcn.com/21_33/community/20522-1.html https://www.fcw.com/fcw/articles/2004/0315/pol-reform-03-15-04.asp If you’re interested in the fact that the (engineering) Brooks Act covers design, but not (as far as I know) construction, read these articles by Jack Reeves:https://www.developerdotstar.com/mag/articles/reeves_design_main.html See this page on my site too.