Today’s Webinar is focused on how to deliver a good BI application the first time and avoid expensive rework and in so doing improving quality. Today, we will share our experiences helping companies implement a repeatable and successful delivery process including real life examples where implementation of agile BI delivery methods have resulted in productivity gains of 66% within two release cycles.
The structure of the Webinar today will be focused on the number of areas. First, we will talk about motivation, so why should we embrace Agile BI methods. We’ll talk about the common problems with the old school approach of waterfall methods. We’ll talk about this theory and the practice of Agile BI. And we’ll talk about ways to automate parts of the delivery process.
If you think about even “small” data warehousing projects, there are going to be at least 3-5 source systems. Those source systems might have 30 or so tables. Each one of those tables may have 30 or so columns. You can see that very quickly the number of data elements is going to explode. In this case if you do the math we are talking about 4,500 data elements, but the trick is if you really think about it there are probably only 100 to 150 data elements that really are important to the business. If we can identify what those key business elements are then perhaps we can turn the delivery cycle around a bit and deliver those items based on business priority.
| #1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index |
|
Read More |
One other point to consider is that data integration tends to be the largest component of many BI and data warehousing projects. If we can find ways to solidify that task to remove ambiguity and eliminate or minimize the rework that tends to occur during that task we can really extract a lot of value out of that and reduce the variability within the project and hopefully come in under budget rather than over budget for once.
If you think about a side by side comparison of traditional waterfall approaches and the more agile approaches, there are a couple of things to consider. From an ROI standpoint, if you think about the traditional waterfall process, you collect requirements, you put that into a design, you do some development, you do some testing and ultimately you deploy.
The business does not receive their return on investment until we do that deployment step, so throughout all these other steps it’s just the cost. We are not delivering anything at that point. Another thing to consider is that we don’t get real feedback until at least user acceptance testing, or maybe not until we go live. So we’re not sure and not really confident that we are delivering the right thing until we actually do that deployment.
So there’s a significant risk component there, and that’s unfortunately why we see a lot of projects get that feedback and user acceptance test or even after go live and get a lot of change requests. They have to go back and make serious changes that ripple through all the layers of the architecture.
 |
View a 2-minute demonstration of InetSoft's easy, agile, and robust BI software. |
From the Agile side of things if you think about it we are doing multiple iterations of features or of reporting on certain data elements and we are driving that based on business requirements. So going back to those 100 to 150 data elements that really drive the business, we are going to prioritize those based on business value and feasibility.
We’re going to deliver those you know in a series of iterations, so that each time we deliver a new iteration of a BI solution, we’re more and more confident that what we’re delivering is what is needed. Each time we’re getting feedback, we’re incorporating that feedback, and as it goes throughout the project lifecycle, the likelihood that we’re going to miss the mark reduces and trends toward zero. So that’s one that we want to see in that graph whereas with the waterfall we actually see risk increase as the project moves forward.