General Business Analysis

Whether linear or agile development approaches are being used, the Business Analyst needs to have a specific required point in time where the solution being implemented is checked against the original problem before it gets too far downstream.

If a business analyst is to step up to the task of becoming a credible project team leader, she must have an understanding of how teams work and the dynamics of team development. Team leaders cultivate specialized skills that are used to build and maintain high-performing teams and spur creativity and innovation. Traditional managers and technical leads cannot necessarily become effective team leaders without the appropriate mindset, training, and coaching.

The language of systems is no different; No, it is not C++, Java, COBOL, etc., but rather simple English (or whatever your native language happens to be). In the past I have gone into length about the differences between Systems and Software, the two are simply not synonymous. Whereas systems include business processes implemented by human beings, computers and other office equipment, software is simply instructions for the computer to follow. Systems are for people who must also take an active role in its execution. In fact, systems will fail more for the lack of people procedures than they will for well-written computer software.

As trusted advisors, business analysts must never forget the value of collaborating with stakeholders at all levels of an organization. The world of Agile has demonstrated this very point and is doing so with great positive impact and effect on the bottom line of many projects. When initiatives and projects are not collaborative, there is always a failing point within the stakeholder community.

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

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.

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?

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.

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. 

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?

Business value is a new indicator for project success. Huh? You may be wondering what ever happened to the good ole scope, schedule, and budget. They are still there and measured, but what the 2012 trends have been pointing to is that a project completed within scope, schedule, and budget and not be successful.