Analytical and Problem Solving Skills

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.

Data migration is typically the most forgotten or underestimated component of an IT project which is the process of making a copy of data and moving it from one system to another, preferably without disrupting or disabling active business processes. On some occasions, it is not easy to understand that a data migration is needed in the project and ...

People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation.  This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.” 

This is a complete example of a Business/Systems Analysis Model using UML and including: Use Cases, Activity Diagrams, Context Diagram, and more.

A few words to set up the story - my daughter is going to have a cyst removed from her left wrist. It's not a complicated procedure but she will be going in outpatient surgery on Dec 20 of this year. Now here's the business analysis part of the story.

Do you know? If not, should you? I’m using BA as an abbreviation for Business Analyst (really, though, it’s one who performs business analysis regardless of the title) and BOT for “Business Order Taker” (also an abbreviated term for ROBOT). They are different in the way they approach business analysis.

...Why, even with the word Analyst in our title, is the role of BA more associated with requirements rather than analytics? My hypothesis is pretty simple:  If Business Analysts are not required to produce specific analysis related artifacts, then both analytical competencies and requirements efficacy will be diminished.

Many words have been written about the process of business analysis and how it can be performed on different types of projects. There are a multitude of tools and techniques which can be used plus methodologies and frameworks to suit a wide variety of circumstances. This makes it all too easy to get absorbed in the day-to-day detail and forget about the real purpose of business analysis – to fix a problem or provide the organisation with a new capability.

Quite simply, root cause analysis is a technique designed to unearth the real, often unknown reason why a business problem is happening, and then to propose a viable solution to fix it. BABOK explains that root cause analysis “can help identify the underlying cause of failures or difficulties in accomplishing business analysis work”[1] [emphasis added] and further clarifies that it is “used to ensure that the underlying reason for a defect is identified, rather than simply correcting the output (which may be a symptom of a deeper underlying problem).”

As businesses acknowledge the value of business analysis – the result of the absolute necessity to drive innovation through projects – they are struggling to figure out three things: (1) What are the characteristics of their current BA workforce, and how capable does their BA team need to be?  (2) What is needed to build a mature BA Practice?  (3) How are we going to get there?

“…The Analyst will [...] facilitate the identification, design and implementation of business and systems solutions in a rapidly growing and evolving business…”   What strategic initiatives might a business analyst as described above discover, and how will they deliver the “business and systems solutions” in today’s 21st Century competitive environment?
 

I was very intrigued with this concept when I read it in the Business Analysis Body of Knowledge (BABOK). This concept is so powerful and if used more in organizations can produce remarkable events; however, I have found that Systems Thinking can only be utilized to its fullest potential if the culture of the organization allows for that. However, as business analysts this is a concept that we should have in our arsenal of tools...

Facilitation is one of the most critical soft skills of the business analyst, as well as one of the most difficult to master. Working with various stakeholders requires tremendous preparation, insight and finesse in addition to an understanding of key principles of the facilitation process.

Over the years I have noticed that we, as Americans, seem to possess a knack for attacking the wrong problems which I refer to as the “Rearranging the deck chairs on the Titanic” phenomenon. I see this not only in the corporate world, but in our private lives as well. Instead of addressing the correct problems, we tend to attack symptoms.

In a process improvement project, the analysis team needs to model and examine several aspects of the current (AS-IS) value chain under study. The purpose of the analysis is to create a visual diagram of the value chain along with its associated text and metrics and determine if there are possible areas of improvement (e.g., reductions in cost or time). If improvements are identified, the team constructs a modified value chain model (TO-BE) with the improvements and then conducts a gap analysis on how to transition to the new value chain. This article focuses on the analysis of the current value chain by providing a method for structuring the AS-IS and TO-BE process improvement discussion.