I define Strategy (with capital S) as a plan to achieve more of the goal. The technique called Strategy and Tactic Tree (S&T) is nothing more, but also not less, than a format where the plan can be articulated, including all the intermediate objectives (IO), the actions required to achieve them and the assumptions behind.
The need for such a format is that any Strategy has to include many elements that have certain dependencies between each other. When Marketing comes with an idea that hopefully would bring high demand the resulting question is whether Operations is able to deliver according to the market expectations. Another question is whether other sales are going to be impacted. Many other possible dependencies exist that should be considered in the planning. The format of a tree gives a better view of the map of the linkages between different IOs and their related actions than a document or even the HTML format.
See for instance the following basic tree describing a generic structure of a part of an S&T. The term DCE stands for “decisive competitive edge”, a critical element for delivering unique value to potential clients.
Within the S&T structure every function in the organization sees what is required to achieve and how to do it. At the same time every one can see what should others do in order to reach the desired objective(s). Ask yourself whether this is the current situation with your organization.
Another great insight by Goldratt is separating the intermediate objective from the actions to be taken. The above figure shows the basic tree of “strategies” (same as intermediate objectives). Within every single entry the planner has to clearly define the actions to be taken and the assumptions stating why the strategy (IO) is necessary and why the actions would achieve that strategy. We have now enough experience to testify how constructing the tree, verbalizing both the objectives and the actions and justify them through a set of assumptions, improves the completeness of the Strategy and makes the probability of achieving it higher.
However, the S&T is still just a format. The ideas, the analysis of their impact and the ability to manage the execution are not impacted by the use of S&T. It is my strong conviction that the intuitive Strategy has to be in the mind of the key people in the organization before coming to put it into the S&T format. Most certainty the key decisive competitive edge ideas have to be already clear. Discussing the various options to move the organization have to be completed by the time the detailed S&T planning starts.
I believe going to plan the gross Strategy using the S&T format yields much higher probability for success.
I’m not going to teach here the S&T. You can learn it online at www.harmonytoc.com. I advise you to go through it!
There are two different limitations of the S&T that I like to note and discuss. Before that I like to state my observation of a seemingly obstacle that I don’t think truly exist.
The perception given is that writing the S&T is a sensitive mission that requires high expertise!
This is NOT the case! I’m against being too overly careful with the verbalization and the statement of the assumptions. Personally I don’t care whether an objective is verbalized in the most effective way – as long as the key people of the company understand and agree to the underlining meaning. I think too many TOC consultants and practitioners get frightened by the difficulty. Sorry, I think that outlining the S&T is straight-forward, and even if you made a “mistake” and write an entry not in the right level, or write it in too long sentences – I don’t see the damage.
The limitations I do see:
- There is a certain ambiguity in the linkage between the low level entries and the higher one. The question is what is achieved when only some of the lower level objectives have been completed.
Suppose entry 2.1 has been successfully achieved, what is the impact on entry 1? We cannot expect to achieve the full high level objective. But, shouldn’t we gain something at the high level? The linkage does not state it. The only valid assumption is that when all three low objectives have been completed then we get the full high level objective. As every plan has to include signals for the execution phase that indicate how well, or not so well, the plan is progressing – those signals are missing from the basic S&T format. The expectations from partial completions have to be somehow attached to the S&T.
- The S&T does not include buffers!
I do not necessarily refer to time buffers. Some think that the S&T should have a due-date, or a lead-time, to be fully completed. The value of such a due-date is forcing commitment on all the key players. In itself the due-date does not mean anything. If my stated lead-time for the whole S&T is four years, then completing it in five years might mean less benefit, but then it also depends not just on the time, but also on the quality of the achievements. Generally speaking we like to achieve the plan as soon as possible.
Suppose you find out that low objective 2 proves to be too tough to achieve. Does it mean that the high level objective cannot be achieved? Does this mean the whole S&T cannot be achieved?
Sometimes all we lose is just somewhat less effect, but the Strategy is still intact. On top of that in reality we do have alternatives. The format of the S&T is not friendly to introduce alternatives like “Alternative low objective 2”, which might yield less spectacular results for the high level objective, but still keep the overall Strategy in place. Planned alternatives are buffers that protect the whole plan from being stuck.
The bottom line from my perspective:
Planning the overall Strategy, including identifying at least one DCE, is the most important mission of top management.
The S&T significantly improves the effectiveness of the Strategy and also provides superior communication of the Strategy. Understanding both the benefits and the limitations, as well as keeping an open mind, are required to support this critical mission.
Eli Schragenheim 
Mr. Eli, thanks for your new post , which I really enjoyed.Actually for our system is very important to keep an eye between our S/T tree, developed some year ago with Mr Fernandez’help and the most important changes in Creatum way of operating its system as a hole. I wish , we will see soon in Medellin by the 7/3. Best regards, Alfonso Vélez.
Enviado desde mi iPad
> El 23/1/2016, a las 4:14, Eli Schragenheim escribió: > > >
LikeLike
What a great article Eli! Time for us to work on that limitations
LikeLike
Thanks, Eli, for sharing your thoughts and wisdom with us. I think this is the only critique on S&T I have come across so far. None of the articles from TOC Handbook (or elsewhere) address these deficiencies as well as you did in this post.
I can agree with both limitations.
I do think, however, that an S&T tree is translated in a master (change management) project, which contains smaller projects. Each project is (according to the CCPM logic) time buffered, which may not be obvious in the S&T tree itself, but is explicit within the CCPM logic applied in project planning and execution. Furthermore, my experience shows that an S&T tree does not take 4 years to implement; short term results of implemented TOC tools (DBR, CCPM, logistics solution etc.), the left part of an S&T tree, kick in very early on. However, the right side, usually the sales, take longer. But 4 years should be sufficient.
So, the question remains: where in S&T tree should we take into the account (time) buffers?
As to the first limitation, what if not all S&T boxes are not implemented (fully)? Will the top goal nevertheless be reached? Again, I think that yes (to a degree) as it depends which S&T boxes are missing. From available research on success of S&T vs. other change management methods (Barnard, 2010 (TOC Handbook, Table 15-1, pp. 409); Mabin, Balderstone 2000 (The World of the Theory of Constraints: a Review of the International Literature)), one can only deduce that even not completely implemented S&T trees still yield (better than other methods). But maybe we need more documented S&T cases and have them validated by external, non-TOC auditors.
Keep up the good work!
Mark Stemberger
PS: I would like to hear of more evidence of S&T success worldwide. Do you have anything more recent than 2010?
LikeLike
Mark, success stories can come from an implementation of a very good Strategy. The S&T is just a part of the Strategy, the main question is how well the content is. I agree with you that we need more documented cases of implementing Strategy in the TOC way, preferably with a written S&T. It is quite difficult to get an agreement from an organization not only to declare the success due to TOC, but also to reveal the details of the Strategy and its detailed planning.
While implementing the full detailed S&T could be planned to take four years or less, the S&T has to be extended all the time to eventually achieve the state of ever-flourishing organization. So, the maximum we can hope for is to have documentation of initial S&Ts along the detailed actual achievements. I assume in all such cases several entries have been replace or updated relative to their original state, because some of the initial assumptions have not been fully valid.
LikeLike
Eli, thanks for your reply. I can only concur with you as I have similar experience with S&T conception, development, communication and implementation. I shared our success story (of our S&T tree) in my presentation in Washington 2014, Sales restructuring delivered. Our S&T tree actually started after we crafted our own strategy, visualized it and tested parts of it in practice. Then S&T tree systemized the (strategy) process and converted our strategy into logical, manageable, correctly sequenced subprojects. All managed in Concerto.
We even used S&T tree as an audit tool and performed yearly the S&T tree audits (for four years). What we lacked, looking back upon this wonderful experience, we missed properly documented changes and upgrades of S&T trees. The process was there, but we lacked the tools and proper methods (i.e. Action Research) to document, improve and accelerate this process.
I would love to learn more about such cases and would appreciate if you could share them with me.
with best regards
Mark Stemberger
LikeLike
Hi, Eli. I was introduced to your website (and the very interesting S&T construct) by Mike Hannan. As I see it, the work breakdown structure is — or can be — one form of S&T. But the S&T concept is much more universal.
You wrote above: “The expectations from partial completions have to be somehow attached to the S&T.”
This is so interesting to me because it relates closely to issues encountered in the value breakdown structure (VBS).
http://en.wikipedia.org/wiki/Value_breakdown_structure
The WBS seems like an S&T that is developed but then used primarily for the input of costs. Your article makes an S&T for any endeavor much more important, and the above sentence about expectations suggests value. The numbers in a VBS, unlike a WBS, are not simply additive up a branch, and that seems to me to be what your are saying above about an S&T.
Perhaps the next step is to estimate the value contribution of each “twig” to its parent “branch”? If so, one thing that I have discovered is the significant difference between two types of twigs and branches: mandatory and optional. Mandatory branches/twigs have a value equal to the entire effort, whereas optional have only a value-added (which can, however, sometimes be very large!). This suggests that if we are talking about a project/program, mandatory and optional should perhaps be managed in very different ways.
I will continue to follow your blog articles which I find very intellectually stimulating.
Steve Devaux
LikeLike
Steve, your remark about a work break-down structure (WBS) or value break-down structure makes sense. To a degree. There are other similar tree structures (to S&T trees) that you can study and compare to the S&T logic, e.g.:
Du Pont analysis of value creation, dating from 1920s
https://en.wikipedia.org/wiki/DuPont_analysis
or
Balanced Scorecard concept
http://balancedscorecard.org/Resources/About-the-Balanced-Scorecard
or
Key Performance Indicators
http://balancedscorecard.org/Resources/Blog/ArtMID/2701/ArticleID/1041/The-Ultimate-KPI-Cheat-Sheet
However, if Goldratt and the TOC community insist on taking the holistic view of an organisation, I find other approaches (i.e. BSC or Du Pont or KPI) too analytical, too local focus oriented; their prevailing wisdom appears to be to improve everywhere (all the components (!)), all the time, as much as you can. This is exactly opposite of focus(!), the S&T tree and TOC logic which aims to a global optima, measuring and comparing each action against global T, I and OE.
Furthermore, TOC is relentless in using the cause and effect logic which I have not seen (to the same extent) in other approaches. With every S&T box you need to answer (and validate basic assumptions about that particular box (NA, PA and SA): necessity and sufficiency logic.
See here: https://www.harmonytoc.com/How-To-Guide
Only thus makes an S&T tree sense and stands a chance to be successful in (i) conception (similar to other concepts) , (ii) implementation (approach is very prescriptive unlike other concepts) and (iii) an organisational audit (I have not seen other concepts to be used for the same purpose).
I hope this helps.
with best regards
Mark Stemberger
LikeLike
Steve, I agree with Mark’s comments that while there are several uses of the tree format outside of TOC BOK, TOC uses it holistically and with an emphasis on cause and effect. I like the distinction Steve does between mandatory and optional twigs and branches. In my vocabulary I call them “must have” and “nice to have” and they are important also for the S&T to know whether they are absolutely critical or just valuable enough to include. I expect that the “Necessary Assumptions” in any S&T entry should clarify that point.
When I wrote about expectations from completing one entry, but not all required for the higher level, I meant not just the net value but also whether we can see a signal that the implementation goes well or not. So, we might complete an entry, but at least one entry that is “must have” have not been completed so far. We cannot expect that the high level entry would be reached – but, can we still see “something” that testifies that once we complete the other “must-have” we’ll reach the higher entry? I assume the answer could differ depending on the case, but I think we need to verbalize the expected signal that the implementation goes well or not.
LikeLike
Thanks for this, Eli–I particularly like what you say about S&T Trees not requiring high expertise (though they may well benefit from it). Many TOC practitioners seem to hold this “don’t try this at home!” perspective, when in the end it should be driven by well-honed intuition and sound logic, which are available to us all.
As for limitation #1 (lack of clear value linkage between the levels), there is something to Steve Devaux’s mention of the Value Breakdown Structure (VBS). For those unfamiliar with a VBS, it requires the logical assignment of value to each component of program/project scope (and the S&T Tree can be used as a program or project scope statement–i.e., what must be done in order to achieve the strategic goal). So, the roof of a house = the value of the entire house, because the house is worthless without it.
Or is it? Perhaps there is still some redeeming value of a house without a roof, just as there may be some redeeming value of a Strategy even if one of its critical components is missing, Similarly, the lack of a roof might open up alternatives–or as you mention in limitation #2, the S&T Tree’s lack of buffers (or “scope alternatives” in this context). Continuing with our roof analogy, perhaps a temporary tent-style roof might allow for better air-flow in summer, along with the benefit of star-gazing on a clear night, while costing less than a permanent roof. As you point out, the S&T Tree construct wasn’t designed to handle this, but as Steve Devaux points out, this is exactly what the VBS was designed to address (and he should know, as he’s the one who designed it 🙂 ).
In my mind’s eye, the S&T Tree could easily be enhanced to incorporate VBS logic here, just as a Work Breakdown Structure (WBS) is easily enhanced to incorporate VBS logic. All that’s required is a value ascribed to each S&T Tree component as relates to the value of the Strategy as a whole. Just as the S&T Tree is really valuable in helping everyone see how their part relates to the whole, it would be even better if it showed in value terms how each part relates to the entire envisioned value of the whole Strategy. In practice, it’s just an extra step, with an extra field to be filled in, no more complex than answering the “what’s the value of the house if there’s no roof?” question.
There remains the issue of flexibility with such “roof alternatives,” both in the S&T Tree and in the VBS. How might we incorporate such alternatives, especially if there are dozens of them? When is it even worth doing this, and when is it not? I think the answer is in the regular revisiting of the S&T Tree as it is being executed, just as we do to the VBS as a program/project is being executed, in concert with risk/issue analysis. We may well start with a clear plan for a traditional roof, and consider that as the obvious best-bang-for-the-buck scope option, but if we run into issues during execution, we challenge the team to come up with alternatives that might be perfectly viable and valuable…and who knows, might even yield better bang for the buck than the original roof option (especially for us star-gazers! 🙂 ).
In the end, the S&T Tree is a model of our own intuition and logical thinking, both of which flex as experience is gained, as some assumptions are proven out in practice, and as other assumptions are discarded if they fail to check out as tightly as we originally envisioned.
So on limitation #2, while the S&T Tree was not designed to allow for myriad alternatives for a given component, swapping out that component for another is far easier to do with a well-developed S&T Tree than if we’d never built one at all in the first place. And on limitation #1, adding a value assessment of each component as it relates to the whole (as the VBS teaches us) seems like a simple and straightforward injection…even better, it can encourage the team to verbalize its own understanding of the value of the Strategy in the first place, and on how each component contributes to that value. Valuable stuff, indeed!
LikeLike
Mike, you have explored far beyond my shallow thoughts! I am still learning about the S&T Tree, which seems to me a very flexible and useful contruct.
I originally conceived of the VBS as a project management tool, and I do believe it has value there. However, I later realized that the VBS can acquire even more importance at the program level, with the projects and the value they add to the program being the second level (i.e., as I might now say, the “tactics” through which the program “strategy” is achieved).
The VBS adds a lot to the program framework because the sequencing of projects in a program is often not based on “logical dependencies” but on maximizing value. For example, Leonardo could perform a project to create a parachute — but it added little or no value until humans routinely achieved heights that could benefit from a parachute: projects to create balloons, airplanes (which also required the internal combustion engine project), and the “operations process” of aerial warfare. Sequencing the projects in a program in such a way as to maximize value is definitely aided by a VBS.
However, now that I have discovered the S&T Tree, I think it’s an *essential* construct for a program! Programs are being performed haphazardly, without sufficient consideration of value and organized direction. The S&T Tree (*with or WITHOUT VBS information*!) would seem to me to add greatly to planning and organizing process (not to mention the periodic re-planning and re-organizing process, which as Mike suggests would be both easier and needed less frequently if an adequate S&T Tree is initially created).
Steve Devaux
LikeLike
Mike and Steve, just to emphasis the point that I agree that VBS is beneficial, but even when completing an entry does not achieve the value until another entry is completed we better have a signal whether what has been achieved seems right and no warning signal is located. So, before you put the roof you need to know that so far the construction is fine and no signal for any problem is seen.
We need an alternative in cases of Murphy, or when a critical assumption is shown to be invalid. For instance, there is a step of getting a loan from the bank. What happens if the bank refuses? Is there an alternative? I agree that when this happens we could look for an alternative, but at that point of time we are under great pressure and then we might do a major mistake. So, planning certain alternatives for specific entries where we suspect might not work the way we need in order to go ahead, we better plan the alternative as part of the original plan.
LikeLike
On alternatives to address Murphy (limitation #2), I agree that we would do well to identify such “Plan B” items/activities earlier vs. later, when we still have time to do something if Murphy strikes and Plan B suddenly becomes Plan A. Not sure if modifying the S&T Tree somehow would be the best way to examine such alternatives, especially if they are numerous, but perhaps a small number of alternatives on particularly risky components might not be so hard. Maybe a modest modification to HarmonyTOC is all that would be required in that case (and until then, saving slightly different versions of the same tree as a workaround).
More exciting to me is the power added to S&T Trees by adding a simple field for the value that any given S&T entity lends to the larger strategic objective (overcoming limitation #1). As an innovation to basic project management, the benefit of adding such value assessments to a given scope element of a WBS has been enormous (if far from common practice), so it stands to reason that the value to an S&T Tree would be far, far bigger.
The roof example I cited in my last comment, while fun, might not have conveyed just how valuable this concept could be when applied to an S&T Tree. So, consider instead an IT project that has “software testing” as a part of its scope. Seems like a pretty important scope element, right? But if we skip it, have we lost the value of the entire project? Even if the value is dramatically lower due to buggy software, might the speed benefit of skipping testing deliver so much additional value that the lost value is more than recovered? The answer, of course, is that it depends. But standard practice doesn’t even ask us to look at it with a value-trade-off mindset, even though maximizing value is what we’re doing the project for in the first place.
The same goes for S&T Trees, only with potential for much higher impact. If we’re able to assign a value to each component–even components that seem as non-negotiable as testing software or putting a roof on a house–we might find that sometimes it’s even more valuable to a strategy to omit them. Unless we assign value estimates to each component of the S&T Tree and do the value-trade-off analysis, we have no way of knowing.
Steve and I were already planning on submitting an abstract for this year’s TOCICO showing revisions/enhancements to the Projects S&T Tree…now we have a valuable additional enhancement to include and specify more fully, stimulated by the challenge posed by limitation #1 identified in this post!
LikeLike
Mike, I certainly agree that such a feature is very beneficial and I like the idea of you and Steve presenting it in the TOCICO conference.
I have one question. When the value of the entry is not deterministic -what exactly do you put?
Take your example of “Software testing” as an entry in an S&T. I assume the Necessary Assumption would state that without proper testing bugs in the software are possible and they could cause huge damage to the user, sometimes even to force the user to stop using the software until the bug is fixed. Sometimes, the bugs revealed are not large, and the testing itself adds two months to the total lead-time. What exactly do you state? What is the value of carrying the software testing? Anything between $5000 and $5M?
LikeLike
Hi, Eli.
First, let me say that I just read your article on Marketing the Value of TOC. Bravo! I feel that my response below (to your question above0 is also related to that thread.
“I have one question. When the value of the entry is not deterministic -what exactly do you put?”
Projects as investments, requiring rigorous application of game theory. Their management, of scope, cost and schedule, should rely on decisions based in Bayesian probability analysis. Are there times when a value entry is deterministic? Yes, but very rarely: a specific liquidated damages penalty for late delivery is one possibility; but even then there may be side effects (bad publicity? Reduced employee morale?) that should be analyzed for their probabilistic negative impact.
If projects are investments, all factors that could impact ROI should be analyzed probabilistically in those terms, not just cost and schedule (as are the usual limits of most project risk management approaches). As an aside, this is exactly the reason why in my books I prefer to use the term “expected monetary value (EMV)” rather than ROI — because the latter is too often (incorrectly!) treated as deterministic.
So, to answer your question directly, the value of the entry should be the output of robust, probabilistic, and *dynamic* analysis of probability and impact. And I emphasize dynamic because, during execution, circumstances may change: value and cost may change, but even more important, schedule may change, causing optional work to migrate to the critical path where its true cost (TC) becomes the sum of its resource costs PLUS its drag cost. Such changes must be monitored and subject to fresh analysis.
To provide an analogy to game theory: when deciding whether and how much to raise in a poker hand, I must: (a) estimate the odds of my winning the hand (odds that depend on a huge number of factors ranging from known cards to human to financial to table location for *each* player); (b) estimate the EMV of the eventual pot (which will depend on variations of the same factors); (c) evaluate the impact the outcome of this hand may have on my chances of winning the tournament; and (d) evaluate the impact that my actions during this hand may have on my opponents’ future assessment of my playing style.
None of the above is simple — yet good poker players are, in real time, making these assessments every few seconds and, in the long run, the one who does this best will likely be the longterm winner.
It seems to me that the current business condition, of failure to perform similar analysis on projects when (i) the value involved (whether just money or also human lives!) is FAR greater and (ii) the amount of time (and computer time!) to reach an evaluation and/or decision is also far greater, is an unfortunate omission in project management practice.
So to respond directly to the specifics of the s/w testing example:
1. “…(T)hey could cause huge damage to the user,..
The value breakdown structure approach is that such potential damage should be quantified on a probability/impact basis. If the risk and potential cost of damage to the project is greater than its EMV, such a project should NEVER be performed without risk mitigation, in which case s/w testing should be a mandatory activity, with value equal to that of the whole project. (This, of course, is why governments and corporations often include mandatory standards, such as pumping water over a fission reactor core for 120 hours during a fuel rod replacement outage. The TC of such work is enormous — but vastly less than the cost to the state of a reactor meltdown!)
2. “Sometimes, the bugs revealed are not large, and the testing itself adds two months to the total lead-time.”
This should be planned and assessed through standard fragnet analysis PLUS drag and drag cost analysis (which of course is crucial, but rarely included with fragnet analysis!). If such analysis is performed showing a 25% chance of adding eight weeks of drag at $100K per week, the drag cost of the risk is $200K. Is the s/w testing now worthwhile? Is the project investment no longer viable? (And of course, changes in these should be monitored throughout execution.)
3. “What is the value of carrying the software testing? Anything between $5000 and $5M?”
If there is a 60% chance of its added value being $5000 (=$3000), a 30% chance of it being $100K ($30K) and a 10% chance of it being $5M ($500K), then its value-added is $533K.
Eli, I am sorry about the length of this post, but I wanted to respond and, as you point out, it’s not simplistic. Mike Hannan has recently read my books and will confirm that I explore all these issues, and many others, in much greater depth there.
But for anyone who isn’t interested in the books, but is unfamiliar with some of the terms above, here are some Wikipedia pages and a 2012 article from Defense AT&L Magazine:
http://en.wikipedia.org/wiki/Value_breakdown_structure
http://en.wikipedia.org/wiki/Critical_path_drag
http://en.wikipedia.org/wiki/Drag_cost
Click to access Devaux.pdf
Your blog is great, Eli. Keep pushing that envelope…
Fraternally in project management,
Steve Devaux
LikeLike
Steve, thank you for your detailed answer. We might engage ourselves in a more detailed debate on how we should treat uncertain decisions, in a way that is simple (otherwise it won’t work) and yields good enough results, plus making sure I’m not hit with a disaster.
I think that the expected-value is not enough for making a decision. I need to know whether I’d survive if a much worse alternative would happen even though the probability is not high.
As you say : “If the risk and potential cost of damage to the project is greater than its EMV, such a project should NEVER be performed without risk mitigation, in which case s/w testing should be a mandatory activity” So, the generic question is how do we consider the expected-value while being careful not to cause a disaster.
In short I’m looking for a practical way, that is good enough even when I cannot associate precise probabilities to every valid outcome.
LikeLike
Hi, Eli.
You wrote: “I think that the expected-value is not enough for making a decision. I need to know whether I’d survive if a much worse alternative would happen even though the probability is not high. ”
I completely agree. I would not take a risk where there is an 80% chance of getting $1 million if there is also a 20% chance of my losing my life. That’s one reason why in my books I recommend that, in the VBS structure, risk factors that involve outcomes that are beyond our tolerance level be made mandatory by being adopted by regulatory or internal standards.
“In short I’m looking for a practical way, that is good enough even when I cannot associate precise probabilities to every valid outcome.”
This a slightly different topic, but it leads to a deep-seated belief of mine: the fact that project outcomes are not being measured correctly. As with EVERY other investment, projects should be measured and judged on the basis of ROI (or NPV or EMV or whatever the preferred term). But this is rarely done, with tangential, and distorting, metrics such as “on time” and “within budget” being used as proxies. Value generation and the value/cost of time are left as externalities.
If the measurements are wrong, the management behaviors will be wrong. And yet the unmeasured parameters will prevent an accurate assessment of the cost of the inappropriate decisions and actions.
To return to the poker analogy, there are two important factors:
1. Incorrect decision-making gets punished. Sometimes it takes a while for a weak poker player to recognize that the bad results aren’t just luck. But an individual is left with two alternatives: recognize your mistakes and improve your decision-making or ‘go out of business”.
2. A weak poker player doesn’t have to master all factors in order to make better decisions and even win his Friday night game. Yes, WSOP champions like Dan Harrington make the right decision better than 98% of the time. But to win your neighborhood game, 75% correct decisions are probably good enough.
In other words, “precise probabilities to every valid outcome” are not necessary in order to vastly improve business decision-making. I completely agreed when in your article above, you wrote: “I think too many TOC consultants and practitioners get frightened by the difficulty. Sorry, I think that outlining the S&T is straight-forward, and even if you made a “mistake” and write an entry not in the right level, or write it in too long sentences – I don’t see the damage.”
In other words, the perfect must NOT be allowed to be the enemy of the better-than-current-practice — and that is true, as you say, of the levels of the S&T Tree, and it’s true of the estimated value of the optional branches of the value breakdown structure (VBS).
You wrote: “Planning the overall Strategy, including identifying at least one DCE, is the most important mission of top management.” That’s it exactly! The S&T Tree should become a state of mind, a way of thinking about the strategy and tactics supported and improved by the S&T Tree artifact.
The same is true of the values in the VBS. And those values, even if not always precisely correct, help to structure correct and disciplined thinking. It’s like making the effort in poker to “put your opponent on a hand”. You may be wrong — but (1) the very effort improves your decision-making and (2) you’ll bet better at it over time.
And the same would be true, I believe, of marrying the value estimation discipline of the VBS to the clearly invaluable structure of the S&T Tree.
And as with ROI-based project management, measurably better results will provide the necessary incentive to further and more disciplined use of such practices.
I guess I’m an optimist.
Steve D.
LikeLike
Steve, I fully agree to every word you wrote here. Making Probability Theory and especially Statistics practical is quite challenging. We need to know how to use approximate and missing information and not to be too hasty in learning from the cases where the result what not we hoped for.
LikeLike