Thursday, January 8, 2015

Day 355: When a Standard isn't the Standard

Yesterday, I wrapped up a three day Whitebelt training and kaizen session, focused on our field services group, at our Toronto office. The group was an interesting mix of field technicians, project managers, service engineers, and most of the participants had to travel from their home or regional offices/work sites for this session. This group rarely got together on the phone let alone in the same room. 

They were a lively bunch, with a strong "git 'er done" attitude. After learning about value, waste, flow, 5S, fishbone/root cause analyses, RACI matrices, value stream mapping and value graphs, they went off on their way, looking for the gold, the opportunities to help improve their work and ultimately the outcomes for their customers.

Three days of searching, stumbling, spinning wheels, gaining traction, and moving forward, they reported out their findings. Lots of low hanging fruit, some really clever ideas, and some contentious ones. Contentious?  Whaaaa?

Yes - contentious because their investigations revealed that a previously developed standard was not being followed. Senior management had made it very clear that the standard was to be adhered to, yet reality showed that it rarely was.

So what happened? Why did the previous standard fail? People generally want to do a good job, so when they don't do some task a certain way, or use a certain tool it's because they either a: don't know how to do the task/how to use the tool, or b: they don't want to do so. This was a case of the latter - no one did the task, followed the standard, because it was perceived to be a big fat case of over-processing. They all wanted to do the right thing, but they also couldn't reconcile the process standard as prescribed with what was best for the company and ultimately the customer.

I can only imagine how utterly frustrating it must have been for the process owner (on the other end of a video conference, 5000kms away to boot) to hear this. To have spent the time and effort to put the standard in place -- with all best intentions -- only to hear that despite repeated directives to follow, that he was essentially walking alone.

What was surprising, however, was the perceived (over the phone, remember) steadfastness to the existing standard. I have always had external standards to which my organization had to adhere - ISO 9001, 14001, IEEE, etc. and with those, your challenge is to meet its requirements with as little effort or onus to your organization. However, internal standards are our own doing - so it's up to us as to when they should be revisited, improved, or removed even. 

We often talk about "the gap" when defining a problem. The gap is the difference between the current state and the desired, near-term future state. We use our tools to investigate this gap and to develop ways to close that gap. So given this current state, this gap between desired behaviour and actual behaviour, how do we close the gap?

Well, I guess we negotiate

Yep that's right, a good ole fashioned back and forth. Quid quo pro, as it were. Each side must be willing to give up a little to come to a common agreement, a common outcome. There has to be a middle ground here. Or even progress in the right direction. Anything would be better than this situation.

There are always real deal-breakers in any negotiation, those key points that cannot be relinquished or positions that cannot be softened, but there is often quite a lot of wiggle room. There is always room for improvement right? In contracts, we look at the intent of a clause, not just the letter. So it might be worth looking at the intent of this contentious standard. What problem was it trying to solve when it was created? Is that problem actually still a problem? Or have things changed enough to justify a fresh look at the situation and this standard?

Considering what I heard during the report out, I'd say it's worth the effort to do just that.

AMac