Engineering challenges – unified design. During the Apollo 13 flight, the astronauts nearly lost their lives because the carbon dioxide capturing filters in the lunar module were square in cross-section, while those in the main module were round. Standardization (i.e., one standard) would have been easy, but no one thought of it in advance. I still see this kind of mistake in various situations. Sometimes it’s a big problem like for those astronauts. Yet, it could have been solved earlier – just needed more communication between the engineers. But when is communication sufficient? Are there any ways to bypass these recurring problems with insufficient communication? Yes.
Engineering Challenges – Unification in Design
First, an important illustration from the review of the front engine of the Ford Mach-E: One minute from a Munro Associates video: Sandy Munro and Cory Steuben wonder how it happened that the rear connector of the high-voltage cable makes sense, but the front does not. It would be possible to standardize the used parts and use the same connectors, but this was not done, despite the obvious benefits. Such things, however, happen, resulting in a suboptimal product, sometimes non-functional.
Proactive Solutions in Engineering
Interestingly, there is a proven way to avoid this. Instead of saying that engineers should talk to each other or “talk even more,” it is necessary to establish ALL the touchpoints AT THE BEGINNING, which is not intuitive. Therefore, in Scrum for Hardware, the interfaces between the main modules are first determined in the first or second sprint (design phase). Then work begins on what is inside these modules. Similarly, components can be standardized. It is so natural to deal with boundary points at the end, when everything is designed, that we do not realize how many future problems we could save ourselves by agreeing at the beginning on what will be connected with what, how, and what additional parameters should be met in this connection. I have experienced this myself, hasty and costly changes of well-designed elements that were boundary could have been avoided. It is necessary to first properly agree on boundary issues and then design what is inside the individual modules. And this is very unintuitive.
Innovative Practices – The Wikispeed Example
Engineering challenges – unified design. Wikispeed – how to do it For example, the super-efficient, open-source Wikispeed car has several different independent suspensions for various road conditions and needs. Replacing any suspension is very simple there because the way of connecting the suspension module to the car frame was established from the beginning: This is just an introduction to the discussion on this topic. Scrum enforces more frequent communication within the team through daily meetings called “Daily Standup Meetings” or shortly daily. There is also pair designing inspired by pair programming. Scrum for Hardware also proposes solutions for component unification (something that in software is not as significant). Please share examples in the comments where engineers did not initially agree on boundary elements (or did not standardize components) and what were the later consequences. Also, share your proven patents for solving problems with engineering communication.
TRIZ Champion and Project Management Expert. Valued for opening thinking. The trainings he conducted were often a breakthrough event in the participants' careers. At TRIZ, he is fascinated by the possibility of providing simple solutions to difficult problems and breaking fixations. A trainer with over 20 years of experience, as well as a long-term member of the Supervisory Board at the ODITK GROUP. A respected speaker talked about TRIZ at Lean, Project Management (IPMA, PMI) and Production Management conferences.
