Problem Solving for Business Analysts

Synopsis

This article explores the discipline of problem solving. Some might consider problem solving an art, while others might define it as science. The reality is a little in between since part of problem solving involves creativity, which by definition cannot be rationalized as science since we are basically unaware or not conscious of it occurring. Creative formulation of new concepts and ideas is a process lies deep within the sub consciousness and we are only aware of the output of the creative process; a new idea is a good example. We don’t understand how the idea was created, but we know we thought of it.

This article does consider the creative process and instead deems it out of scope. Instead a process for problem solving is proposed that defines a number of phases that can be rationally quantified, executed and basically tested and verified.

Introduction

What does it mean to solve a problem? It relies upon two things occurring in the following order; an issue, or undesirable state that remains to cause angst, disadvantage, some negative consequence, or a limited capability and as a result some drive to overcome this situation through the formulation of some kind of a solution to resolve, nullify, or improve the current state of affairs.

How do we solve problems? Some people would say, by thinking. Thinking about what? The problem, right? Not necessarily. Thinking about the problem may help the situation and provide a starting point, but if thinking about the problem alone is not immediately returning positive inspiration and results then you are probably selling yourself short, being too narrow minded in breath and/or depth or focused on the symptoms rather than the cause. If the solution is not obvious, then there is obviously something missing from the equation.

For languages sake of descriptions, the term ‘problem’ is sometimes used interchangeably with the word ‘issue’. We don’t say ‘issue solving’, only ‘problem solving’. Issue is used since it is a more positive expression of the situation. One might say that there are no problems, only issues.

Practical Context

Undertaking business analysis, business architecture, or enterprise architecture involve the use of a broad spectrum of knowledge and best practice in frameworks and techniques to solve business problems. Apart from information relative to the professional practices, there are other domains such as the specific context in the organisation; the drivers & motivations, constraints, legacies, culture, etc. and issue or problem.

Finding a solution to a problem involves some kind of change within the organisation to be realized and formulated that could include a new product or service, capability, technology improvement, process maturity uplift, etc. All of these examples represent solutions to underling issues/problems that impact capability, and value to shareholders, customers, partners and suppliers.

Solving business problems always involves some kind of starting point, and a finishing point in terms of where in the spectrum one lies with respect to the problem and the solution. 

Important Elements of Consideration

There are a number of important elements of problem solving which will be explored in detail later when considering the proposed overall process of problem solving. See below;

·        Problem Statement: Describes the nature of the issue at hand

·        Scope & Information: Associated information contained within boundaries of consideration

·        Association and Relationships: Linkages between information within the scope

·        Rationale: The logical deduction within the scope that links the problem to the solution

·        Solution: A defined change in the system that nullifies, the problem and/or problem driver

Process

The following are a series of sequential phases that should occur to complete a problem solving exercise, which would result in a solution to the problem statement. The phases can be viewed as a waterfall. If however a phase cannot be completed, it means that a previous stage is incomplete and requires further exploring. Hence each phase has an optional feedback loop.

Problem Statement

Definition of Scope

The scope of the problem is extremely important and provides the platform to which all other considerations are included and excluded. A good analogy to scope is the expressions of ‘ring fencing’. Picture yourself actually laying a fence around an area to encapsulate something. The goal of building a fence is to keep something in, and to keep something out. Seems obvious but it’s worth thinking about this in terms of information and problem solving. All information that needs to be considered is within the fence line, and everything else is outside.

This is important from a planning perspective since if one knows what information needs to be considered, one must review the information. Because the information is known one can actually plan and put constraints around this; who needs to be consulted, where the information is obtained from, what systems and resource needs to be drawn upon.

Scope itself is a constraint. The output or solution to a problem is directly dependent on the information that went into the problem solving process. Information that is critical to formulating the correct solution is essential to being included in the scope. This can be demonstrated through a mathematical equation.

Take the following equation, which the problem is to find the value of X;

X = Y + 10           

Consider for a second that the problem is X, and X cannot be determined. What can be determined is that Y has the value of 5.

Unfortunately, due to poor research Y is not considered, only X. This equation is them impossible to solve and a solution is not found.

If however, you broadened the scope to include Y (Equals 5) then you could add 5 to 10 and have the solution;

X = 15

This may seem elementary but it highlights that without proper considering and scoping, one’s perspective may not be adequate to see the whole picture.

Quite often in business some information is considered, but not everything due to time constraints and economic pressure guiding a shorter term perspective on the solution. Often when this is done the depth of analysis is limited resulting in shallow or knee jerk reactions and band aid solutions that do not address the underlying cause.

In this sense scoping can be strategic since it takes into account the broader perspective including a broader more considerate base of information that is often not focused on the short term.

Resolving Ambiguity: Ambiguity factors

Resolving ambiguity is very import. When there is confusion or uncertainty statements made become imprecise approximations that fuel a culture of anxiety. People need to have the right knowledge at the right time to solve problems by making sound decisions. It’s important to note that nothing sure footed can really be achieved when there is confusion.

Resolving ambiguity or confusion is present in the following situations. Note that the following does not include any human communication dynamics.

·        Missing Information: Information that is not present

·        Incorrect information: Information that can be verified by other information to be incorrect

·        Conflicting Information: Information in at least two separate places that contradicts

