Cost Benefit Analysis: Can a $20 solution replace a multimillion dollar solution?

“For a man with a hammer every problem is a nail.” The EA team having access to a very large hammer often leans towards very elaborate solutions to solve problems that could have been solved with a much simpler solution, or even no solution at all. As a solution Architect I’ve often encountered such solutions -and even was part of few of them- very elaborate solutions to resolve problems that should have been handled operationally.

Screen Shot 2016-01-20 at 3.05.12 PM.png

Cost Benefit Analysis conducted during the requirements phase of a project can prevent such scenarios from taking place, whats more important though is keeping an open mind and accepting that often the problem encountered doesn’t require the hammer the EA team is wielding.

Here is a parable I like to share when I encounter such situations, It is said that this is a true story.

Understanding how important that was, the CEO of the toothpaste factory got the top people in the company together and they decided to start a new project, in which they would hire an external engineering company to solve their empty boxes problem, as their engineering department was already too stretched to take on any extra effort.

The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.

A while later, the CEO decides to have a look at the ROI of the project: amazing results! No empty boxes ever shipped out of the factory after the scales were put in place. Very few customer complaints, and they were gaining market share. “That’s some money well spent!” – he says, before looking closely at the other statistics in the report.

It turns out, the number of defects picked up by the scales was 0 after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the precision scales were installed. A few feet before it, there was a $20 desk fan, blowing the empty boxes out of the belt and into a bin.

“Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.


The Law of Diminishing Returns

As an architect you often encounter requirements that are better off not implemented, requirements are triaged through several activities one of them is impact analysis. The law of diminishing returns comes into play here given that the how the complexity of a requirement and its return are often inversely proportional. Its often more productive to partially implement the requirement rather than going to the full extent as the cost will far exceed the return.

The law of diminishing returns states that in all productive processes, adding more of one factor of production, while holding all others constant, will at some point yield lower incremental per-unit returns.

This behaviour can be represented using the following formula with X being the unit of incrementation and i the number of increments.


Screen Shot 2016-01-19 at 11.40.19 AM

To put it in a more colloquial form, the more seeds you plant in a field the less yield you get per seed, another example would be developers per project there is a certain infliction point afterwards it doesn’t matter how many developers you add to the project the return remains the same.

An example of requirement that exhibits a highly diminishing result are service assurance requirements, requiring a 99.9% accuracy would cost far more than what it would cost to have a manual workflow to manually verify the deviation. OCR (optical character recognition) projects come in mind and hence you find projects like captcha relying on users to verify the output of the OCR algorithm.


This is not very different from NP-Complete problems and approximation algorithms reaching an acceptable solution at a fraction of the cost is favoured over reaching the solution to a certain problem set with a potentially infinite solution time.