The Community Blog for Business Analysts

David Wright
David Wright

Separating Requirements Elicitation from Business Analysis

What do you need the most when eliciting Requirements? Face-time with Subject Matter Experts and their Managers.  As a Business Analyst employed in a typical organization, what is the thing you get the least of? Face-time with Subject Matter Experts and their Managers. Who will Subject Matter Experts and Managers make time to see? Outside Consultants.

Such is the way of the world, at least the one I have worked in for 30 years. Full disclosure: for about 20 of those years I was an employee Business Analyst. I am now an outside Consultant working in Requirements Elicitation, Analysis and Documentation. I have spent more direct time with SMEs and Senior Managers in the last five years than I probably got in those 20 years. Why? Because I have usually been brought in to work an important project, and I am a direct cost to the organization.

If you the reader are an employee working on projects, and not limited to Business Analysts, you know this true. Is it fair to you? Not really, but having been on both sides of this situation, I don’t see it changing anytime soon.

So rather than complain about it, how can you make this work for you? (And yes, what I will suggest should mean more work for me, but hear me out…)

Name one good thing about Consultants: they bring a fresh viewpoint, and they should bring better practices to deliver what they have been hired for.

Name one bad thing about Consultants (or least what many people I know do think): they leave when they are done, leaving it up to those involved employees to carry on what they probably started in the first place, and see it through to the end.

So, please read the first paragraph again… It does not mention all the other things Business Analysts do for their organizations. The role varies from place to place, but it usually does involve more than getting those pesky requirements. My own extra-speciality was project initiation, scoping, doing cost-benefit analyses, and a little Project Management on the side when pro PMs were not available. My experience over the years is that it is possible for an employee BA to get Senior Managers and Project Stakeholders in a room long enough to bash out a project charter, with goals and expected benefits; that is when these people are most engaged, up front when the idea is fresh and the expectation of good results is the highest. It is later on when you need some serious time to elicit requirements that the reticence to show up starts.

On the other hand, many BA’s participate in downstream activities, like testing, user documentation and training. I have actually had some vigorous discussions in the past with people who say that you aren’t a really a BA unless you do those things. I don’t happen to agree, but the fact that many BA’s do it, and do it well, is current reality.

So, you can probably see where I am going here. Being a BA can involve you from start to finish, but the key thing that makes all of it work, getting those requirements, is the hardest thing for a BA to get done, and done correctly; and boy, do you hear about it if the requirements turn out to be incomplete or incorrect. What’s a BA to do?

Separate requirements elicitation out from the all the rest of the work, and bring in an expert (which is how the business sees consultants) to nail down that important piece. Using good practices and standard deliverables, 5 to 10 days is all that is needed to get it done for a medium size project. That means those SMEs/Managers in a room, together, for those days in facilitated requirements discovery sessions. You get the requirements you need, and actually get them a lot faster than if you tried to get time with everyone in separate meetings, try to get it all down in one deliverable, get everybody to review it and approve it. I’ve been there, you’ve been there, and it can take 5 to 10 weeks, if not longer.

So yes, I am selling myself, and the people I work with, as a solution; there have been many buyers so far. 

The smartest customers have taken it one step farther. Once we have demonstrated success, the next step they take is to adopt our practices and train their own BA’s; and, of course, we help them do that as well. The most common approach is to train a few people to be the new internal consultants, and often that role (such as “requirements facilitator”) lives on as support to BA’s on all projects. All it takes is a few early successes and those hard-to-get business people (the start of this whole discourse) will be more than happy to be part of Requirements Elicitation.

So, divide and conquer, then reunite for long term success. That’s win-win-win for everyone.

This entry was published on Apr 28, 2011 / David Wright. Posted in Elicitation (BABOK KA), Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  3 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
11 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC