Entries for 'Transform VA'

In many organizations, culture and conventional wisdom make it difficult for the BA to break out of mostly tactical roles within projects. However, in many ways, the future competitiveness of your organization (and consequently of your future employment) depends on it! So don’t blink or you will miss out on the best BA opportunity of your career.

Welcome to the new series of articles on the BA as the 21st Century Creative Leader. It was a perfect storm. As we entered the second decade of the 21st century, we found ourselves struggling to adapt. ... It is no coincidence that the business analysis profession is taking hold to address many of the 21st century business challenges.
 

This article proposes a use case best practice technique: Always document decisions separately and explicitly in use case scenarios. This practice assists the business analyst in identifying where alternate and exception paths may be needed.This is similar to how decisions and resulting gateways are documented in Business Process Model and Notation (BPMN).

A business model should include behavioral rules, decision rules, operational business decisions, and operational business events — all as first-class citizens. Understanding their intertwined roles is key to creating top-notch business solutions and business operation systems unmatched in their support for business agility and knowledge retention. This article explains how such true-to-life business models can be created.

I’m pleased to continue to uphold: the unveiling of this year’s top 10 business analysis trends. This year business analysts (BAs) will need not only the balanced portfolio of technical and business skills they have been perfecting, but also a more comprehensive perspective in order to meet the challenging business environment of 2012.

Creating a BA Center of Excellence (BA COE) is a proven method for effectively reaching these goals with a BA team. In addition to improving BA performance in the traditional fields of elicitation and drafting, they aid in improving the other ‘soft’ skills that are becoming increasingly mandatory for a BA to possess.

There are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article, expect to spend more time than average developing detailed requirements specifications.

Lean techniques use a process-oriented approach. In non-industrial organizations however, the process is invisible. In order to apply Lean techniques successfully in this environment, the visibility of processes has to be significantly increased. Employees have to learn to look at their organization from a process viewpoint. Furthermore, it is important that the method is applied to all layers of the organization.

Instead of taking for granted that either you find a flavor of agile that will fit the needs of your organization, or you must completely dismiss the use of agile methods, a much more valuable approach is to determine, for each individual project, which agile concepts should be embraced or not.

Several conditions make it appropriate to leave the requirements descriptions at a higher level of abstraction. Recognize that these are broad guidelines. The BA should perform a risk-benefit analysis to balance the potential downside of omitting important information against the effort required to include it.

We have always been fascinated by the exceptional business analysts who can create order out of total chaos. The ones who can ask those great questions, who can figure out what’s important and what’s less so, who can synthesize lots of information, put it all into their magic hat and come out with requirements that make sense to all the stakeholders.

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?”

Your new system just went live and the project, that replaced a critical legacy system, is coming to a close. Business analysts gathered requirements and worked closely with users and developers, but did you capture all of the requirements?