Don’t let the Fear Factor hold up approval of your Data Warehouse Project

Who is online?  0 guests and 0 members
Home  »  Articles  »  Don’t let the Fear Factor hold up approval of your Data Warehouse Project

Don’t let the Fear Factor hold up approval of your Data Warehouse Project

change text size: A A A
Published: 1/8/2010 by  samvnw51  - Views:  [894]  

 

Does the following situation sound familiar?

Your complex organization has enormous amounts of operational data stored in everything from Excel sheets and Access tables to clustered database servers from multiple RDBMS vendors.  Users from across the management spectrum frequently ask for ways to access that data from different perspectives to inform their decision making.  As a competent IT professional you and your team have indentified that a Data Warehouse based Business Intelligence solution is the best approach because its flexibility and high performance will provide long term value to the enterprise. Now it’s time to get buy-in and budget for the project from the management hierarchy.

These initiatives often have high level visibility within the organization because the analysis and decision making they facilitate is done at the C-level and Senior VP level. Unfortunately, at some point in their careers these executives have been disappointed by the results of a “Data Warehouse” project.  In some organizations “Data Warehouse” is almost a pejorative term. This is not because there is anything inherently wrong with the technology. It is because too often these projects have failed to deliver the expected results, or failed completely and end up unused. Part of the problem is the way the projects have been executed:

  • A team is assembled
  • A multi-month requirements analysis is performed
  • Six or even seven figure budgets are allocated
  • Six to twelve months pass while the first phase of the solution is built
  • Meanwhile the decision and analysis needs of the organization are evolving
  • When phase one is finally rolled out  twelve to twenty four months later, it doesn’t match the changed needs
  • The revision cycles begin, budget continues to be spent, but the business users are still waiting.
  • Etc..

So how do you reduce upper management anxiety and get the buy-in and budget you need to build the Data Warehouse solution that you know will work for them? A good strategy is to use a technology stack and a project methodology that shortens the “Time to Value“ for the project, demonstrates value at the earliest stages, and delivers new production ready functionality every three to four months.

At Pragmatic Works Consulting we have had great success with Data Warehouse projects using the MS BI Stack technologies coupled with the project approach describe above. We call this approach our “Agile BI Methodology”.

We have found that the Microsoft BI stack that comes with SQL Server 2005 and 2008 is hands down the best technology available for building Data Warehouse solutions. BIDS provides a single, consistent developer UI for all phases of the project (ETL, OLAP cubes, and reporting). In addition a vibrant ecosystem of BI developer productivity tools and addins has developed around BIDS that have more than doubled the productivity of our project teams.

The “Agile BI Methodology” we use begins with a “Quick Start” week at the very beginning of the project. During this week we identify a specific, high profile, Business Analysis problem and build a Data Warehouse prototype solution for it. The prototype includes ETL to load at least a subset of the needed data, as well as an OLAP cube with a couple of fact tables and dimensions, plus a presentation layer connected to the cube such as a flexible report or an Excel Pivot Table. At the end of that week we bring in the business stake holders at the highest level and show it to them. At that point we ask them for either a red light if we’re on the wrong track or a green light if they like it. So far it has always been a solid green light, and of course we always get suggestions and new ideas. On one occasion a VP of Markeing commented “Wow. This is answering questions I didn’t even know I could ask.” The absolute key goal of this Quick Start week is to show results to the decision makers early in the investment cycle, and get their buy-in.  Once we have it, we map out a project plan calling for a series of 3-4 month long “Sprints” that will each deliver an additional production ready BI/Data Warehouse solution or enhancement. Again, this tight schedule and feedback loop reduces the anxiety for the decision makers because they know it cannot turn into the endless Data Warehouse project from hell that they may have experienced in the past. During the project approval process make sure they understand this.

Another advantage of this project methodology is that it can provide an excellent forum for mentoring a project team up the learning curve for the BI stack technologies. Some clients have asked us to provide a team that executes the  “Sprint” build outs completely. But at others our role has been to mentor an internal team during the “Quick Start” week so they can execute the Sprints themselves. In these cases, it has proven effective for the mentor to be available remotely during the project sprints, or to return onsite periodically for additional mentoring and to help get the tougher solution components built. However, regardless of who is doing the work the frequent feedback and deliverables keep the project and solutions aligned with the business stakeholders’ needs and reduces their level of anxiety around the initiative.

A successful BI initiative can deliver significant value that has visibility up to the highest levels of the organization.  The IT team that delivers the solution can be real heroes. The “Agile” methodology described in this article can help you get your BI project approved and started quickly, as well as dramatically improve its chances for success.

 

aabundez likes this.
 
0
/5
Avg: 0/5: (0 votes)

Comments (8)

TimMitchell
TimMitchell said:
Good writeup. I've always preferred the approach of delivering smaller incremental pieces along the way, rather than forcing the principals to wait until the end for a "big bang" delivery.
11/29/2009
 · 
 
by
paschott
paschott said:
Can you share more details about the Agile BI Methodology you use or perhaps write more articles on that? It sounds really interesting and the lack of deliverables seems to doom more warehouse projects than anything else. Even a 3-4 month "sprint" would give some feedback as opposed to being years in and "almost ready".
12/11/2009
 · 
 
by
ashishnaik1
ashishnaik1 said:
Just in time article. I was reading about Agile development ("Accidently Agile" - article by David Poole on SqlServerCentral.com). This is more focused on BI.
1/8/2010
 · 
 
by
samvnw51
samvnw51 said:
Been really busy with the holidays, and just got back to see the comments today. I'd be happy to discuss more of the details of our experiences with this methodology over the phone. Feel free to reach out to me at Samvnw51@yahoo.com
1/8/2010
 · 
 
by
nashworth
nashworth said:
I agree, we have adopted a similar approach in our current project. The whole technology of BI is often a big step for any company and we have found that drip feeding functionality and value is the best approach.
1/11/2010
 · 
 
by
mikedavis
mikedavis said:
Good info Sam. These BI quick starts really help companies learn the ropes fast and get the on the right track.
2/2/2010
 · 
 
by
Daniel
Daniel said:
This looks like a great methodology on the surface. A finer grain would be helpful. I started a new job as a DW developer about a month ago. On the day I started, two regional VPs and one regional manager told me that I was the most anticipated hire in several years. Clearly the position is high profile. The company is very large, and the data and the sources are too. My immediate managers are very interested in cleaning up the ETL processes (which are messy and inefficient), and improving the cube design (which is very basic) before really getting to the results side of the equation. I appreciate their concern, but I don't want to lose site of the big picture, and more importantly I don't want the big picture people to lose site of me and for the project to fail as a result. This approach may help me clarify my personal goals. Any additional adivce would be appreciated.
2/21/2010
 · 
 
by
aabundez
aabundez said:
Thanks for posting this Sam. Helps to put things into perspective for Data Warehousing projects.
8/18/2011
 · 
 
by

Most Recent Articles