If you work with other business analysts, you are fortunate. Together with your colleagues, you can experience greater effectiveness than you could have achieved on your own.  Additionally, your colleagues can provide you with a diverse and convenient pool of expertise from which to draw.

There is much written today about separating business rules from other dimensions of automated business systems. Without proper separation, they operate in enterprises without a great deal of thought given to them. Ironically, they may be the most important dimension because they represent important business thinking behind processes, use cases, for example. This article discusses various approaches for dealing with business rules and use cases.
 

What we have witnessed in the last 25 years is a series of programmes of change failing to achieve their intended outcomes. Customer Care, ISO 9000, TQM, ABC, BPR. All the research and experience show that the latest panacea does no better than its predecessors. Over and over again improvement programmes are thwarted by commonly-known but illusive forces. The problem is labeled as ‘organization culture’, which typically leads to rationalizations like ‘change takes time’, or ‘each programme is an element in the total change programme’.

Rationalizations prevent learning.

This article provides the business analyst an analogy on how process owners manage value chains by monitoring leading and lagging metrics. The article highlights the need for business analysts to provide process owners with these metrics. These metrics provide indications of positive and negative process and business risks. Examples of the traditional risk response types of accept, avoid, mitigate, transfer, exploit, enhance, and share are provided.

The benefits of Agile methods are becoming more obvious and compelling. While the most popular practices were developed and proven in small team environments, the interest and need for using Agile in the enterprise is growing rapidly. That's largely because Agile provides quantifiable, "step-change" improvements in the "big three" software development measures - quality, productivity and morale. Confirming Agile's benefits, hundreds of large enterprises, many with more than 1,000 software developers, are adopting the methodology.

Regarding software architecture, it's interesting to note that it is the "lighter-weight" Agile methods, specifically Scrum and XP, that are seeing the broadest adoption in the enterprise.

Requirements continue to be a major problem area for most organizations. According to industry reports, the leading causes of quality, cost, and schedule problems are lack of understanding of the customer’s needs, incomplete requirement specifications, and managing changing requirements. In fact, requirements are so important that one of the definitions of quality is, “conformance to requirements”. If requirements are not good, the costs of poor quality will be high and the resulting products and services will not be good either. So what can an organization focus on now to measurably improve their requirements? This article will describe some practical strategies that organizations can use to measurably improve their requirements.

The role of business analysts and systems analysts appears to be very closely related, and there is no agreement on the definitions of the roles or the required skill set to become one of the said analysts. Though the number of these positions is increasing, the understanding of what the business and systems analysts are remains unclear and differs between organisations. A review of literature shows that there are common roles and skills between the two positions, as well as very distinct roles and skills that are clear. This research has demonstrated that although there is some harmony between the articles and interviews on the distinctions between the business analyst and the systems analyst, there are still discrepancies that can only be understood through further research.

I get this question and variations of it all the time! What is a senior business analyst? What skills do I need to develop to become one? What are the most valued business analyst competencies?

This is a tough question. And although finding the answer can be difficult, it’s also a tough question because it has multiple answers. Business analysis, like many, if not most, professions, exists within an organizational context. Different organizations value different competencies and so senior can mean something different depending on the organization in which you work and the strengths you bring to the table.
 

A thorough discovery of business requirements is almost never readily available at an analyst’s fingertips—rarely can requirements be quickly looked up as one would gather information for a term paper or study for a test. Much of business or technical requirements is not documented anywhere—it resides in the minds of stakeholders, in feedback that has yet to be obtained from end users, and from a study of flowcharts and surveys that have yet to be created. And so requirements must be elicited, or drawn out, and the methodology in doing so must be logical and meticulous... The purpose of requirements elicitation, therefore, is to thoroughly identify the business needs, risks, and assumptions associated with any given project.

Decision tables have long been a successful technique for representing structured logic. Being visual, they circumvent the need for unnatural formal language or grammar. We use them not only to communicate that logic, but also to automate it. They are especially useful for validating the logic’s completeness and consistency.  Yet, this article advocates that this is not enough.