Tag Archives: Problem Solving

Are you thinking about solving the problem, or simply fixing it?

What is the first thing that comes to mind when we see the problem? Most of us immediately jump in to start solving it. While this might appear to be a natural instinct and a logical choice for some simple problems, reality could often be otherwise, especially for complex problems. If we don’t know enough about genesis of that problem, we might spend countless hours ‘fixing’ it, and yet hardly make any meaningful headway. Or, we might fix it in the short-term, but might not solve it in the long-run, i.e. address the root-cause behind it. For all we know, the first thing we do might actually be the worst!

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solutions” – Einstein

There is an interesting story about the famous Jefferson Memorial. A few years back, for no apparent reason, the monument was found decaying significantly more than other monuments. At the initial inspection, it seemed like it was acid rain or some such thing, but on detailed inspection, and after asking a series of ‘why’ questions, the root-cause was found to be completely unrelated to the original problem. Here’s roughly how the chain of thoughts proceeded:

Problem: Jefferson Memorial was found crumbling more rapidly then other similar monuments.

Question:Why was Jefferson Memorial crumbling faster than other monuments? Was it due to acid rain?

Answer: It was not acid rain. The monument was being cleaned both inside and outside twice a week with strong cleaning soaps. Upon further investigation, it was revealed that erosion was being caused by soap solution reacting with exhaust from jet fuel from the airport across the river.

Question: Why was the monument being cleaned twice with such strong cleaning agents?

Answer: Because there were lots of bird droppings, which were spoiling the monument, and to keep the monument clean, they had to wash it frequently.

Question: Why there were such high numbers of birds at this memorial compared to other memorials?

Answer: Because there were very high numbers of spiders at the memorial which birds like to eat!

Question: Why there were such high numbers of spiders at this monument?

Answer: Because there were a large number of midges (tiny aquatic inspects) that these spiders love to feast on.

Question: Why were there so many midges at this memorial?

Answer: Because midges were coming out for sex (yes, literally!) at dusk and were being attracted by light which was caused by the floodlights that were being put on just before the dusk – to make the memorial beautiful for the tourists! They would promptly die thus triggering the whole food chain.

So, that was the key. This was a long-lead food chain that had eventually turned into a problem. While the initial possible solutions included building a huge glass cover around the memorial, or even moving the airport far away (both of which seemed like very costly and complex solutions), eventually National Park Service delayed putting on the floodlights by one hour which led to midges population going down by 90% and the food chain was broken, and the problem was solved.

You can watch a nice short video on this from Juran Institute here: 

 

 

This is of course a great application of the Five Whys that was originally developed as a problem-solving tool by Sakichi Toyoda, the father of Japanese industrial revolution, at Toyota and became part of the Toyota Product System. Over the last several decades, several of the principles, tools and practices of TPS have found its way beyond automobile manufacturing, and are now generally considered as a vital problem-solving process for pretty much anything.

So, why this blog post?

Because the subsequent process of initiating required change is not as easy or straight-line as it appears to be.

Surprisingly, we still continue to see knee-jerk response to ill-understood problems that end up paying just a lip service to the real issues. Invariably, the 4th or the 5th why lands us into an unfamiliar territory – another function in an organization that we don’t have control over. In case of Jefferson Memorial problem, the solution involved getting in pigeon expert and then spider expert, and so on. Solving the problem effectively requires people to muster up all their courage and go over the fence and work with stakeholders to change something in their way of working – something easier said than done! There is a nice story of how a mousetrap, meant to be problem just for the mouse ends up being being a problem for everyone else but the mouse himself! It is a nice and simple illustration of how smaller causes cascade into bigger effects, and how trivializing them in the initial stages only ends up growing them into a monster problem that one is simply not able to handle. However, hindsight is always 20/20, and if only we could rewind the problem and get another chance to start it all over.

