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 isn’t 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 department’s analysts 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 (RGS’s)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. I’ll discuss a few common techniques used in these sessions. One of the buzz words around RGS’s 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 presentation 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 I’ll 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 customer’s 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 ascertain 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 RGS’s 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?
I’ve been a project manager, 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 don’t 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 rudimentary 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 you’ve saved yourself a lot of future annoyance and plus you’ve 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 group’s needs. Ultimately its all the same candy with a different wrapper but that is for you to decide.
- 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, I’ve got the following resources in my toolbelt.
- 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.
- 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.
- NASA ARM Tool (link to homepage)
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.
Alright, so this post was all over the place but I wanted to convey so many points around the seemingly simple topic of RGS’s and Change Management. I think I’ve 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 Project Management 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, that’s a good find on any budget.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
Ultimately the goal of commentary in OBIEE is to have a system for persisting feedback, creating a call to action, and recognizing the prolific users.