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.

Smooth stakeholder participation is integral to the success of any project. Sometimes stakeholders hold information that is essential to thorough requirements discovery, so it is important that they be forthcoming. Other stakeholders must sign off on requirements as being final in order for a project to move forward, so it is important that they be decisive and willing to let go the discovery stage of a project.

 This article considers the unique complexities of large, long-duration, high-cost projects that pose challenges to project success, and offers both old and new management strategies to handle the complexities... The complexities of large projects require that particular attention be directed to planning the project, developing and delivering the solution, selecting team members, and sustaining a high-performing team over the long haul.

Although you can do ‘standard’ requirements gathering for Service Oriented Architecture (SOA) projects, there is now an evolving a set of analysis techniques, methods and approaches that purport to be better suited to information gathering and design specification. I will call these generically Service Oriented Analysis.

Through development and beyond we hope not to have show stoppers, anticipate builds and releases on time, expect teams to portray efficiency, want our customers to be happy, and hope that boss coming to work and singing melody. Sounds like a perfect five-course scrum, isn’t it?

Today the term Business Analyst is synonymous with a career in the IT industry but the most successful and valuable analysts are those who understand the 'business' rather than those who understand IT. So what exactly is a Business Analyst? What is the Business Analyst’s role? What is the best background for this job? What skill set is required? What type of person is the best fit? What training is required and available?

If you ask Business Analysts what they think about ‘Agile’, you’re likely to get a mixed bag of answers... With so many different ideas on what Agile is and how Agile impacts the Business Analysis profession, we decided to talk with leading experts in the Agile field and get their opinions on the subject.

For business analysts, understanding decision logic from the perspective of business people is key. For that you need business rules. But when can a rule be considered a business rule, and when not? This article presents five pragmatic tests for knowing when you have identified a true business rule.

Business Analysts are required to contribute to a project in a number of ways: primarily by identifying the needs of the target community; building the Communications Plan; defining use case models; and Business Requirements document. In order to do their job effectively a large element of a BA’s time must be spent understanding and managing stakeholders in the project... From a CIO’s viewpoint the skills they look for in a good Business Analyst include an aspect of stakeholder management and an ability to find a path through the likely problem zones.

Last time, we proposed that, with business rules, we surely can. The traditional way we manage business rules is time-consuming. It focuses on details rather than the bigger picture. The details are the business rules themselves - expressed, analyzed, approved, and stored in a safe place. But, viewed as details, they lose momentum, postponed until design or implementation. Perhaps we deliver too much too early. But, we can do it differently by delivering less up front and evolving it into something more important.

Managers who supervise business analysts, particularly in large companies, frequently struggle with creating a competency model for BAs. What are the key elements to consider? How to structure the various BA levels and titles? How to make sure that the competency model truly reflects business needs? Even if it requires a certain level of effort to be developed, a competency model offers a number of benefit to organizations...

 Ever had to interview your boss – or a divisional general manager – or the managing director of a key customer? What about a politician or a senior executive in a government department? All these scenarios can be nerve racking, yet they’re something a business analyst may be required to do on a regular basis.

A businesses rules management system (BRMS) can help a business in almost any industry realize two goals: make faster decisions with an automated process; and make better decisions for more profitable results. Unfortunately, many businesses assume that the road to decision management success ends simply with selection of the right BRMS. But that’s just one step—one that should be accompanied by 11 others.

Job sharing is growing in popularity across almost all corporate job sectors.  It also offers employers a viable option for balancing heavy workloads and retaining talent. Even if all of an organization's employees are full-time, should a project balloons unexpectedly and a business analyst become overloaded, the option to project-share would enable an employer to tag a less-stressed analyst to jump in and share the load.