In my experience, apart from the ignorance about the power of a simple problem-solving tool such as five whys, when it still fails to find an effective solution, it is generally because it requires two different set of skills –

  1. the first is about doing a series of deductive reasoning steps to keep double-clicking on what is being presented as a cause till everyone agrees on the root-cause behind the problem. This needs smart thinking, ability to go beyond the obvious and build and test hypothesis that uncover more deeper issues.
  2. the second part is all about actually influencing people in another part of the organization to go and fix it. Invariably, the reaction is – “that’s not my problem”. In a way, this is like the Butterfly Effect – the flap of a butterfly wing sets off changes in a system causing a chain of events that eventually manifest in something very big in a completely different time and place. Solving this problem, then, is significantly difficult because it requires establishing the entire chain of events that led to the current problem. Given that these events are likely to be spread out in time (e.g., decisions made over time) and space (e.g., different functions in a organization), no one is likely to own them individually.

So, how do you go across organizational silos and ask people to take some preventive action that really solves the problem they have probably not even heard of! In general, making someone agree that they need to change something is hard enough.

I have found the following approach that works in many situations –

  1. First, get all the data. In the absence of data, we are all only conjecturing, and as creative that might be, we need to back it up with objective data to eventually make meaningful and better decisions.
  2. Whenever possible, involve other affected groups or individuals in the process at the earliest. No point second-guessing on their behalf.
  3. If they haven’t been part of the original root-cause analysis, instead of shooting off an email to them asking them ‘what’ is to be done, walk them through the entire process and ask them for validation. At this point, get an agreement on the problem without telling them your view of the solution.
  4. Once there is an agreement on the problem, half the battle is already won. Now start asking them how would they solve it.
  5. An ideal situation is when their solution is same as yours. But that might not always happen. If their solution is different than yours, first understand what is it that they are telling you, and why do they think that will solve the problem.
  6. At this stage, if you are not convinced of their approach, let them know so, and share what your original root-cause analysis exercise has come up with. The idea is not to confront them, but rather present another perspective and to compare and contrast what is better way to address the issue.
  7. If there is a toss-up between these two approaches, it might make sense to go with their solution rather than yours for two primary reasons – they are the primary function owners and hence expected to have better subject-matter expertise and professional judgment than you, and secondly if you go with their perspective, you are likely to get a better buy-in in the long run.
  8. However, if there is a deadlock, and quite often that is the case, one has to be accommodating. A very natural response is to go up the reporting chain and push for our solution, but I haven’t seen that is very productive in the long run. I would give benefit of doubt to the concerned group or the function and ask them to try for a reasonable and mutually agreed upon period of time till we see if the problem is resolved effectively. If it is not getting resolved, it’s time to once again get back to the drawing board.
  9. Hopefully you have an agreement by now on a solution that actually addresses the core issue and solves it. God bless you.
  10. Always remember – today’s solutions are tomorrow’s problems. While you might have solved the problem, in the bargain you might have inadvertently triggered-off another problem that is waiting to be manifest somewhere else in the organization in due course of time. So, keep your eyes and ears open if any new issues are reported – it is quite likely that they are regression effect of the current solution!

In today’s world, solving a problem effectively is as much a hard process as it is an individual and sociological change – affected people need to understand not only the required changes, but also the reasons behind it and adapt accordingly, which is more often than not, very discomforting. In a way, one can even argue that this is not even ‘change management’ – it is ‘change initiation’ which requires chartering unknown waters. Initiating the change requires even higher level of individual courage, leadership and persuasion skills to bring all affected parties on the same page. In a large and complex organization, it means hopping over silos and other political boundaries and tribal cultures and getting them agree to something else. Apart from a very strong understanding of systems thinking, it also needs very high amount of political capital and people suaveness to get it done. It also takes a lot of time to get this done, and most of us are simply not prepared to initiate such transformational change for a variety of additional reasons (e.g., if my performance system rewards result-orientation at the cost of long-haul systemic improvement, how can I demonstrate results by the time next review is due, and so on). So, we settle down for what appears to be second-best – just fix it. In reality, that is just postponing what eventually needs to be done anyhow – and perhaps at an even greater cost!

