Yeah, problem solving

Most people love to solve problems and feel the satisfaction of getting rid of some nasty tricky problem. It’s an outdated but still lasting belief that management is about problem solving. Problem solving turned in some cases into the managers’ and engineers’ holly mission and in some minds, the more problems the manager/engineer solves, the better manager/engineer he/she is. This kind of problem solving can be addictive, hence the Arsonist Fireman Syndrome.

On the other hand, thanks to Lean Management, enlightened managers understand it is crucial to refrain from solving problems and develop their subordinates’ ability to solve problems themselves instead.

Note that all the above is about problem solving, not problem avoidance or problem prevention. And if today’s problems come from yesterday’s solutions, as stated in Peter Senge’s “The 11 Laws of the Fifth Discipline”, in a world requiring increasingly fast decisions (read solutions), we’ll never run out of new problems to solve.

So what’s wrong with problem solving?

There are at least 2 major issues with actual problem solving practices.

1. Quick fixes

Solutions to problems are most often quick fixes made of the first “best” idea that popped up. Problem solving is not very often a robust and standardized process, systematically rolled out. In fact formal problem solving processes seldom exist even if everybody is claiming solving problems.

If known, simple structured approaches like PDCA are disregarded and ignored, pretending the situation requires quick reaction and not “unnecessary paperwork!”

Often, the problem seem to be fixed, giving credit to the firefighters and reinforcing their belief in their “way” of handling.

It is not really surprising that the same problem keeps showing up as the fixes did not eradicate the problem’s root cause, and the problem itself was never really studied, hence understood.

2. No risk assessment / risk mitigation

If formal and structured processes to tackle problems are seldom, the solutions’ risk assessment is even more seldom. And if the rush to quick fixes leaves no time for properly analyzing the possible problem root causes, no need to mention non-existing attempts to figure out the possible risks these quick fixes bring with them.

Chances are that the ill-prepared and hastily put in place solutions generate unexpected Undesirable Effects. What may fix one problem may well cause one or several others to appear.

That’s how quick and dirty troubleshooting usually come at the expense of later longer efforts to cope with a situation that possibly grew worse, and how Peter Senge’s quote: “Today’s problems come from yesterday’s solutions” makes the most sense.

What solutions?

  • Choose yourself a structured problem solving approach, there are several available. Try it and if proven suitable for your purpose make it your standard way of approaching a problem.
  • Make sure the implemented solutions will really kill the problem by measuring on a long time horizon if the trouble has disappeared for good. The Quality Operating System is perfect for that.
  • Explore the Logical Thinking Process, the sole complex problem solving methodology I know which includes a systematic “Negative Branch” check to avoid or mitigate Undesirable Effects as by-products of the implemented solution.

1View Christian HOHMANN's profile on LinkedIn

Why would I learn to think (logically)?

Most people are convinced of their ability to think logically and don’t see the point of getting a specific training like the Logical Thinking Process  training course.

Indeed, in some extend most of the people have an innate basic logical thinking way, otherwise our world would be pretty weird.

Yet it is also true that many people are unable to structure properly their thoughts and express their ideas with clarity and in a straightforward brilliant logical way. Even so it makes sense in their mind, what they try to share doesn’t always make sense to others.

How many times did you listen to someone and ask (yourself) “so what?” once the speech is over.

The importance of clarity

The first important thing to achieve is to express ideas with clarity. Clarity means that the idea, purpose, objective or goal is expressed in an unambiguous way, letting no room for misunderstanding or interpretation.

Clarity is always important. As an employee to be correctly understood by managers and colleagues and as a leader to be correctly understood by the team members or subordinates.

Imagine the consequences of an ill-stated objective. Stakeholders may misunderstand it and do something unexpected but aligned onto the objective they understood. Such kind of situation can be costly in terms of motivation – the stakeholders are feeling bad about their misunderstanding, resenting their leader for his/her poor objective statement and disappointed for all the energy they put into some action, for nothing – and in terms of resources and time wasted.

