artofbi.com-requirements gathering amp change management techniquesnbspnbspart of business...

8/4/2019 Artofbi.com-Requirements Gathering Amp Change Management TechniquesnbspnbspArt of Business Intelligence-2471113

1/4

http://www.artofbi.com/index.php/2010/03/requirements-gathering-change-management-techniques/?pfstyle=wp

November 9, 2010

Requirements Gathering & Change ManagementTechniques | Art of Business Intelligence

I think two of the most under appreciated parts of a Business Intelligence and Data

Warehousing project are gathering the project requirements and creating the action plan of

implementing the solution, often referred to as Change Management. Now, some groups

deal with each of these techniques with their own methodology. Others see this as part of

the normal project process, haphazardly hitting the high-level topics and driving to the

finish line hoping that no one asks them for the directions on how exactly they got there.

Because after all isnt the goal to provide the solution and not every atomic step it took to

get there?

I sit on the fence with that question because the answer really depends on each project and

each client. However, there are several consultant groups that earn their dollar by solely

providing Content Management professional services.

The Requirements Gathering Gathering

Without a doubt one of the crucial parts of a Business Intelligence (BI) project is the

requirements gathering session. Now at this point, I make the assumption that the
http://www.artofbi.com/index.php/2010/03/requirements-gathering-change-management-techniques/?pfstyle=wp


2/4

client/customer has been through the product demos by the sales guys, the buzz is in the

air, the necessary budget approvals have been set, and the departments analyts are ready

to rock and roll. Now it is time to figure out what everyone needs to get out of the tool

selected for the job.

Next is setting up the requirements gathering sessions (RGSs)which grabs all business

sponsors of the project and the end users of the ultimate project into a same room for n

days while the specifications of the BI implementation are hashed out. But as the

Professional Services (Consultancy, etc.) team on the project walking into these sessions

without a game plan would be a big no-no. Ill discuss a few common techniques used in

these sessions. One of the buzz words around RGSs is the use of questionnaires which

intend to sum-up and grasp the inner workings of the end-users needs in 20 questions or

less. Another, is the retrieval and prsentation of existing business reports, which basically

assumes something like taking a mainframe report as a starting template to create the

same report in the new BI system. There are many more techniques and Ill look deeper

into them shortly.

Ultimately a successful requirements gathering session boils down to asking the right

questions, knowing the capabilities and limitations of the BI system set to be implemented,

and documenting the specifications that arise from the RGS.

From Brainstorming to Prototyping

So an RGS is really a brainstorming session with a focus on immediacy and factual accounts

of reporting needs and experiences, right? So how do you get from an RGS to

Prototyping? The answer to the latter questions is that it depends on how much

bureaucracy exists within the client or customers department. Some organizations area

ripping and ready to go right away. Other groups are driven by intense process

development and granular specification documentation. As a side note, one should try to

assertain which approach the project will fall under. This will allow your group doing the

effort to be better prepared on how much documentation you will need to prepare and

develop and it also allows you to understand which approach to take regarding setting up

the RGSs documentation and so on.

Another aspect that I look at when discussing Prototyping is to relieve any ambiguity

regarding what Prototyping means to the project. With my engineering background, I

always look at prototyping in the BI world as a Proof-of-Concept (POC) that is a rough

design that understandably has many more iterations and refinement before it is ready for

prime-time. A POC to me means that a sandbox or development environment will be

stood-up and the project based there as a quick approach to letting a focus group of users

begin looking at some test data. And to me a POC has a different timeline structuring, nobackup and recovery strategy, etc.

There are several different approaches here so just make sure that they get hashed out


3/4

with everyone on the same page.

Solutions Architect or Hand-Holder?

Ive been a project manageer, team lead, solutions architect, report developer, analysts,

and DBA sometimes all at once, but what is sometimes unavoidable is the position of

Hand-Holder. And, I dont mean that term in a negative way. If you are the principal

solutions architect on a project you should always be prepared with a hand-holding

strategy. What does that mean? To use the old adage, Give a man a fish, he eats for a day;

Teach a man to fish he eats for a lifetime. As it relates to this topic, prepare white papers,

links to information on the web, and canned demo sessions for client/customer. You are

already on the project and passing this information along via an email or printed document

will prevent tons of rudamentary questions thrown your direction. Use a canned demo or

create one on your own that you can give to your new project team. Set up a 1 hour demo

presentation with a 30 minute demo ending with 30 minutes worth of Q&A and youve

saved yourself a lot of future annoyance and plus youve got material to use for the next

project/client.

Theories & Practice

Unless your group has a stern methodology to change management and requirements

gathering, you should at least understand some of the more well-know theories

incorporated by larger organizations. Taking a piece from each of these groups would help

you to define your own strategy and refine it to your groups needs. Ultimately its all the

same candy with a different wrapper but that is for you to decide.

RapidBI

CSC

TDAN.com (Anne Marie Smith) (2000)

STSC (Software Technology Support Center) (2002)

What I like about the last two items are that they have been around for 8 years and the

logic is still really solid. The checklist for the TDAN.com link and the STSC link arestrategic and the combination of the two are excellent for putting together a tight

requirements gathering and specification lifting document including testing with use cases

once a prototype of full development implementation insues.

Tools to Use

So here is what you are really reading this post for. After being on a project team where

requirements gathering seemed to be more important the prototyping, Ive got the

following resources in my toolbelt.

1. Topping the list are the good folks atVolere, a UK based outfit. They have put

together a killer Requirements Specification Template around 64 pages in length that
http://www.volere.co.uk/


4/4

has all aspects of writing great specs. For around $55 USD this is not a bad deal for a

great start to wowing your client/customer.

2. Next is NASA. Yes, the same people that claim to have landed on the moon. They

have developed an application that seeks to provide measures that can be used by

project managers to assess the quality of a requirements specification document. I

have not tested this yet, but it is free. If you try it please let us know your feedback.

There are a lot of tools out there right now for requirements management. My opinion is

that if your team typicall does more than 10 requirements gathering sessions per year,

looking into getting one of these would be a great idea.Volere has a list of 3rd Party Tools

here.

Conclusion

Alright, so this post was all over the place but I wanted to convey so many points around

the seemling simple topic of RGSs and Change Management. I think Ive left you withsomething to think about and hopefully listed a few great places to get started in either

creating your own process or enhancing the one that you already have.

As a last note to ProjectManagement and Requirements Gathering software I would

suggest taking a look at more options than just your stand-by Microsoft Project. There is

an up and coming open-source (free) tool called TaskJuggler which looks to be a new

contender. And, at a price point of $0, thats a good find on any budget.

Popularity: 26% [?]
http://alexking.org/projects/wordpress/popularity-contesthttp://www.taskjuggler.org/http://www.volere.co.uk/tools.htmhttp://www.volere.co.uk/tools.htm

artofbi.com-requirements gathering amp change management techniquesnbspnbspart of business...

Documents