·        Duplicate information: Same or similar information that is in more than one place

·        Incomplete information: Information that is present but has an unsatisfactory level of detail

How do you know if you’re missing information? Sometimes this is obvious based on the existing information. (You can see the outline of the footprint.). Other times there is no footprint, all your have is your current information, which is the best starting point for further information and traceability.

Traceability

Traceability is the art of defining concepts and their associated connection points. Consider a dot to dot drawing or a mind map; what presents is an interconnected network. This network can be used to explore its boundaries, both its breath of scope and level of scope. This two way exploration can always start with the existing information, considering other related concepts and relationships.

For example, if the word ‘Interface’ was on a mind map, I could also draw other branches with connections that say ‘client’, ‘server’, ‘api’, ‘web service’, ‘xml’, ‘meta-data’, ‘contract’, ‘data flow’ etc. The root of this exploration is the word ‘interface’.

Traceability can be explored within a mind map, or in any other conceptual model where you are connecting information, to other information through some kind of relationships.

Root Cause Analysis

Since the entire scope has now been defined, the process of identifying the problem symptoms and problem causes can begin. The symptoms are obvious effects, outcomes, metrics, sales figures, costs, performance measures; negative qualitative or quantitative measurements.

Asking the question why is the basis for root cause analysis. It considers the result of questions and then traces backwards to underlying causes. If we ask the question why, the result is the answer and potentially the basis to another question. This is an iterative process that is continued until the underlying cause is uncovered. Note, that the underlying cause should also be within the bounds of the scope already defined.

For example, the problem is a person driving a car along the highway breaks down and is stuck on the side of the road. The problem is “Car has broken down”. See below for root cause analysis.

·        Question: Why has the car broken down?

·        Answer: Engine has overheated.

·        Question: Why has the engine overheated?

·        Answer: No water in the radiator.

·        Question: Why is there no water in the radiator?

·        Answer: Didn’t get the car serviced

·        Question: Why didn’t the car get serviced?

·        Answer: Forgot to get the car serviced.

·        Question: Why did you forget to get the car serviced?

·        Answer: It was a new car and the owner never had to get the car serviced before.

·        Question: What is the servicing requirements of the car?

·        Answer: Get it serviced 6 months after purchase, then 12 months thereafter. (Stated in contract.)

·        Question: Did the owner read the contract?

·        Answer: No. Owner didn’t read the contract and was unaware of car servicing requirements.

Therefore;

·        Problem Symptom (Effect) = “Car broken down. Can’t go anywhere. Stranded on highway.”

·        Real Problem (Cause) = “Owner didn’t read the contract and had no idea that car needed to be serviced”

Identification and realization to solution

Once the underlying cause is attained through root cause analysis, the solution is often the formulation of a preventative action that is undertaken to resolve the problem symptom from ever occurring. This is usually obvious since it is only a single ‘jump’ to understand the resolution.

In the above example, the solution would be for the owner after they purchased the vehicle to read the contract or ask the sales dealer. That way they would have understood the responsibilities of owner the car and taken it in for service, preventing the breakdown from ever occurring.

A less savvy car owner would have opted for a more reactive solution. In this example, the owner could have just carried a jerrycan of water in the car. When the car breaks down the owner can simply fill the radiator up again with water and restart the car. (Assuming the engine is still working.)

Conclusion

The most challenging aspect to problem solving is having the right information and doing adequate work in scoping the issue. When the right information has been considered, mapping out the context and domain diagrams, the relationships can be defined; the problems and their causal drivers can easily be identified through logical deduction.

It’s also important to point out that sometimes it’s better not to be too focused on the actual problem, since as we have demonstrated here, the problem itself is just a single breadcrumb in the investigation; a mere starting point for exploration. This is what problem solving can be described as, a process of guided exploration within a domain, that has boundaries and has been defined to be within scope. Exploration starts at the symptom and goes backward, forward, underneath and around the problem to provide context and understanding of the bigger picture.

Often it’s the bigger picture that allows us the understanding to see the problem relative to the context and proceed in a process of questioning from a defined starting point to an ending point. This is one way to solve problems that starts by considering the problem statement, examining the scope boundaries and information, conducting logical deductions; asking questions and assessing answers, asking further questions etc, and deriving a solution that addresses the cause or root of the problem.  Sometimes root cause analysis is not required, other times there a multiple problems, seemingly interrelated with dependencies - and this is all compounded with complexity and ambiguity of course, not to mention miss communication and misinterpretation related to human factors. 

Yes, problem solving can be challenging, but it can be made less so with a methodical and logical approach that works.

Matt is a senior business analyst with 5+ years experience in transport, telecommunications, utilities, technology and automotive industries working with stakeholders to meet the objectives of organisations. Matt is competent across the spectrum of competencies and possesses sound alignment to IIBA best practice. He has engaged stakeholders in large transformation projects to facilitate change by delivering value through best practice. He provides thought leadership through research and development, academia and knowledge of open standards. 

Matt has extensive technical knowledge and is passionate about technology, business, business analysis and business architecture. He takes a dynamic high energy approach to delivery and providing exceptional value to clients through consulting. Matt leverage’s the creative process to innovate and deliver solutions to business. He has worked internationally in organisations in Melbourne, Germany and the UK.