Welcome to the fifth blog post in this series about problem-solving. Today’s blog post will be about other kinds of problems.
One example is a system product with integrated parts of electronic parts that is failing at legal requirements at the test house. The company first goes home and checks their own test equipment used for the sub-system tests which have shown to be ok, and also the sub-subsystem equipment. At first, they cannot understand the failure, but further investigations show that they have missed a new and harder legal EMC requirements. And since it is not part of the system requirements, this led to that the sub-requirements are not complete, and of course not the design specifications either. Going further in their investigation shows that there was too much coordinating work, which led to that this activity was never taken care of by anyone. The scenario looks like this:
And as you can see, the EMC problems are affecting the whole Product and is normally requiring some hardware prototypes. Without the correct planning for taking care about EMC already from the start, it will be a nightmare and most probably require big changes of not only the requirement specification, but also significant changes in the design specifications of the different parts of the total product. Other areas that show the same behaviour are parts of a system product regarding their respective; electricity usage, heat dissipation, volume needed, bus load, memory usage for programs and working memory need for programs. The parts will affect the total system product, so without looking at the whole from start will get us into trouble.
Another company, making cars, makes a severe fail, when missing the width requirement for their new type of car in the introduction to another country, making the car wider than allowed for driving on all kind of roads. All parts of the car will then get a reduced space for its operation, leading to redesign of most parts, extremely expensive changes. And since most of the cars today are built on platforms, also the platform needs to be rebuilt. Further investigation about how this could happen, showed that people were to stressed due to too many other people on sick leave. This scenario looks like this:
In this example with a missed legal requirement, it is easier to understand what to do about it, but due to narrowing of the volume for all parts within the car, we are really talking of a total makeover of the car as a system product.
An example that has nothing to do with product development, is the following:
There is a car accident due to a hole in the motor way, too big depending on the size of the car wheel and the speed of the car. The first thing to do is of course to take action so that there are no more accidents. The root cause to the accident on a product level (the motor way), is apparently the hole in the road, since the science behind is the gravitation law, always applies. The gravitation law we cannot change, so the most obvious thing to do is to repair the hole in the road. Another possible, but non-preferred solution, is to require bigger wheels for the vehicles driving that motorway, and by that avoiding (at least right now) to fix the hole and save money for the community. The latter case will of course not be the common solution. But, by looking more holistically on the situation, and focusing on the community instead, responsible for the roads, the hole may only be a symptom. Why? Because on an organizational level, we can continue to ask why the hole existed. Here are some possible causes. One cause can be heavy rain that undermined the motorway, which means that no one could anticipate it, it happened accidently as Murphy’s law always does, which is more of a product level then. Another cause can be that the community knew about the hole for a long time, but that it had been smaller, and not dangerous, so they prioritized other work with a risk. And why did they prioritize other work? Because they were lacking money, due to bad financials. Another cause of bad financial of the community can be that they bought the motorway too cheap when it was built some years ago, so soon more holes will pop up, which means that fixing the hole is not a root cause even for the road, since it was not built according to the right standards from start. Asking why on the financials in either of the mentioned cases can lead to root causes within the organization, for example bad collaboration within the community, leading to high costs due to too many employees. This bad collaboration is due to the system (the way of working in the community), and not due to the employees, since we humans are both social and collaborative from our DNA. In most cases it is due to the rigid silo organization, and the lack of a virtual delivery structure, making collaboration between the silos to “no one’s responsibility”, and we are not fulfilling all our organizational principles (science). A SPPA done on the community will easily find all the root causes to bad financials and all other low- and high-level problems, both built-in and normal problems.
A last example of another type is a manager at a company that consider that all employees in the team are low performers. By hiring a psychology consultant to look into this, the manager hopes to find the problem. The psychologist interviews the team members one by one and very fast in respective interview it comes up that the employees are not feeling well, since there is something wrong with the atmosphere. Further investigations about why tells the psychologist that all the employees have the same answer, the manager needs control and are micro managing every employee’s work. But now the psychologist has a very big dilemma, since the manager pays the psychologist and the manager is a part of the problem. This scenario is unfortunately very common when changing context for the work of the psychologist. If a private customer comes to the psychologist, the circumstances to the customer’s problems normally are difficult to change, but if the manager makes all employees stressed, the manager is part of the problem, but maybe not the root cause. In an organisation we most of times have the answers ourselves, even if we cannot see and understand it, or accept it.
If we continue to ask why on this particular problem, maybe the manager’s manager has the same behaviour, which in turn depends on that the organisation is too expensive, that in turn depends on too low resource efficiency. The scenario looks likes this with a dotted line between who is paying and the continuation of asking why to find the organisational root cause:
In this example with the psychologist, we can see that the original problem is an organisational problem and not a product problem. So, an organisation originating from a bad system can behave in any way, since the chains of symptoms are endless.
And about the psychologist’s dilemma:
Companies should have a centralized function in HR, that buys external help, to avoid conflict of interest, if the company really need to solve a people problem with the help of external consultants. Because, this is about respect for people, meaning that managers and non-managers in the organisation should represent the organisation on the same conditions.
This was all in today’s blog post and tomorrow we will dig into the problem with queues of activities in organisations and how to deal with these queue problems.
C u then.