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

Is ITSM really ready ‘Out of the Box’?

As ITSM has evolved in recent years, there has been an appetite and ability to move towards ‘Out of the Box’ implementations where not a stitch of code is changed in the ITSM solution during Read more…

News

Preparation is key

So, you’ve identified the need for a new ITSM system.  You might be starting from scratch (although that’s never really the case).  You might be upgrading between versions or procuring a system from a new Read more…

News

Don’t Disrespect the Data

There are many moving parts that ITSM Implementation teams need to consider in the scope of a project. Commonly the main focus is on code and configuration and second to this is data. This is Read more…