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.

The once lowly business analyst is suddenly in high demand. Here's how to work well with the ones you've got.   The hottest job in IT right now might be the least "T" of them all: business analyst.
 

There is an exciting paradigm shift happening within the information systems (IS) field. This means a new breed of information systems is emerging as are new approaches for developing them. The good news is that business analysts may be more critical to the new paradigm than to past ones.