Taking time to determine business requirements before launching into a new IT or process-based project is a critical component of good planning and protecting company assets. Clearly defining the current process, the problems that need to be focused on, and working with the people in the organization before beginning your project will allow for a much more streamlined process once you start, with better odds for success.

As I've had the honor and privilege of mentoring and coaching business analysts (BA’s) one of the areas that has been a challenge to some is moving from facilitating and eliciting face to face meetings to facilitating and eliciting virtual meetings. More and more BA’s are working remotely, work for companies who have global businesses as well as companies looking at very creative ways to cut cost which may result in having business analysts work from home.

The project involved updating a quote process and the technologies underpinning that process, this included dealing with an underwriting calculation, which was embedded partly in the legacy systems and, partly, in heavily manual processes. The project team could not determine how to unpick this calculation and provide a detailed specification to a 3rd party software house.

I was asked my opinion about whether I’d want project managers to focus on processes first or tools first. Without hesitation, my response was “I don’t really care whether project managers focus on process or tools first,as long as they don’t get in the way of our doing good business analysis!”

Employers are looking for critical thinking and an ability to adapt, invent, and reinvent; collaborate, create, and innovate; and an ability to leverage complexity to compete. Standout companies are using projects as the hotbed of creativity – so that means BAs and PMs have to step up their game. According to the 2011 CHAOS Report from The Standish Group, only 37% of projects delivered on time, on budget, with required features and functions.

Ron Ross and Gladys Lam have written an important book for the business analyst community. It aims to get business analysts out of the technology ghetto that many of us get stuck in. Regardless of the type of analyst you are, I think it would be worth your time to get your hands on and read this book. I’ll explain why below.

So many IT projects ultimately end in failure and are simply written off. Same old story, time and time again. Why is it so hard? Why can’t we figure out beforehand whether some solution will actually work once we roll it out? Most project management approaches and many IT methodologies include steps for building business cases and provide guidelines for project planning and estimating. What’s missing?

There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant.

The Agile Extension to the BABOK® describes “business analysis areas of knowledge, their associated activities and tasks, and the skills necessary to be effective in their execution within the framework of agile software development”.  Below are 3 misconceptions that, in my opinion, the current draft of the Agile Extension is helping perpetuate.
 

Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME is talking about!
 

Today’s letter is “C” – for Class Diagrams. Business Analysts use Class Diagrams to help them discover ‘structural’ business rules and to document them in a visual form that is readily understood by developers.  What is a structural rule?

Agile development is an approach that evolves requirements and software through iterative deliverables. One of its principles is to deliver working software frequently, often through a series of two to three week iterations.  The Decision Model (TDM) is a model for the full and rigorous specification of logic.

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.

In a nutshell, a methodology represents a series of steps in a project specifying Who is to perform What, When, Where, Why, and How (aka, "5W+H"), from start to finish. Perhaps the best way to think of a methodology is as a roadmap or an assembly line where a product is developed over a series of work stations.

A data flow diagram (commonly abbreviated to DFD) shows what information is needed within a process, where it is stored, and how it moves through a system to accomplish an objective. As its name implies, a data flow diagram depicts the flow of data within a system.