So, think again – are you thinking about solving the problem, or simply fixing it?

Effective Escalation Practices

This article was provided by Erin Palmer from the University Alliance. Erin writes about project management topics such as PMP certification.

Great leaders know how to focus on project management competencies. Perhaps nowhere in project management do effective soft skills shine through more than in the process of escalation and escalation mitigation. Knowing when and how to escalate requires more than just an intimate knowledge of the emerging issue, but a deeper understanding of the entire business landscape surrounding the events that have led you to this moment. Handling conflict in an action-oriented manner that effectively brings about resolution and promotes team cohesion may at first seem like contradictory goals. On the contrary, effective project managers know that teams work best when trust in leadership is palpable and when team members feel confident that if a problem arises, the leader will expediently and effectively resolve the issue. Strong leaders have strong teams and that is why it is imperative to spend time considering the finer points of an escalation strategy as part of your overall professional development process.

The Art of Knowing When to Escalate 

Establishing long-term communication protocol for all team members is vital to maintaining a feel for the pulse of the project and anticipating challenges before they become full blownissues. Some challenges cannot be avoided, such as a major upheaval in supply chain management when sudden events like natural disasters or international social unrest grind project progress to a halt. It is the more mundane situations encountered over the course of a career that will test your effectiveness more intensely than the occasional huge event. Here are a few questions to ask yourself before escalating.

1. Do I have all of the facts?

Escalation in its purest form is a strategic move. Make sure you have all your facts together and have taken the time to consider alternatives before escalating. If the issue personally involves team members, strategize how this escalation will be a learning tool if at all possible.

2. Will this issue come to a complete surprise to superiors?

If communication is open and effective throughout a project, then your superiors should have some indication that a challenge is present before the escalation occurs. The soft skills involved in finessing communication techniques over the course of a career become more complex and more important as the stakes grow. Be sure that your communication skills grow with increasing responsibility. Seek professional mentoring or other professional development to keep skills current.

3. What do I want from this process?

Escalation as a management strategy involves a comprehensive understanding of outcome goals and long-term project planning. Escalate too many issues and you may be perceived as the “Boy Who Cried Wolf” which may result in the lack of engagement of superiors when you truly need them. Holding back and waiting too long to escalate an issue can result in the project falling apart. Effective escalation takes skill, knowledge, and experience.

4. Am I prepared?

While seasoned professionals will disagree about when or how to escalate an issue, most will
agree that if you are going to escalate an issue you need to be completely prepared. Accumulate your documentation about what you have done so far to mitigate the situation; prepare a concise report detailing any related financials; have clear ideas about your outcomes. You want to be a partner in the process, so involve your team as necessary and engage your superiors as colleagues. An escalation can be an effective learning tool for teams if strategized properly.

Additional Factors to Consider

Effective escalation requires a certain level of professional maturity that emanates from top project managers. When you are in the presence of great leaders, how they handle conflicts and unexpected issues becomes the glue that builds team cohesion and is noticeable from a distance. Every company has divisions and teams that work smoothly despite issues that arise as projects evolve. Project management is a dynamic field with a strong history of building innovative solutions to business’ toughest challenges. It promotes a collegial environment where collaboration is a key element. Developing effective escalation strategies can help you keep your skills relevant and leverage career growth throughout the longevity of your career.

Role of Integrative Thinking in Project Management

I just finished reading the brilliant “The Opposable Mind” by Roger Martin. He introduces the notion that we all possess the so-called  “opposable mind” which has this amazing capability to simultaneously hold two contradictory views about a problem.

The conventional wisdom is to try to find a via media but that is perhaps meekly surrendering to complexity by taking a short-cut to a suboptimal solution. He argues that the some of the most exceptional leaders do not succumb to the obvious “either/or” thinking but rather work patiently towards synthesizing the best from both of these opposing views to create a best-of-breed solution that is far superior to either of these. He calls it “integrative thinking”.

