A riddle on product development projects to think about! Part 2
06 January 2016, Jelena Fedurko
I got a clarification for the riddle as presented in Part 1:
“Just one big BUT!! There is a resource conflict. The process engineers in the factories are responsible for both types of projects. New products require new/modified processes. Existing products require improvements – speed, quality, capacity, cost … and also require process engineers. YES, there are product development resources and they are a different set. The conflict arises when the new product is qualified for sale and must be industrialized in the factory. It is in the factory where the conflict occurs.
It is a ‘conflict’ between the factory and product development because the factory delays product industrialization for their factory reasons (local optimization). The product development people often face a question ‘Why should we speed up only to have to wait for the factory to do their part. It feels like the army … hurry up, and wait?’ “
This comment brings in new understanding of the conflict which is now truly between the product development projects and improvement projects.
Let’s look again at the first part of the clarification to the conflict:
“The process engineers in the factories are responsible for both types of projects. New products require new/modified processes. Existing products require improvements – speed, quality, capacity, cost … and also require process engineers. […] The conflict arises when the new product is qualified for sale and must be industrialized in the factory. It is in the factory where the conflict occurs.”
If we go along with the claim that there is a resource conflict, and based on the statements “The process engineers in the factories are responsible for both types of projects” and “It is in the factory where the conflict occurs”, the conflict seems to be of factory process engineers and looks like that:
However, such conflict raises immediate questions:
- Do process engineers really face this dilemma?
- Are B and C the needs of process engineers in the factory?
- Is A the objective of process engineers in the factory?
If we still go along with the claim that there is a resource conflict regarding factory process engineers (they are responsible for both types of the project in the factory), and considering the statement “the factory delays product industrialization for their factory reasons (local optimization)”, then the conflict would look like the following dilemma of factory process engineers:
The need in C is not clear from the information in the riddle.
Do the factory process engineers really face this dilemma?
Absolutely NOT, as it is clearly stated by the continuation of the clarification: “It is a ‘conflict’ between the factory and product development because the factory delays product industrialization for their factory reasons (local optimization). The product development people often face a question ‘Why should we speed up only to have to wait for the factory to do their part. It feels like the army … hurry up, and wait?’ “
The factory DELAYS product industrialization projects – it means they have NO CLOUD and NO DILEMMA. The process engineers do NOT swing between: “Should we delay or not?” They delay – to protect the factory local optima. In terms of the Cloud above they pursue the lower leg of the Cloud.
Interestingly enough that the statement “The product development people often face a question ‘Why should we speed up only to have to wait for the factory to do their part. It feels like the army … hurry up, and wait?’ “ reveals that actually the riddle is speaking about the internal conflict/dilemma of the product development engineers (NOT of the factory process engineers!). And this dilemma looks like this:
The internal dilemma of the product development engineers is caused by the Two-Sided Organizational Conflict Cloud, where one side is represented by the product development engineers and the other side – by factory process engineers:
An observation: while in this two-sided conflict the process engineers side is presented by their preferred action from the dilemma ‘give improvement projects priority’ vs. ‘give product development projects priority’ (again, if such a dilemma exists at all), the side of product development engineers is presented by their forced action from their dilemma – as it is clear from the description that they prefer NOT to speed up the work on the projects as they see no sense and no appreciation of their effort further in the process (in the industrialization stage).
Another note regarding this two-sided conflict: the link “D endangers C” is not readily apparent. However, it is possible to argue that getting the new product timely ready to move to the industrialization stage will eventually force the factory process engineers to push further in time some of the preferred and ready to launch improvement projects, thus endangering their need for “quick and measurable return”.
The bottom line: it looks like even though the company believes that they [quoting the riddle:] “decide correctly which product development projects should be pursued, AND improvement projects are also selected correctly with proper application of T, I, OE and proper focus on the organization’s constraint”, the company currently has not moved beyond Step 2 of 5 Focusing Steps: Decide how to exploit the system constraint.
They do not demonstrate the difficulty in deciding. The difficulty is either in understanding the technical side of how to perform subordination – Step 3, or in following the plan for subordination actions.
The situation described in the riddle strongly suggests that there is no synchronization between the two departments/two sets of resources – factory process engineering and product development – and no alignment of the both departments to the same set of measurements that would encompass both types of projects.
Published by Jelena Fedurko, 06 January 2016
I bet that the situation at the front (product development and process engineers are at the front) is not so clear as described. Both sides understand each other and try to help their colleagues, The likely outcome is too much (much too much) WIP in process engineering and as a result too little gets done.
The situation is hampered by division of labour! Process engineering and product development are 2 different departments … each with their specific KPIs. For process engineers they could be cost effectiveness, production capacity, quality, efficiency etc. For new product development it could be the sales from new products in the first 3 years after commercialisation, time to market, the number of new developments etc. KPIs cause conflicts because they are not aligned correctly … we have an engine of disharmony.
If “Both sides understand each other and try to help their colleagues” – then the claim in the clarification to the riddle at the beginning of Part 2 that there is a ‘conflict’ between the factory and product development is ungrounded. The conflict between the two departments either exists (the claim in the clarification) or does not (the claim in the comment above).
The comment above “the likely outcome is too much (much too much) WIP in process engineering and as a result too little gets done” brings back the initial claim that there is a resource conflict: the conflict is about the capacity of factory process engineers that results in simultaneous release of many tasks from different types of projects into the process engineering department and, subsequently, in their multitasking.
Then the conflict for the factory process engineers will look like this:
D – Do NOW the work for industrializing the new product (for a product development project).
D’ – Do NOW the work for an improvement project.
B and C will be Meet the respective KPIs for process engineers regarding each type of project, and doing NOW work for one project type will endanger the KPI for the other project type.
A will be a statement of the type: “Be a good employee”.
The conflict dilemma does exist. Senior operations management expects results and those results must be for their area of responsibility. The process engineers, while the help where they can, they have to meet internal (local) targets.
Hi Rudi
From the statement above it would mean that it is impossible to get at the same time expected results in an area of responsibility of senior managers and expected numbers according to the internal targets by process engineers.
The two – having results and meeting internal targets – cannot be necessary conditions for the same system because necessary conditions cannot conflict with each other.
Necessary conditions of the system as a whole … the company do not conflict.
But subsystems (production) is also a system on its own (operates as an independent system) because of the way targets such as cost, quality, efficiency are set.
What I think you are talking about is the conflict is easy to solve… because first of all the company necessary conditions must be met above all. Any so-called necessary conditions a department may have must subordinate to that. The problem is, of course, that in many environments this subordination does not exist.
So far I have process engineering management on board that prioroity must be given to company needs/goals (the necessary conditions); the priorities would then be clear. The question I then got … who will tell the COO?
I think I will soon get a day with the C-level (including the COO) at which point I can get such points across.
I enjoyed reading that, how you moved between clouds to understand the situation!
I don’t work in Manufacturing, but we have a similar situation in software-intensive businesses where I do work, though the situation is somewhat different. Some of our changes are 100% technical and all that happens is that software code moves from a development environment to a production environment. Those sorts of changes are usually automated nowadays, but newer businesses or less mature teams often have to hand-hold the technical changes and do a lot of manual jiggery-pokery; they also do the changes in the middle of the night to avoid day time downtime.
Many changes, though, require a lot of coordination with non-technical people – training the most obvious example – an those changes require managers and workers in “the business” to take time out from their normal day-job (running call-centres for example). Our problem is that those “business” people have full time jobs and they’re really busy. They’re often reluctant to take the time out to do change, even though they want the benefits of the change. On the other hand, on the technical side we tend, these days, to have teams dedicated to managing these changes.
So, what do we do, to tackle this? A few things.
– More and more, these days, we make sure that our projects are viewed as *business changes* rather than just *technical changes*. The division I work for is called “Technology and change”.
– We include project managers and analysts who are responsible for “business readiness” in our project teams.
– We automate what we can so the changes are quick and as smooth as possible.
– We schedule the changes so that they’re quick and smooth and people are expecting them.
– We sometimes batch up changes if that reduces the impact.
– We sometimes drip feed smaller changes (the opposite of batching them up) so the change is barely noticed.
– We also design our technical solutions so that the change is smoother and causes less friction.
This all sounds rather organised, I suppose, but that’s just where I work. We weren’t always so disciplined and many software intensive businesses aren’t.
Hope that helps 🙂
In my mind when there is a choice of things to do and resources choose the wrong things there are 3 possible causes:
1) Prioritisation is not clear. In the case above it sounds like prioritisation is departmentally based rather than business based. So we are likely to have 2 prioritisation processes in place.
2) Priorities are all red hot urgent, therefore there is no priority.
3) You have the wrong people in the organisation – generally not the case because people generally want to do well and the way we measure them has a significant impact on the way they behave.
So assuming case 3 is unlikely we are left with cases 1 & 2 to resolve. We could get into lots of discussions about conflicts, dilemmas and behaviours but ultimately choke release is the answer. If Process engineering is the constraint resource have a buffer of work in front of them, but only release the work to execution in the sequence that is best for the company. Do not allow any process engineer to be working on more than 1 or 2 tasks at a time. This means management of development and production need to be aligned and be controlling the release. Resource management also needs to be managing each individuals WIP and keeping it to a minimum
These problems are quite often brought about by the management paradigm of the more we feed in the more we will get out. It is this paradigm that needs challenging not the way the process engineer behaves. Trying to feed in to the system more than the system can process will always lead to delays.