FREE copy of the Uptime Elements Implementation Guide once you subscribe to Reliability Weekly

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

Keep reading...Show less

Upcoming Events

August 8 - August 10, 2023

Maximo World 2023

View all Events
banner
80% of Reliabilityweb.com newsletter subscribers report finding something used to improve their jobs on a regular basis.
Subscribers get exclusive content. Just released...MRO Best Practices Special Report - a $399 value!
DOWNLOAD NOW
Internet of Things Vendors Disrupting the Asset Condition Management Domain at IMC-2022

Internet of Things Vendors Disrupting the Asset Condition Management Domain at IMC-2022 The 36th International Maintenance Conference collocated with the RELIABILITY 4.0 Digital Transformation Conference [East]

Asset Management Technology

The aim of the Asset Management technology domain is to assure that IT/OT systems are focused on creating the value from the assets and that the business can deliver to achieve organizational objectives as informed by risk.

TRIRIGAWORLD AWARDS at MaximoWorld 2022

TRIRIGAWORLD AWARDS honors excellence in space optimization and facility management, A Reliabilityweb.com event to further advance asset management

IMC-2022 Who's Who: The World's Best Run Companies

The International Maintenance Conference (IMC) provides a fresh, positive community-based curated experience to gain knowledge and a positive perspective for advancing reliability and asset management through people, their managers, the strategy, the processes, the data and the technology. The world’s best-run companies are connecting the workforce, management, assets and data to automate asset knowledge that can be leveraged for huge beneficial decisions.

Uptime Elements Root Cause Analysis

Root Cause Analysis is a problem solving method. Professionals who are competent in Root Cause Analysis for problem solving are in high demand.

Reliability Risk Meter

The asset is not concerned with the management decision. The asset responds to physics

Why Reliability Leadership?

If you do not manage reliability culture, it manages you, and you may not even be aware of the extent to which this is happening!

Asset Condition Management versus Asset Health Index

Confusion abounds in language. Have you thought through the constraints of using the language of Asset Health?

Seven Chakras of Asset Management by Terrence O'Hanlon

The seven major asset management chakras run cross-functionally from the specification and design of assets through the asset lifecycle to the decommissioning and disposal of the asset connected through technology

Reliability Leader Fluid Cleanliness Pledge

Fluid Cleanliness is a Reliability Achievement Strategy as well as an asset life extension strategy