If an Injection is a solution you knew BEFORE you built the Cloud, why did you need the Cloud?

15 January 2017, Jelena Fedurko

I quite often see Clouds that were built after a person has read a TP book/teaching material. Looking at the solution presented in the Injection box I often ask the author, ‘Hadn’t you thought about this solution or discussed it BEFORE you built the Cloud and recorded this solution in the Injection box?’

If the Injection IS WHAT YOU KNEW WITHOUT THE CLOUD, what was the value of building the Cloud, surfacing assumptions and challenging them?

The cloud is the TOOL FOR FINDING A SOLUTION. And it is not a final tool, because the Injection that was derived with the help of the Cloud is nothing more than raw material for checking that the solution meets the important needs (B and C), and for trimming whichever negative consequences may arise as the result of implementing the derived solution.

If the diamond structure of the broken Cloud presents an Injection that the person had been contemplating before they recorded the situation in the Cloud, it is likely that the person substituted (often unintentionally) the Cloud’s purpose of finding a solution by a purpose of justifying the solution that they had known or contemplated before.

In such cases the Injection will sound as one of the conflicting actions with a slight addition or clarification. The assumption which served as the basis for this Injection will sound as a mere repetition of the arrow connecting the conflicting action to the need (which is a typical mistake in surfacing assumptions), or as an argument supporting this conflicting action that is recorded in the assumption box between D and D’ (also, a typical mistake).

The Cloud CAN be used as tool for justifying the solution/persuading, but AFTER IT HAS SERVED ITS PURPOSE OF FINDING A SOLUTION.

To avoid misunderstanding regarding the objectives of the Cloud, here is the exchange between me and Ian Heptinstall in our Facebook group TOC Practitioners Worldwide on 16 January. Ian, many thanks!

Ian Heptinstall Jelena, are you suggesting that it is not worth using the cloud to check an idea one has for a possible solution, or are you suggesting that you need to take more care in writing it, and to properly surface and test all your assumptions?
 
Jelena Fedurko Hi Ian Heptinstall, thanks. No, i do not suggest that it is not worth using the cloud TO CHECK an idea. But then it is a different approach and the Cloud is RECONSTRUCTED – like in reverse engineering. Then you ask, “If THIS is a solution, then what is the problem?” In TOC a problem can be represented by a conflict/dilemma, an UDE, a perceived negative outcome, or an obstacle. If the problem is a conflict, dilemma, or UDE, one can use the Cloud. But as you are correctly saying – then the conscious objective is TO USE THE CLOUD TO CHECK AN IDEA. In the blog I was speaking about the situations when people are aware of the problem, decide to use the Cloud to sort it out, spend time on writing it, and then put the known solution as an Injection. As I wrote – in such cases as a rule you cannot find assumptions that would lead to this injection.
Regarding ‘testing assumptions’, yes all assumptions should be carefully tested before being accepted as raw material for developing injections. Thanks!

Comments

Jelena Fedurko, 15 January 2017

 

