Throughout my career I’ve heard the term “bullet proof” a few times from a few managers but never from individual contributors. The first time I heard it I didn’t know what it meant but from the context of the sentence I determined the intended definition. Some of these phrases I’ve heard were, “…your design needs to be bullet-proof.” or “…the procedure must be bullet-proof.”
Why would anyone request, metaphorically speaking, that a design or process be “bullet-proof”? The foremost reason why someone would make that request is for their concern to eliminate the effects of any and all problems that may arise. For the creator of the design or procedures, their primary concern is that it functions within the accepted criteria. Designing for anticipated problems would be an immediate secondary priority.
I never gave the bullet-proof term much thought or the reasons why the individual contributors I know never used it, until some time ago.
I had an interview for a Manufacturing Engineer position. Throughout the interview the interviewers repeatedly expressed how impressed they were at the fact that I was cross-functional. I didn’t see that quality or skill as something exceptional. It’s just a matter of doing what is required for dynamic situations. I thought if they were impressed with that then they would be very impressed with my track record of quickly resolving production issues, since both come from the same philosophy. Surprisingly, the technical manager was not impressed. He said that the goal of the Manufacturing Engineer is not to solve problems all the time but to devise processes that are “bullet proof”. Hmm, I haven’t heard that term for the longest time. I came to the immediate realisation why my colleagues and I don’t use it. For the sake of possibly snafuing the interview, I decided not to point out the flaw in the technical manager’s philosophy.
Sure, in an ideal world it would be possible to devise designs or processes that would account for all problem occurrences. In reality there are numerous factors that can render the “bullet-proof” concept as nothing more than a desire. One of these is the human factor. The human factor is one that is multi-faceted. By that I mean to say we all have our times when we are not operating or thinking at 100%. We have our “off-days” due to illness, distractions, or mood. Basically our focus have diminished to a degree, which naturally would result in mistakes being made. Another variable of the human factor is our mindsets. Mindset is another broad topic which I talked about in the Flexibility and Mindset posts (Introduction, Complacency, and Ego).
I can go on to list even more variables to this one factor but the point I’m making is that with all of the variables that are a part of this factor, the goal of devising a “bullet-proof” system becomes a very difficult endeavour. Eliminating the human factor through automation will not guarantee a “bullet-proof” system. Mechanical problems do occur, such as tool breakage, equipment defects, and other factors we may or not have control over.
To list every known possible cause for problems and those that would be unknown, it would be an extremely long and exhaustive exercise. If someone requests that a product or process be “bullet-proof”, they are essentially asking the creator to undertake this very long exercise. Does productivity suffer? Absolutely. Implementation times would be greatly increased, resulting in spending more time for the products and services to reach the customer. Some may argue that the extra time spent up front will be beneficial in the long term. That is correct if your organisation is not planning on changing anything for that length of time. In an evolving business environment, that would not be a practical thing to do.
So the question of, do “bullet-proof processes or designs eliminate future problems? In theory, yes. In practice, it is not a feasible endeavour.
In the spirit of keeping this post short, I would like to continue this topic on next week’s post.
Until the next time!
Productivity Aspects 