Martin writes, and I quote:

“…the leaders I have studies share at least one trait, aside from their talent for innovation and long-term business strategy. They have the predisposition and the capacity to hold two diametrically opposing ideas in their heads. And then, without panicking or simply settling for one alternative or the other, they’re able to produce a synthesis that is superior to either opposing idea. Integrative thinking is my term for this process – or more precisely this discipline of consideration and synthesis – that is the hallmark of exceptional business and the people who run them.…Human beings, it’s well known, are distinguishes from nearly every other creature by a physical feature known as the opposable thumb. Thanks to the tension we can create by opposing the thumb and fingers, we can do marvelous things that no other creature can do – write, thread a needle, carve a diamond, paint a picture, guide a catheter up through an artery to unblock it. All those actions would be impossible without the crucial tension between the thumb and fingers.…Similarly, we were born with an opposable mind that we can use to hold two conflicting ideas in constructive tension.”

The book is a treasure trove of how go develop integrative thinking, but I was struck by how much it is relevant to each one of us at all levels, not just for the leaders at the top. The field of project management is all about making sensible but often hard trade-offs. Effective management of Project Management Triangle is literally the holy grail of project management – one that not only is the nemesis of every project manager but is also, in fact, the genesis of modern project management. In layman terms, what we mean is that out of Scope, Cost and Time, you may pick up any two, but can never meet all the three of them at the same time. So, if the requirement is to build replica of Eiffel Tower in just three months and ten thousand dollars, then yes, it can be built but it might look more like a school project. If it is a fixed-scope project like migrating all tax payers to a new software by close of the current financial year, then one might need to look at costs involved without which either one of the scope of the time might not be possible to meet.

However, what ends up happening in reality in many situations is that a project still ends up taking the amount of money that is takes, and yet the scope delivered is too little, too late!

If one were to look at modern project management (though most of us in software industry would probably call it as ‘traditional project management’), I think we just don’t have any similar notion of integrative thinking. The only treatment I have seen is perhaps in the Theory of Constraints where the approach is more holistic.

In software development, the conventional project management is modeled around industrial model of a production process – the so-called waterfall. In a linear, sequential flow done by silos that specialize in a single functional area, there is natural tendency and inclination to optimize the area of responsibility. For example, a design team might be most concerned with how elegant their design is, whether is meets the future issues of maintainability or portability or not. Similarly, the high wall between developers and testers is industry-famous – which is a major reason why developers don’t trust testers (“they will come up with only Sev 3 bugs and kill us with volumes towards the release, and expect us to fix them all before GA”) and in turn, testers don’t trust developers (“they can’t write clean code”, “if only they did better code reviews and unit testing and found all code-level defects, we could do such a better job of finding all Sev 1 bugs and focus on performance and reliability aspects”). Clearly, such a process breeds a mutual trust deficit, and the narrowly focused project roles simply perpetuate it further. What happens is the tragic story of optimization of parts at the cost of sub-optimizing the whole – completely anti-lean approach!

Agile software development (the concept, not a particular methodology) helps by offering to eliminate such artificial boundaries that force “either/or” thinking. Instead of taking a monolithic approach of meeting 100% of the project triangle, it offers to simultaneously meet part of the scope at part of the cost in fraction of time that what would normally be needed in a waterfall model. However being recently introduced to this concept of integrative thiking, I am still thinking if agile philosophy fully addresses it, and on the surface, it doesn’t look like. However, I have been proven wrong in the past, so we will see…

Are you splurging long-term dollars for a short-term fix ?

