Every Jack has his Jill (1/2)

Many times we forget that the CI infrastructure we created is not here to stay. It is established to be just improved again and again. Creating a mindset of constantly improving any process which is even value-enabling is one of the hardest challenges in my daily life. “Yes but we have agreed on this standard. We have agreed on this rule” Clearly we have, and luckily we have done it together and not me alone as the leader of this implementation program. I have to admit that in most of the cases I am taking care that those needs and opportunities are put on the table to be discussed, otherwise they may have never been recognized or even ignored. On the other hand, just because its comfortable, some are coming up with the discussion that rules are here to be broken. The problem is, as a CI enthusiast you are NEVER allowed to respond to your instinct of making things comfortable for yourself. I confess that this can be the trigger for any improvement, namely seeking for comfort 😊. Coming back to the rules which are here to be broken, all guidelines, standards, rules etc. (should) have an underlying reason why they are created: safety, necessity, improve comfort, improve understanding, agility/flexibility, etc. You can refer back to this underlying reason and you have a reference on base of which you can discuss and eventually adapt the rule.

An approach to create high awareness about the role of standards is to show that it is not a new way of working – many companies have already standards. On the other hand, many of them were not reviewed for a long time, others are just assumptions or bad habits which have never entered the level of a standard. They were just executed without being questioned because someone was following them for a long time. We talk about change and the point is that circumstances under which we took decisions for standards and rules are also changing, there is no other way but to change our way of working from the bottom to the top. This is especially a topic for working on tasks and improvements: I call it “prioritization awareness”.

In the beginning of our CI implementation program I was about to overgo my own implementation principle and gave too many advices from which I was sure they are/will be needed. I had to stop myself and unleash the dog (reference to Sandors' previous blog entry) to make its own experiences but to be there to trigger the creation of rules and guidelines when the context is born. With “dog” I mean the process and not any individual. It ensures sense of urgency and the motivation to work on it 😊 One of those guidelines were the classification of the topics and which tools to be used for which problems/CI ideas.

In my opinion this is an issue which is extremely depending on the company culture and the management approach the company has. Of course there are overarching parameters like the scope & size or the complexity of the problem/CI which makes a certain arrangement necessary, but other parameters are pretty much company specific as I would say. We want to use just the best method for any topic. If we use an under-qualified method/tool we will not succeed, if we would use a too sophisticated tool, well we may succeed but with consuming unnecessary resources, so to say using a Ferrari to deliver a Pizza (this may have its advantages 😊)

It also plays into the credibility of the program. When the people recognize an obsolete amount of effort for a comparatively low benefit, they will question it. On the other hand and more important: with this guidelines you can also reflect principles like empowerment and decision making in the source in your company. It is always nice to have these principles but how to make them tangible? To be continued in the next blog entry...