Just after writing one of our previous posts, I was listening to a book called ‘Start With Why: How Great Leaders Inspire Everyone To Take Action’, by Simon Sinek.  During one of the early chapters, Sinek refers to the well worn story of the American car manufacturer visiting a Japanese car manufacturer, although I think probably apocryphal.

‘There is a wonderful story of a group of American car executives who went to Japan to see a Japanese assembly line. At the end of the line, the doors were put on the hinges, the same as in America. But something was missing. In the United States, a line worker would take a rubber mallet and tap the edges of the door to ensure that it fit perfectly. In Japan, that job didn’t seem to exist. Confused, the American auto executives asked at what point they made sure the door fit perfectly. Their Japanese guide looked at them and smiled sheepishly. “We make sure it fits when we design it.” In the Japanese auto plant, they didn’t examine the problem and accumulate data to figure out the best solution—they engineered the outcome they wanted from the beginning. If they didn’t achieve their desired outcome, they understood it was because of a decision they made at the start of the process. At the end of the day, the doors on the American-made and Japanese-made cars appeared to fit when each rolled off the assembly line. Except the Japanese didn’t need to employ someone to hammer doors, nor did they need to buy any mallets. More importantly, the Japanese doors are likely to last longer and maybe even be more structurally sound in an accident. All this for no other reason than they ensured the pieces fit from the start”

It is also reminded my of my studies of Kaizen whilst studying for an MBA.  If designing the problem out works in engineering physical goods, why can’t we do more of this when engineering or implementing software?  Earlier in my career I often found myself and my team under pressure to start building or implementing where we knew that spending more time building requirements and designing solutions would mean both less time building, less time testing and less time with a rubber mallet making the solution fit.

 

Related Posts

News

In-house testing and ‘no, we don’t test data’

As I mentioned a few weeks ago, I spent the day at SITS.  I had some really interesting conversations  and some truly frightening ones, so beware.  We’re also working on bringing some guest posters to Read more…

News

Project Lifecycles and Engagement

Whatever techniques and methodologies are employed during a project, we see different stakeholders brought in at different stages. Typically, ITSM projects follow a waterfall process and a quasi Prince 2/PMP approach to managing the project. Read more…

News

An Approach to Estimating

Our experience within IT projects and particularly within ITSM projects revolves around the time critical nature of projects and the need to have everything immediately (whether this is true or not is up for discussion). Read more…