Ambiguous or ill-stated objectives are also welcome for some people to smartly escape some chores or refrain to commit to something they don’t agree, don’t want or don’t like. Room for interpretation is also room for later arguing. Something not desirable when some objectives are non negotiable.

Conversely, the inability to clearly explain what has been achieved, why and how it contributes to achieving some objective may make a team member look as a poor performer even so his/her contribution was significant.

It is frustrating to be a brilliant contributor to some project but unable to explain why and how. It is also frustrating to be unable to “sell” a brilliant idea to colleagues, the boss or customers.

Sound logic

The robustness of a cause-and-effect analysis or demonstration is also important in order to convince readers or listeners about the soundness of the ideas expressed.

According to the principles of adult learning, sense and purpose must be fully understood for adults to commit to something. If the rationale of some project or actions asked is not demonstrated in a clear and sound (robust) way, it will invite opponents to fight against it, making use of all “holes”.

Some undertaking presented in a fluffy way with many unanswered questions remaining open is scary. Opponents will have it easy to reinforce the doubts and fears of the audience by pointing out the inconsistencies and “holes” in the reasoning.

Lack of confidence is very likely to turn away customers, stakeholders or decision makers from the best of proposal. Instinctive risk aversion is probably more common than innate logical thinking.

Using “long arrows”

Many people with good logical thinking abilities will mentally cut corners and use “long arrows” in their demonstration. A long arrow is a metaphor for skipping several cause-and-effect steps linking an effect to a cause or the other way round.

While the link exists, it does not appear clearly. The audience cannot understand the rational link between an effect and a cause and may lose trust or interest about the presentation, get stuck because of this logical “hole”, doubt about the reality and validity of the ideas expressed, and so on.

Long arrow example

I have to make a presentation in building n°10, 15 minutes walking from here. It rains. I need an umbrella. I must borrow one.

“Could I borrow your umbrella because I must present my report?” I ask a colleague.

My colleague may ask herself what the link is between presenting a report and her umbrella. She will probably lend me the umbrella anyway, still not understanding what for. I did not feel necessary to explain the whole sequence of cause-and-effect, perfectly clear and logical in my head but strange when expressed that way.

Now imagine asking for commitment to something very important and serious that does not make sense because of long arrows.

Mastering logical thinking is also about avoiding long arrows and being able to detect them. I guess someone trapped with long arrows would be grateful for the help by someone seeing the shortcut and helping to reformulate the idea in a more robust and clearer way.

Mitigate the risk of “negative branches”

Negative branch is another metaphor used in the Logical Thinking Process, were logical relationships are depicting in logical trees. A negative branch is an undesirable effect or chain of cause-and-effect that “grows” from an action or decision taken.

Negative branches are often growing unexpectedly because the action was decided or decision taken without checking the possibility for things to go in an unexpected and undesirable direction.

Some fixes for a problem can result in other problems to arise, sometimes worse than the initial problem that was to be fixed.

Awareness and practice of the Logical Thinking Process hones the ability to “foresee” or at least to prevent negative branches and craft better solutions.


Basic logical thinking is a given and it may appear strange to promote “learning to think logically”. But it is as with many other things supposed to be “common” but aren’t. Common sense for instance is not so common.

Therefore there is a lot of room to improve one’s logical thinking skills.

Once introduced to the Logical Thinking Process, there are daily opportunities to hone one’s scrutinizing abilities. Newspaper, tv news, blog posts, speeches… are not always constructed with sound logic. Fallacious reasoning is easier to debunk, as well as surfacing false assumptions or “insufficient causes” on which some thinking are built upon. Negative outcome can be sensed and hopefully prevented.

Mastering Logical Thinking helps for better analyzing situations, understanding real causes of problem, crafting better solutions and expressing oneself much better.

1View Christian HOHMANN's profile on LinkedIn

Can CCPM reinforce Parkinson’s law?

