The increasing cost of change is ultimately what drives the need for complex products to have a robust product development to absolutely minimize the amount of change required to resolve things that are not known at the start of development, and thus minimize subsequent cost and schedule impacts.

I have attempted to illustrate the relative cost of change during a product development cycle in the above graph. This is not an absolute representation; i.e. for any particular change the specific values of this graph will be unique. But the general trend is the same across all change - the cost of change is relatively low thru the definition and design phase, but cost takes a significant increase once hardware (in terms of tooling and parts) is purchased. And of course, once product is fielded, then costs for change are at the maximum.

For complex products, if an incremental approach is taken instead of a robust product development process that I have previously described, then it is probable that change necessary for product success will be prohibitively expensive. Ultimately most (if not all) product developments fail because the understanding of when a change is necessary for product development success occurs far too late in the product development cycle, and as such is prohibitive of further effort.

An example of this caught my eye in a recent article - in the Friday Nov 7 2014 Wall Street Journal, "Safety Concerns Sank Google's Barges" on Page B1 by Jeff Elder, discusses the fact that the infamous Google barges that showed up last year in San Fransisco Bay with much mystery about their purpose are now in the process of being dismantled due to safety concerns expressed by the Coast Guard. Per the article, construction began in 2011, and Google began the process of obtaining Coast Guard approval in late 2012 with the intent of making them into retail demonstration space.

No product development can ever be perfect - if someone were to attempt to design without experiencing any failures, there would be no products as nothing can ever be perfected without being fabricated and tested. The purpose of planning is not to prevent failure; rather, the purpose of planning is to prevent SYSTEMIC failure, that is, a failure that cannot economically be overcome.

I believe (based on the information in the article) that the Google barge suffered a product development systemic failure. If indeed Google waited 12 - 24 months after construction began (and so waited by my estimate at least 24 - 36 months after design begun) to engage the Coast Guard in potential regulation requirements was a systemic failure of their product development process, as the requirements necessary to comply with regulations needed to have been understood by the designers early in the process to avoid the prohibitive expense of attempting addition later. These type of requirements cannot economically be incrementally added - they have to be (and could have been) designed in from the beginning. It is the resultant inability to incorporate the changes incrementally in a cost effective manner the changes necessary to comply to requirements that makes this situation a systemic failure.

It would initially seem odd that what is technically simple (a barge with a building on it) turned out to be a product development failure. However, perhaps it does makes sense in the context of how much thought may have went into their planning process, and how much experience Google has at successful non-software only product developments (particular products that involve the Coast Guard). I doubt many people at Google thought there was much technical challenge in the fabrication of a barge with a building on it, and therefore they may not have put together a sufficiently robust product development process. As such they did not anticipate the need to integrate the required equipment required to meet Coast Guard requirements, and subsequently failed.

The lesson to be learned is to not underestimate the impact of not addressing systemic failure modes on products independent of complexity. Systemic failure modes can be related to anything that needs to be designed into the product from the beginning of design to be ensure economic viability - things like regulatory requirements, firmware quality, or the other complexity drivers that I mentioned in previous discussions. Robust product development planning is specifically required to eliminate these systemic failure modes such that the product development is ultimately successful.

This article originally posted on LinkedIn