Diagnosing the root cause of a problem is a critical analytical skill. Most often, what you see is not what you get – the symptoms might indicate something, but the root cause might be entirely different. Some cases require a short-term fix – an immediate one, while some require careful investment in the long-term to completely eliminate root cause of a problem. Generally, most problems require a combination of the two. While ‘Process Pundits’ favor a long-term, preventive action, the action-oriented Cowboys can’t wait for eternity and want some short-term, immediate corrective fix to the problem, even if the problem resurfaces a few weeks later. In a way, the corrective-action Cowboys are like John Keynes, who said: “The long run is a misleading guide to current affairs. In the long run we are all dead”. After all, of what possible utility would be a long-term investment if we are not around, say, next quarter. So, no arguments that an immediate need must be addressed first and foremost, but it is like the proverbial firefighting – lack of preventive action eventually leads to emergencies that simply need a big fire hose to douse the fire. Initial trivialization of small incidents only leads to benign neglect which eventually deteriorates into a full-fledged Frankenstien of problems that simply refuse to die.

If initial and repeated trivialization is bad, so is other end of the spectrum – taking every problem far too seriously and calling the army when a watchman will do. In a zest to solve problems, we sometimes make them appear larger than life, and then find solutions that would perhaps address every exception condition, every nook and corner – mindless of the fact that for perhaps 80% of the times, a 20% solution could have done. The result is wasted money, time and effort, and an overbureauracratic process that stifles not just creativity but even the work itself. Look at what happens to our bus driver in this nice story when he takes the problem a little too far: 

One fine day, a bus driver was driving his bus along the regular route. No problems for the first few stops, a few people got on, a few got off, and things went generally well.

At the next stop, however, a big hulk of a man got on. Six feet eight, built like a wrestler, arms hanging down to the ground.

He glared at the driver and said, “Big John doesn’t pay!” and sat down at the back.

The driver was five feet three, thin and basically meek. Naturally, he didn’t argue with Big John, but he was not happy about it.

The next day the same thing happened. Big John got on again, said, “Big John doesn’t pay!” and sat down. And the next day, and the one after that, and so forth.

This irritated the bus driver, who started losing sleep over the way Big John was taking advantage of his size.

Finally, he could stand it no longer. He signed up for body-building classes, karate, judo and all that good stuff. By the end of summer, he had become quite strong.

So the next Monday when Big John got on the bus and said, “Big John doesn’t pay!” the driver stood up, glared back and screamed, “And why not?”

With a surprised look on his face, Big John replied, “Big John has a bus pass.”

Moral: First, be sure there is a problem before working hard to solve one.

Can we relate this story to something at workplace?   Are we sometimes guilty of ‘goldplating’ a problem – perhaps to get enough management attention, or to get enough resources, or simply to promote our interests in the organization ? Goldplating of requirements is a perennial problem for a product manager (or the engineering team – depending on what camp you are from :)). Then again, haven’t we seen the second-time architect syndrome – the architect tries to play so safe to avoid all the problems he faced in his first architecture that the second one becomes a virtual fort – and ineffecient in the short run and quite clumsy in the long run. What about testing ? In last ten years or so, I have seen a dramatic shift in the testing philosophy. From the goal of “good software”, the software industry seems to have gradually moved to “good enough software” and finally to “good enough to ship software”. Look at the amount of patches that download into your system everytime you are connected to the net. Granted that the problem complexity is perhaps a few notches higher than before, and internet has specially made it easier to shorten the feedback look from end-users, but I am sure there is life in between two extremes. No one could test a software forever, but customer surely can do with a little better software :).

So, what do you do when you see a problem? Do you percieve that to be a ‘trivial’ problem and choose to ignore it till it grows tall to your eye-level, or you simply get into a panic mode and raise the emergency alarm? Or, you treat a long-term problem with patches and quick fixes in a hope that sustained amount of small efforts can eventually move the mountain. They sure can, if you are willing to wait for a while. Or, finally like our bus driver friend, you choose to fix a short-term problem with long-term efforts only to realize that you have not only been taken for a ride, but also lost most valuable resource of them all – time. I think the wisdom is in keeping options open until the time it becomes critical to take a call, but institute mechanisms for periodic checks and balances lest you are sent on a wild goose chase.