This month’s column is not a debate about decision table theory versus decision model theory. Instead, it focuses on current practices for decision tables and those of The Decision Model. It covers (1) Four Benefits of Decision Tables (2) Decision Tables in Practice (3) The Decision Model in Practice (4) The Science Behind the Transformation Steps and (5) Wrap Up: A Leap in Maturity.

How do business rules fit with requirements? What role should business rules play in business analysis? Do business rules offer something to agile projects? This column, the first in a series of three, explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it? You may be surprised by what you find here!

When we first look at data fields on a business document, they appear complex. However once we analyze and understand them, they become simple. This is one of the purposes for a technique called normalization – to understand data fields and their relationships.

One of the most significant characteristics of an Agile engagement is that technical and business professionals work collaboratively to grow the system. The team agrees upon the goals for the project, as well as the order in which the requirements will be addressed on each of the sprints... At least one team member should have the role of “data advocate”; a person who wears the data hat...

We are frequently asked about connecting and tracing software architecture elements to business processes by integrating BPMN business models and software models in UML (Unified Modeling Language)... Now we will explore how to supplement business architecture with software architecture. 

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.

Today many business analysts are creating business-oriented decision models. These decision models contain business logic for operational decisions that operate within business processes. And, it is no surprise that data quality is critical to business-oriented decision models. After all, good decision models operating with bad data are no better than bad decision models operating with good data. The surprise is: not only are decision models a preferred way for managing true business logic but they are remarkably suitable for managing data quality logic!

What comes first, the business analyst or the business analyst experience? If you’ve looked at BA job postings lately, you’d probably say the experience, as most BA jobs require experience. From one perspective, you’d be correct. But from another perspective, you’d be wrong.  For if every BA role requires experience, how is it that there are hundreds of thousands of practicing business analysts across the world?

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).”

Checkpoint Beta is not mandatory. It is, however, extremely helpful for the business analyst. Checkpoint Beta is also an informal meeting, this time with the solution team. It is held prior to committing the solution to the final, formal solution document andobtaining final confirmation from the business community.

One of the soft skills that BABOK [1] specifies is communication, and for good reason—understanding and being properly understood is key to any profession, but especially business analysis, where details are king and unearthing them is meticulous work. And an analyst has multiple avenues of communication that affect her work.

With the rapid adoption of The Decision Model, the most frequently asked question is: “How do I convince my organization to try it and eventually adopt it as a standard?” Two related questions from two different perspectives are:  Do I have to find a way to introduce The Decision Model from the top down? Can I introduce The Decision Model from the ground up?
 

As businesses acknowledge the value of business analysis – the result of the absolute necessity to drive business results 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?

There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article I offer some ideas about how to make that choice.

Of the four articles in the series, this particular article is the most sensitive. If not practiced with caution, trying to influence someone or a situation could have a devastating impact. Therefore, this article comes with a disclaimer: “Stupid is as stupid does.”