In this post I share a post-mortem analysis of a situation we’ve encountered while helping a company to improve its performance. This company was specialized in custom-made machine engineering and asked for help to improve its On-Time Deliveries performance. We proposed to install Critical Chain Project Management (CCPM), an obvious choice given the circumstances.

Critical Chain Project Management (CCPM) is supposed to supersede Critical Path Method (CPM) with its capability to deliver projects on time, something CPM has consistently failed to do for more than sixty years now.

Among the obstacles to on-time project termination is the Parkinson’s law. This law – not to be confused with the disease of the same name – states that “work expands so as to fill the time available for its completion”,

The Critical Chain Project Management approach recognizes this specific behavior consisting of refining the work, add unrequired features or perform additional tests instead of handing the task over to the next person in charge when finishing a project task ahead of time.

The main reasons for this behavior refered to as “Parkinson’s law” are that someone finishing earlier will:

  • fear to see the allocated time to achieve the task reduced by management the next time
  • fear to appear unable to give a trustworthy estimation of the time necessary to complete a task
  • enjoy the extra time when finishing earlier instead of being late and under pressure
  • enjoy to seemingly deliver just-in time and as predicted something that is ready and waiting for a while

Critical Chain Project Management being aware of the Parkinson’s law, its proponents educate the project members about the consequences of this behavior and put the relay race principles as well as common project buffer in place.

The relay race principles state that when a task on the Critical Chain is nearing its completion, a signal is sent to the next resource that will take over. This resource is then using this early warning to make sure to be ready on the high priority task that soon will be handed over. This is like the relay runner starting to run when the baton is approaching in order to be at top speed when it’s handed over.

The common buffer is a shared protection of the finishing date made of the sum of roughly the half of all individual protection margins. Please see Introduction to Critical Chain Project Management for more details about CCPM protective buffer.

So far so good. Now here is a developers team that was working in constant hassle, with chaotic and permanent priority changes and countless interruptions. Multitasking was so bad that some of the members could not work on a given task more than 3 minutes in average before the next interruption occurred.

Thanks to CCPM, multitasking was banned, interruptions prevented and focusing on one single project at a time became the new rule. The team members soon acknowledged the positive change and the comfort of getting rid of all the hassle and the multitasking.

Yet top management was not happy because the development team did not deliver more by finishing projects earlier, and taking a closer look concluded that CCPM reenforced Parkinson’s law. Indeed, the team members took it easy and did not really rush to the next priority job once their current task on the critical chain was completed.

What went wrong?

Well, nothing went really wrong, simply putting the system under control and stopping the constant chaos let the true problem show up: the team was not managed.

As long as everyone could influence the work on the projects, mainly sales managers and general manager worrying about the delivery date, someone was giving orders. Under such a pressure the developers managed to push the projects to their completion, even they finished late. As things were progressing, even in a total uncoordinated way, there was a general feeling that the process was delivering.

Once the CCPM rules were agreed and installed, sales managers and the general manager refrained to interfere with development team and developers had their list of priorities to work on. What they did not have was a manager taking care about work intensity (another word for productivity), cadence, challenging for continuous improvement. In one word: a manager.

Without the management’s constant challenge and care, the developers simply laid back, feeling legit to do so after all the years of stress and bad working conditions.

Insufficient cause

Reflecting on this story I realized that the top management was assuming that CCPM principles of stopping multitasking and keep focusing on the critical chain priorities was enough to squeeze out the unnecessary individual margins and consequently speed up the development process. This in turn would allow to increase throughput with the same resources.

In the Logical Thinking Process (LTP) lingo, this is an insufficient cause, meaning that by itself it will not be sufficient to cause the expected effect; increasing throughput.

What we consultants, and probably the general manager, considered a given was that this team was managed. As well this was clearly a Necessary Condition, we felt it was “oxygen”, another LTP term for conditions that are supposed so obvious that it is not necessary to express them, just as oxygen is necessary for humans to breath.


The CCPM principles worked well. The chaos was tamed and the developments could finish within the estimated time, now based on so-called focused durations.

