jul 8, 2020


I anledning Los Norges første bokslipp – Lean Sensei – vil vi fremover presentere en bloggserie med temaet “lean og læring” av Eivind Reke og Michael Ballé. Det vil være mulig å komme med spørsmål og refleksjoner til forfatterne. Send gjerne inn til disse til post@losnorge.no. Første post er en kort diskusjon om hvordan vi tenker og hva som opptar oss påvirker måten vi bruker leanverktøy, den mentale modellen på læringsspråk. Vi har tatt utgangspunkt i et verktøy som hører hjemme i produktutvikling, nemlig QFD.

 The Quality of Function Deployment

Eivind: What seems to be the biggest concern of managers in western organizations today is the question: “Will my subordinates deliver what they have promised, will work be done in time, where are we in the process?” Hence most daily stand-ups and supporting Obeyas are process-driven. We visualise what we worry about. Is this lean? Not really. A truly lean organization would not worry about delivery, why would one, people are usually keen to make the effort to deliver as long as when, where and what are clear. So, what does a lean leader worry about? As you might have guessed, the clue is in the title, a lean leader worries about quality. All the time. To a lean leader questioning people’s ability to deliver is absurd. However, supporting their technical skills development is key. The question then is, how does this different type of worry impact how we use the lean tools? In a product development team this differentiation can be highlighted in the how the Quality Function Deployment (QFD) matrix is approached.

Michael: The twist is that now that so many have bought into the ideology of “shareholder value first” or “the only goal of a company is to make money” many CEOs feel they have a moral obligation to pressure employees to deliver what was planned, no matter what.

Plans are what shareholders live for. Plans are what analysts look at, and what drives the share price. If plans don’t deliver – no worry, more plans to correct the situation are ready. Until customers stop buying.

When we’re looking at product engineering, this approach can be disastrous. First, engineering problems can’t be wiped out with powerpoint slides. At some point, someone has to understand what the problem is and find a fix. This requires knowledge, expertise and creativity. Just asking people to commit on delivery don’t get the job done.

Secondly, and harder to see, a product is not just a sum of functions – it’s the integration of functions. I remember a carmaker with a reputation for styling where the boss had enough of getting flack for so-so quality. He asked his engineers to dramatically improved quality on very tight deadlines. What they did is take all the more reliable functions for cars in the existing line-up and come up with a car around these functions, feeling confident the car would be more robust because each of the function was more robust. 

We’ll never know – the resulting car was ugly as sin and the audience for this brand looked for styling. It never sold. 

When you look at a Quality Function Deployement (QFD) matrix, you can think of it as a way to make sure each function separately is deployed well and on time, thinking ahead of interface problems with other functions or processes. That would be like choosing all the best features of a face and hoping the composite portrait will be attractive. 

Or you can think of it as a way to check the quality of your function deployment: make sure every new function integrates smoothly with pre-existing ones in order to come up with a fully integrated product customers will love. 

QFD is not about making sure each function is engineered on time. It’s about understanding what we change and what we keep in the product when coming up with the next iteration, and then making sure the new functions integrate seamlessly with the existing one. To convince customers, a product must be grown organically, not assembled from lego bricks 

This is why we look at the quality of Function Deployment, not the deployment of Quality Functions.