People or System Problem

Workforce Development | 19 June 2012 | Team EACPDS

Share this

At a recent seminar we gave that touched on root cause problem solving, one of the attendees asked a question about a problem at their company. The problem involved two individuals who were in conflict, in essence, over the definition of the problem. I gave an answer that suggested assigning the solving of the problem to a third individual who had not taken a no-compromise dig-in-your-heels position on it. The attendee said that the problem was actually the intractable insistent stand taken by the two employees in conflict, and that the personal conflict was the problem they were struggling to solve.

Since the seminar, understanding that I had not given a very good answer to the question, I have spent some time thinking about this situation and will share my thoughts in this blog.

The problem is one that we are all likely familiar with. The market requirements for a development project insisted on a product feature whose shape and tolerances were beyond the current level of manufacturing capabilities. The two individuals squared off alternately insisting the feature was necessary and then the other that the feature could not be created according to the spec.

A couple of quick thoughts have occurred to me right off the top that helped me put my considerations into context. First off, I recalled Deming’s instruction that 95% of what appears to us to be a people conflict or a people problem is in fact a system problem that comes to the surface in the guise of a people problem. And the second thought is courtesy of Peter Senge who postulates in the second law of systems thinking that pressure (pushed ideas, pushed requirements) creates its own resistance.

As is often the case with problems that have hooked in combatants, there are short term measures that need to be taken to get past the current incarnation of the problem, and then in follow up, a root cause problem solving project should be executed to prevent or at least mitigate future recurrence.

Let me insert here a brief disclaimer. In the problem solving technique we teach, we apply the ‘learning first’ paradigm that those of you familiar with Mike Kennedy’s writings will recognize. The technique calls out a principle common in all applications of the Lean philosophy, that the first step is coming to an understanding of the problem by going to the gemba (or in product development by following genchi gembutsu), that is going to the location of the problem and experiencing it first-hand. We have not done that, so this discussion will be generalized rather than specific.

First is the band aid to get past the current standoff. Power struggles that show no sign of resolution need to be escalated to move things forward.

Then, to start, the requirement should be dissected.Is it a real requirement — a must-have or a should-have, or is it a nice to have — a could-have? If the requirement is legitimate, then the second step is to confirm the ability of manufacturing to hold the specified tolerances.  If in fact both individuals are correct – it is a legitimate requirement and manufacturing can’t hold the spec – then what Covey calls the 3rd Alternative must be sought. Because both combatants are right, the position of each combatant relative to the other is wrong, and new thinking is required. A list of alternate options would be created, and the tradeoffs of the viable ones would be analyzed against each other. For example, outsourcing seems a logical option, but that option needs to be evaluated on a cost/benefit basis of the required feature. If it is a must-have (we don’t have a product without it) compromise is not possible and the best cost for the feature should be sought. If it is a should-have (the market values this and our product would be better positioned including it) then the cost/benefit may in fact drive to a compromise position.

In moving on to the long term solution for this problem, it is worth citing again Deming’s contention that this people problem is most likely a systems problem. If in this organization, like in many organizations, a marketing manager sets the requirements that a project manager must lead a team to satisfy and subsequently a production supervisor must see repeatedly manufactured, you have no natural constraint on the requirement setting. Even well intentioned product marketer can create a situation where it is impossible for other downstream leaders to succeed. Some organizations have set up a system where the individual responsible for setting the product requirements also runs the project and is thereby responsible for delivering against the requirements. This drives a natural rationality into the setting of the product requirements!

Other organizations have moved to the definition of product requirements as goals rather than as hard specs. In the case of must-haves, they are defined as technical specs. But for should-haves, a system of goals cascades from product level goals down to subsystem and assembly goals. This creates a more open design space for the development team, as opposed to the overly constrained space bounded by hard specs. It is common for product development organizations to adopt this practice on their path towards implementation of Set Based Design.

The best system level countermeasure to the cross functional conflict that we are discussing here is a product development system element that has been implemented in Japan, but to my knowledge no organization has implemented here. It requires extreme discipline and patience. This element is called a Kentou Phase, a study phase, inserted early into the development cycle. During it, cross functional team members share functional knowledge and functional need with other team members.  And the team members collectively study how to satisfy the goals of the project. In the end, this approach prevents even a strong individual pushing their ideas on the team ‘and building its own resistance’.

Resolving cross functional conflict is critically important, because quality problems arise on the interface between functions. Conflicts like the one that we are looking at here will result in a sub-optimal level of product quality if they are not successfully resolved.

Categories