Pick Two, But Only Two

There's a saying in engineering:

"In any product development project you can have it good, fast, or cheap. Pick which two."

You tell this to most people, even non-engineers, and they get it. Something has to give, and choices get made in development. So why is it so hard to put into practice?

Good and Fast:

If you want a quality product developed quickly, then pay overtime, consultants to help, fab houses to expedite, and develop without consideration of materials or processes used no matter how expensive. There is, however, a limit to how fast some projects can be done, and infinite money won't get a project completed instantly - some things just take time. The 'C' level often fail to grasp this - they say they know it, but actions indicate that very often they don't.

It's common to fall for the "Mythical Man Month", where the expectation is that if you double the staff on a project, development time will halve. At some point, this is like saying "Nine women can make a baby in a month", and in fact the management overhead of too many people on a project can slow things down. This is the equivalent of computing's Amdahl's Law, where some tasks can be parallelized, and some are inherently serial - in the end, it's those serial tasks that limit how fast things can be done even with infinite computing resources.

Under pressure of timeline, management often cut what they are told is critical - design verification testing, engineering verification testing, initial user testing - I could say because they have no understanding of the need, or they don't listen when told how important they are, but often it's because they can hope that things will work out, and the blame will be on others if it doesn't. "You should just do it right first time" I have literally been told when objecting to that route. That some problems just have a minimum time and effort to solve, is a hard reality to accept for some. Blame, ultimately, ends at the C-suite, but until that day of reckoning, the minions are suitable cannon fodder for blame. 

Heavy pressure on management also makes them susceptible to the sell from the outside group who swears they can do it faster. better, cheaper than the internal team - "Just sign this contract and we'll take care of it all!". It's nice to be able to sign with someone who promises a solution, when your own team keep telling you of major issues and delays, but when it does go wrong it's the internal team that's going to clean up the mess, and for a lower hourly rate than the outside group was paid. Importantly, it doesn't go unnoticed by the engineering side that they were not trusted, and that does not help future interactions.

One particularly frustrating situation for engineers is when they deliver what's asked for, a quality product in a timely manner, only to be berated for it being too expensive when only weeks before "cost is no object!". Stating that you were (just) within the cost target set falls on deaf ears, and you're sent back to lower the price - without, of course, sacrificing quality or with a delay (which there will inevitably be). I've walked away from those meetings hearing the remaining executives saying "Engineers just never understand cost, it's beyond them." when in actuality we understand it perfectly. Cost is a constraint, like size, or weight, or performance, and we'll work to hit that. Cost targets can move during development, but poor choice of that target is a failure of the business side, not engineering.

Fast and Cheap:

Now, if you want something fast and cheap, then as long as the product doesn't have to be very good (say, falls apart on second use, or doesn't actually do what is claimed) it's achievable. Engineers hate this one, by nature they want to make a good product, and they know they'll be fixing things later on anyway when it will be much more expensive to do than if it was done correctly the first time. Software is often released this way, with the hope that the application is 'just good enough' or that the customer can be placated while fixes are put in place. 

With a non-critical product, and an understanding customer, this can be a viable route for a business, especially with software where patches and updates can fix problems and add needed features quickly. On the hardware side, this is more applicable to disposable or very low cost products, physical objects don't tend to improve with a patch. Despite this, such a mentality has started to make its way into medical related devices such as with Theranos, and other safety critical areas such as automotive - I've written about this in more detail here and here. 

With hardware this method is almost guaranteed to accrue technical debt - problems that cost a lot more to fix in future that to fix now. Hardware that fails in the field regularly and is returned, is a nightmare for warranty cost as well as reputation and returning customers. And guess who gets the blame for a product like that?

Good and Cheap:

Good and cheap (or affordable) is the rarest combination, it's hard to give the time and resources needed to do a job well first time. The pressure to release products to earn revenue, or placate investors, is intense. A few companies can do this, for example Google or Apple with special projects like autonomous vehicles, but in most cases it's very, very hard for normal companies to do this. If you can give a team time to solve problems and iterate, design for cost from the beginning, investigate alternate routes, multiple rounds of customer testing, and the equipment they need, then you can deliver great economical products. Sadly, it's the exception, not the rule.

Good, Fast, and Cheap:

Think you're an exception to all this? Go ahead, good luck, you may be the exception. Odds are that you're going to end up with a product that's late, not quite as good, or more expensive, than if you'd just picked two. If you're ignoring your engineering team who've already told you this, then maybe you're the CxO of a company I've worked for...

Which Two to Pick?

So what is the solution to this problem? There is no one answer to that, every company, every product, every team, every market is different. Getting a product to market, at quality, at cost, and on time, is a monumental task, for both the business and engineering sides of a company. The companies that I've seen succeed the best at this set a culture that is adhered to even under great temptation to move away from - and that consistency has to come from the CEO. This culture usually revolves around a few key points:

1. The business side sets clear and realistic goals for the engineering team - performance, cost, timeline - and stick with them. Engineering need to be able to trust the business side and what they say.
2. CEOs need to understand that their word does not overcome reality, and that timelines in particular can be impossible to shift. Business needs to trust that when engineering say a timeline or cost target isn't achievable, they need to re-evaluate that metric.
3. Engineering need to communicate realities and issues to business in a clear manner, with an understanding that sometimes terms like 'at risk' don't always mean the same to each side.
4. When things go wrong - either engineering performance or business predictions - there needs to be honest and open communication with a mind to fixing the problem, and not a witchhunt looking for the target to blame.

It seems simple, when it comes down to so few things - each person doing their job, open and honest communication, and teamwork to fix a problem when things (inevitably) go wrong. All it requires is competent leadership with a basic understanding of reality. Why is it so rarely seen?