2 replies
  1. Jelena Fedurko
    Jelena Fedurko says:

    Here is discussion in our Facebook group TOC Practitioners Worldwide 16 January 2017:

    Cidce Net: I don’t recommend building a Cloud from a perceived direction for a solution to such Cloud. If the conflict exists and it is a valid conflict then there will be many assuptions on each side and a direction for solution will emerge. Building a Cloud form a preferred injection (bacwards) will more like forcing the Cloud to justify the injection and difficult to validate the conflict. With experience one may be able to identify a similar conflict than one worked before and try to jump to the preferred injection from other Clouds, but doing so also risks not overcoming resistance to change in the process. One of Goldartts pillars is “never to say I know”.

    Jelena Fedurko: “Cidce Net, thank you. I would disagree about not recommending building the cloud to check the perceived or suggested solution. It is not only that it is not bad to check the justification of a suggested action, it should be done before the action should be taken. Very often, top managers are bombarded with all kinds of initiatives and ‘break through ideas’, which are suggested by people who do not know the Cloud, and who came to their ideas through their own thinking algorithms. To reconstruct the cloud to find out IF THE SUGGESTED SOLUTION IS REALLY JUSTIFIED is a very healthy way to ensure that managerial efforts will not be spent for nothing or for very little benefit.

    Cidce Net: All one needs to ask is Why do you want to do that? Also, find someone who does not agree with such recommendation and ask Why? It will lead you to the conflict from which to build the Cloud and then find the one or more injections to solve it.
    Remember no two organizations are the same and no two managers are the same even if they are twins. Also, not all proposals presented necessarily reflects conflicts, and some could just be evaluated from impact on T, OE and I.

    Jelena Fedurko: Cidce Net, Actually “why do you want” is the question that leads to describing all the history and usually is not helpful. I have found it more productive to ask the question ‘What do you want to achieve with this action/solution?’ I would not agree with checking justification for the suggested solution by searching for someone who may disagree with this direction.

    Cidce Net: I agree that the why could be rephrased as to what is it to be achieved.

    Jelena Fedurko: Cidce Net, can I ask who I am speaking to? If I understand it correctly, Cidce Net is the name of the company or a group

    Cidce Net: Correct. My firm is CIDCE Net. My name is Michael Bolaños Davis.

    Jelena Fedurko: Hi Michael 🙂
    I agree with you that not all proposals present conflicts. I was saying in my response to Ian that any solution is a response to a PROBLEM, and a conflict is only one of the forms the problem manifests itself. I also listed an UDE, an obstacle, or a possible negative outcome of something,

    Cidce Net: Hi Jelena… glad to chat with you.

    Jelena Fedurko: I fully agree it would be waste of time to write the Cloud (or any other logical structure) if you know how to treat this type of situation. We do not write clouds when we get thirsty, we just go take a drink that we like or that is available. Evaluating the solution from T, I and OE is a part of the evaluation process to decide whether you should go for this solution or not.
    The difficulty with evaluating through T, I and OE is that you are speaking about the future, and estimated T is nothing more than forecast. I was speaking about checking the justification of the numbers “promised’ by the forecast.

    Cidce Net: My only concern is that when one pre-decides on a direction for solution (idea or proposal) and from there prejudges the conflict and then builds the Cloud to justify it, you run the risk of forcing the Cloud to reflect a not so valid conflict. Any injection for a not valid conflict will generate more disturbance to any system and increase any resistance to chnage. Validating a forecasted impact on T, OE and or I is not a systemic conflict, so why imply the use of a Cloud for it?

    Jelena Fedurko: I agree with you fully about the danger of using the Cloud in a manipulative way. Therefore, I was stressing that this type of work should be done “TO CHECK THE JUSTIFICATION”, and NOT to “JUSTIFY”.
    I would not use the work “prejudges” referring to understanding the conflict in this context. This thinking work is valuable to understand how the problem (that is suggested to be solved by this solution) MANIFESTS ITSELF IN THE REALITY. If one cannot clearly outline the problem and show it logically, I would say that the suggested solution serves a different purpose, self-realization of an author, for instance.

    Cidce Net: There is a saying in English that states: “be careful of what you ask for, you may get it”. If you aim at justifying an idea, you will find a way to do so, but that does not means that it will solve a real problem. If you can identify the problem or conflict, then you have the starting point for a Cloud.

    Jelena Fedurko: Michael, again, I did not say that any solution is an Injection to a Cloud. I was saying that it is an answer to a problem, and it is important to understand what is this problem, how it manifests in the reality and to check that the suggested solution sorts it out. In majority of cases, it does not, at least not to the expected outcome. because it has not been justified.
    Michael, by saying “be careful of what you ask for, you may get it”. If you aim at justifying an idea, you will find a way to do so” – you did not mean to say that an idea that will require spending time and money and effort of people in an organization (or family) should NOT be justified?

    Cidce Net: Be open-minded though, because once you have a Cloud you may find that the perceived solution is not the best. No… the saying in English that I quoted means that when you ask for something that you don’t really want or need you will have more problems if you get it.
    We see this very often in most companies when some interesting ideas are implemented without understanding the impact it will have in the system and then having to live for years with such a decision.

    Jelena Fedurko: That’s correct that the Cloud may show that you don’t really have the grounds for the suggested solution. But this is good, not bad. That IS the purpose of the reconstruction work, if you decide to do it. It is much better to ‘catch’ the half-baked or irrelevant solution before we start putting time and money into its implementation. Again, to reconstruct the cloud makes sense only if you are unclear on the justification of the solution (in most cases it is someone else’s suggested solution) and you want to CHECK. Not to ‘massage’ the cloud to force the suggested solution on the organization. Actually, this is what the post in the blog was about.
    Re your “We see this very often in most companies when some interesting ideas are implemented without understanding the impact it will have in the system and then having to live for years with such a decision.’ – I agree absolutely. And it is lucky if an impact of such an ‘interesting idea’ is not disastrous and allows the company to live with it for years.

    Cidce Net: Correct. My comment are more as warnings than rejections. I personally prefer always to identify first the conflict and then work from there.

    Reply
  2. Jelena Fedurko
    Jelena Fedurko says:

    Here is a continuation of the discussion with Ian Heptinstall on 16-17 January 2017

    Ian Heptinstall: Jelena, are you suggesting that it is not worth using the cloud to check an idea one has for a possible solution, or are you suggesting that you need to take more care in writing it, and to properly surface and test all your assumptions?

    Jelena Fedurko: Hi Ian, thanks. No, i do not suggest that it is not worth using the cloud TO CHECK an idea. But then it is a different approach and the Cloud is RECONSTRUCTED – like in reverse engineering. Then you ask, “If THIS is a solution, then what is the problem?” In TOC a problem can be represented by a conflict/dilemma, an UDE, a perceived negative outcome, or an obstacle. If the problem is a conflict, dilemma or UDE, one can use the Cloud. But as you are correctly saying – then the conscious objective is TO USE THE CLOUD TO CHECK AN IDEA. In the blog I was speaking about the situations when people are aware of the problem, decide to use the Cloud to sort it out, spend time on writing it, and then put the known solution as an Injection. As I wrote – in such cases as a rule you cannot find assumptions that would lead to this injection.
    Regarding ‘testing assumptions’, yes all assumptions should be carefully tested before being accepted as raw material for developing injections. Thanks!
    Ian, did I answer your question?

    Ian Heptinstall: Hi Jelena, yes you did answer it. The scenario I had in mind was slightly different. I wasnt thinking about injection a KNOWN solution, but an intuitive one. A known idea is unlikely to be the right one, because of it was a good solution, the cloud would already have been evaporated!
    With a balanced team and a robust process, I think the cloud can be used to test an idea…so long as you are willing to throw it away if it proves not to fit with the logic, or if a better injection becomes obvious.

    Jelena Fedurko: Ian, thanks. Yes, I am in complete agreement with you that the Cloud can be used for CHECKING justification of an idea. However, I am not sure that there is a difference between a ‘known’ Injection and an ‘intuitive’ Injection. The moment the idea is captured as a thought – it is ‘known’. To check it (you use the word ‘test’), one may reconstruct the Cloud. But if it is checking/testing of an idea – the process will still be as I described earlier: If THIS is a solution, then what is the problem? How does this problem manifest itself? Through what conflict or through what UDE (if one wants to use the Cloud)? The moment one has a recorded the conflict, the door is open for constructing the Cloud as a dilemma cloud or as a two-sided conflict cloud. If the problem is presented as an UDE – it is the process of an UDE Cloud that will result in the cloud. Do you agree?

    Ian Heptinstall: Yes I do Jelena. I think when trying to construct a cloud, I find it hard to keep the mind from leaping around and starting to have ideas. That is why the process is important, so that when the time comes to consider the idea for a possible solution, then it can be looked at dispassionately. Either “yes ot seem to fit with the analysis”, or “no, that won’t resolve it”.
    I think what is needed is the rigour and self confidence in applying the process.
    I guess many TOC implementations go through something like this. The chances are that DBR, sDBR, CCPM, etc will be of value, but first we need to ensure that this particular organisation does have the generic conflict, as a root cause, and that there are no other unique UDEs that change the fundamental issue?

    Jelena Fedurko: Ian, you are’ raising an important issue regarding the process of working with the cloud. If it is a structured work, then the stage of developing/looking for an injection is after the assumptions have been surfaced, you take assumptions one by one and start recording your thinking with which you challenge each assumption. Usually, after a few sentences one starts seeing the direction in which to develop an Injection. In this sense, it SHOULD fit the analysis since it is the logical outcome of it, However, since the matter that we analyse in the cloud is significant for us (otherwise we wouldn’t go for all the logical work), we cannot switch off our head, and keep on thinking about the matter also when we are not working with the Cloud. Then, yes, when an idea comes – it should be checked through the needs and assumptions – does it fit with the analysis?
    And my thoughts about the second part of your comment – “The chances are that DBR, sDBR, CCPM, etc will be of value, but first we need to ensure that this particular organisation does have the generic conflict, as a root cause, and that there are no other unique UDEs that change the fundamental issue?”
    Yes, any TOC logistical solution is the solution of a problem. This problem manifests itself in a set of UDEs. If the company operates in the area for which the solution was developed, and the company has those UDEs that the solution was built to remove , then yes, the solution will work. What you call a “unique UDE” – will require a further development of the standard solution, What I would think of a factor that can change the fundamental issue is not an UDE in the logistical area, but a deep conflict of interests between the equally influential parties in the company, or some business practices that do not fit the solution, Both are obstacles for the implementation, rather than system UDEs.

    Ian Heptinstall: I was thinking not so much changing the fundamental issue, but maybe an additional set of circumstances (like the shoulders of giant idea, where there is some overlooked aspect)..An example in projects is when most of the work is done by contracted 3rd parties. CCPM, and the core project issues are still there, but contracting practices also have to be taken account of. They create a whole set of different UDEs.

    Jelena Fedurko: Agree absolutely

    Reply

Trackbacks & Pingbacks

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply