Analytical and Problem Solving Skills

Visual analysis models provide a powerful set of tools that let business analysts depict system information at various levels of abstraction. These models serve as an aid to understanding, as well as an aid to communicating. Alas, I fear that modeling is somewhat of a neglected practice. I believe modeling is an essential skill every BA should master. Here’s why.

Five S can be applied in any work environment and prepares a work area for a follow-on Lean process improvement effort. In this case, 5S prepares my garage for Lean process improvement in doing home activities like automobile maintenance, appliance repair, and hobbies like gardening and woodworking. But, remember the preparation benefit is only realized if 5S is sustained. As I said I am the worst (ugly) in keeping the “new world order” in my garage.

The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, the Future-How, which looks at the solution to the business problem. It does this by assessing alternatives, and then choosing the best solution to that real business problem.

Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations. The first article in this series described what mental models are and talked about the first mental model covered, second order thinking. In this second installment we discuss another mental model that that can help business analysts become better problem solvers: integrative thinking.

The purpose of the Trips-R-You Flight Booking Case Study is to provide an integrated, end-to-end set of requirement examples. In IIBA® BABOK® V3 terminology, end-to-end means from Business Requirements to Stakeholder Requirements to Solution and Transition Requirements. This case study, and associated artefacts, use the more traditional business terms Goals, High-level Requirements (HLRs), and Detail Requirements. Only functional requirements are addressed, and only within the context of a project chartered to deliver an IT-based solution.

For the business, it means they not only need to understand the problem the customers are trying to solve - they need to understand that problem in a context and design a full end-to-end experience of solving it. Some people call this process “human-centered design”, some - just using common sense when designing stuff. 

The reason why top performing business analysts tend to be so effective in complex projects, even when their domain knowledge is limited, is because of their ability to see things from a higher angle and with more nuanced colors.

Process modeling/mapping/flowing, can be an art, and science, based on the maturity of the organization, knowledge of those doing this work in the organization, and many other factors. What I have found can be challenging is identifying the actual processes to model/map/flow. The fight identification may not occur on the first attempt as this work can be quite iterative, however, there are some concepts that can help make the identification a little easier

Sometimes I find it difficult to explore new pieces of work in a structured way. When given a new challenge / piece of work it’s easy to jump straight into a solution. However as BAs we first need to understand the problem area better.

In a large firm, a business analyst (BA) organization makes an effort to identify, analyze and provide a solution to the above questions. A BA organization is a prime pillar in optimizing resources to provide maximum value out of it to the business.

A BA organization consists of business analysts in various roles like Product Manager, Program Manager, Project Manager, Business Analyst, Business Systems Analyst, Business Systems Consultant, Business Process Analyst etc.  The prime objective is to analyze business to maximize value addition.

To understand more about the BA organization, it is important to understand what is business analysis

During a recent presentation to business analysts, I used one of my consulting projects as an example of how to apply an analysis technique we were discussing. A member of the audience asked, “What made this company hire you as a BA consultant to tackle this project, when they already have so many in-house product managers and business analysts on their teams?”

A requirement is “a condition or capability needed by a user to solve a problem or to achieve an objective” (AKA a goal). Thinking in terms of problems and goals thus is a core competence for the requirements engineer. But what in fact is a problem or a goal? This may seem to be a rather philosophical question. As requirements engineers we should be quite specific on this point as the problems and goals of our clients are the raison d’être for our work.

Is your team struggling with the transition to modern requirements practices? As many teams explore and experiment with modern practices and agile, they often jump to apply tactical methods and techniques. But does anything really change?

 

Most teams work really hard and don’t see results. Or they find a few early benefits, but get stuck on a low plateau. They often give up and slide back into their old habits. Why? Because they’ve modified surface-level tactics, but haven’t modified mindsets.

A story is defined as a narrative or tale, true or imaginary. Each story has a moral hidden in it. A story writer won't directly say that hard work and patience is the key to success. Instead the writer came up with a story of Hare and Tortoise. And if we observe carefully, stories are everywhere; we ask a friend about her love story, we watch a prime time news story, we ask a new friend about his life's story, the movie I watched the other day had a good story. 

This short paper series, “Deep Dive Models in Agile”, provides valuable information for the Product Owner community to use additional good practices in their projects. In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.