The Throughput did increase, but not dramatically. There a three reasons for this:

  1. First reason is that the increase of throughput allowed new projects to start earlier, but given the average length of a project (10-12weeks), the speeding up was not very noticeable.
  2. Second, CCPM was applied on the work packages without challenging the work package contents nor engaging continuous improvement at once. The local management chose to collect data about buffer consumption first, in order to understand where and what to improve. Given the projects durations, this is a slow process.
  3. Third, there was no incentive to improve due to the lack of team management. This later becoming blatant once all other disturbing factors have been neutralized.

So CCPM did not enforce Parkinson’s law. CCPM did what it is supposed to: set the scene for efficient focused work and deliver the projects on promised dates.

CCPM is no cure for everything and no substitute for failing management.

View Christian HOHMANN's profile on LinkedIn

Samples from LTP training with Bill Dettmer (Day 1)

Paris, June 2016. Bill Dettmer delivers his 6-day Logical Thinking Process training course in our offices. I am attending on the host’s and partner’s side, going through the whole course for the second time (I got my certificate the previous year) as a backup facilitator-if-needed, a master of ceremony, reporter and videographer.

While Bill is sharing his knowledge and experience, I videotape with his consent in order to promote the course and show you samples of what happens during the 6 days.

The following video shows samples of the morning of the first day, once introductions have been made, backgrounds, expectations and motivations of attendants shared.

I am sorry for the poor image quality due to low light, but this is a tradeoff between sharing the experience with the viewers and bothering the course attendants who paid for their seat.

The first morning is spent on some basic theory about the logical relationships, the structure of the different logical trees and how to build them. It paves the way for the afternoon’s exercise in which each participant builds his/her own Goal Tree, then, in turns, presents it to others and have it scrutinized by the others, under Bill’s supervision and coaching.

Bandeau_CH160601View Christian HOHMANN's profile on LinkedIn

Where I could have used a Goal Tree but didn’t know about the tool then

During the June 2016 Logical Thinking Process alumni reunion, Bill Dettmer asked the participants to share their “War Stories”, i.e. experience with the Logical Thinking Process (LTP) and LTP tools.
I came up with several short stories. In this excerpt, I recall I could have used a Goal Tree but didn’t know the tool at that time.

The story I tell is the one that inspired my post Goal tree chronicles – The pharma plant.

View Christian HOHMANN's profile on LinkedIn

Limits of Logical Thinking Process

In this excerpt of day one from the 6-day Logical Thinking Process training course, Bill Dettmer explains that the very front end, the two first tools (Goal Tree and Current Reality Tree) are deterministic, based on facts. The other steps and tools are about future, which can only be based on probabilities.

At the end of this short video, Bill gives his definition of the Logical Thinking Process.

Logical Thinking Process training June 2016 opening speech

Paris, June 2016, day 1 of the Logical Thinking Process training course hosted by Marris Consulting, Philip Marris welcomes the participants with a speech.

Philip’s speech is a mix of teasing and testimony as well as an analysis of the growing relevance of Theory of Constraints (ToC). Philip also explains how the Logical Thinking Process tools help focusing, the core idea of ToC. Finally he shares his thoughts about why the participants are in the room that day: it takes a peculiar mindset to go the Logical Thinking Process way, people do not attend this course by chance.

After more than 16 minutes, Bill Dettmer finally can welcome the participants too.

I was fortunate to attend on the host side to facilitate the 6-day course, also taking care about video and photos of the venue. If you want to see how the 6 days unfolded in fastforward (2 mn), >click here<

View Christian HOHMANN's profile on LinkedIn

3-color system for Goal Trees

In this 5 minute excerpt from the Logical Thinking Process (LTP) Alumni reunion with Bill Dettmer, June 2016 in Paris, France, I explain my 3-color system for assessing the current reality with a Goal Tree.

The 3-color system is a visual management tool to assess the organization’s readyness to achieve its Goal and shows where to act in priority.

You’ll find several articles on this topic here on my blog, for instance:

Bandeau_CH40_smlView Christian HOHMANN's profile on LinkedIn