There are many qualities that contribute to great business analysis. You have to be a good communicator and be able to analyze problems. It generally helps to have some solid background in the common techniques of business analysis. For some jobs you need domain knowledge, for others technical expertise. All of these are debated and discussed often in BA circles across the web. One of the attributes I don’t hear people talk about quite as much is being results-oriented.
 

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

As stakeholders play decisive role towards solution delivery, it would be helpful for business analysts and project managers to have a stakeholder strategy. Stakeholder strategy can help facilitate communication between stakeholders and IT teams. Stakeholder strategy allows project members to consider stakeholder availability and associated risks early in the project lifecycle.

 Today it seems like every project is urgent due to time-to-market compression and fierce competition in the global marketplace.  In this article we recommend management techniques that can help you and your team manage the complexities that are most likely present in urgent projects, while establishing and maintaining an environment of adaptability, innovation, and creativity.

Excellent requirements prioritization is essential to any well-run project. It ensures that the project focuses on the most important elements first, and that everyone understands and agrees regarding what the project’s most important elements are. Good prioritization of requirements will also ensure that engineers, programmers and database analysts develop a project’s most critical elements in sync with the business needs.

The voluminous amounts of information that an analyst collects during the discovery and elicitation phases warrant a good deal of planning and organization in order to make business or user requirements into a usable, cohesive whole. As with any other organization process, the key element to requirements’ organization success is thorough preparation and planning.

 You remember the game of telephone, right? The test of communication skills where one person whispers a message to his neighbor, and that message is translated multiple times from person to person until eventually, the last contestant repeats her interpreted message aloud. The goal is for the final person in the chain to correctly hear the original message, but invariably, there is laughter all around as the message is misconstrued.

This article promotes a new approach to requirements management that reduces project complexity and improves communication between business and IT. This new approach can be used on its own, or as a supplement or precursor to existing approaches. Critical features of the approach are: detachment of business requirements from individual projects; and the production of testable requirements that can be shown to be complete, consistent, and correct prior to use within the SDLC.
 

We present a requirements framework and methodology that may be different from what you are doing. Its three prominent characteristics are a framework, a new model, and visualization. The framework ensures completeness of all requirements. The new model is the Decision Model, transforming important business thinking into a tangible and manageable business requirement. The visualization simulates user scenarios, alleviating the need for abstract specifications or models.
 

Today’s business systems aren’t agile – even when agile software methods are used to develop them. Companies need business agility, and in most cases we simply aren’t delivering it. 

Here’s an example from recent experience. I visited a very large health care organization and had conversations there with a variety of people.

Great teams, like all great organizations, are those that make a distinctive impact and deliver superior performance over a long period of time. For a project, performance is typically measured in terms of on time, under budget, with full scope of features, meeting quality specifications, and delivering the business benefit that was expected. Project teams do not need to be big to be great...big does not equal great. But all too often contemporary project teams are too large, too dispersed, too diverse, and just plain too complex to manage using typical project management techniques alone. So how can we be successful when a project demands complex teams? Success in the 21st century demands that we acquire new competencies to form, manage, and use large, diverse teams as a competitive advantage.

The purpose of companies creating Business Analyst positions is to improve IT quality and efficiency while reducing project failures. When I first started as an Analyst, coming previously from the position of Software QA and having an education in technical writing (think documentation), I thought I was the perfect mix for the position. I quickly learned that having a job where I prove my worth through project success can be stressful.

The Business Architecture has slowly emerged as a new and creative way to deliver value to enterprises that have undertaken this strategic initiative... However, many are rightly questioning the necessity of the Business Architecture, while trying to understand its purpose and realize its value. After all, most enterprises do not have a formal Business Architecture and many do not have plans to develop one.

Learn all about the ISEB diploma in Business Analysis offered by the British Computer Society (BCS). It offers an industry recognized qualification without mandating a set duration of prior business analysis work experience.

Until business analysts really begin to understand the difference between rules of the business (business rules), and choices about system design, we’ll keep falling to the same requirements and legacy traps as always. In my previous column I looked closely at the meaning of business rule. Now let’s probe the two fundamental categories of business rules: behavioral and definitional.