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

The purpose of this article is to provide project managers and business analysts an example of choosing a hybrid solution development life cycle (i.e., combination of agile and waterfall). Much discussion has transpired on the virtues of agile and waterfall approaches.  

At some time or another, most companies will likely experience a point in their development when business process management (BPM) will need to be adjusted in order to support growth, mitigate a challenge or respond to market trends. Exploring how multinational corporations such as Apple and Hewlett-Packard have handled such challenges can offer insight for managers looking to apply best practices to the unique situations facing their own organizations.

As we travelled around India we were initially amazed at how the traffic flowed. India is a populous country, of course, and they have an ever-increasing number of vehicles.  No matter what time of day it was, the traffic seemed heavy. So, how can their constant flow of traffic work?
 

Teams that are geographically distributed and primarily work virtually face many challenges. One of them is sharing knowledge. I am part of an organization which has a team in Denmark responsible for development of the platform we support, while a team in India is responsible for the maintenance.

Enterprise analysis (also known as strategic enterprise analysis or company analysis) is defined as focusing “on understanding the needs of the business as a whole, its strategic direction, and identifying initiatives that will allow a business to meet those strategic goals.” 

An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable.