Requirements Gathering & Change Management Techniques | Art of Business Intelligence

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

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

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, no backup and recovery strategy, etc. There are several different approaches here so just make sure that they get hashed out

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 are strategic 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 at Volere, a UK based outfit. They have put together a killer Requirements Specification Template around 64 pages in length that

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 with something 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% [?]