If we do the executive part right that at the beginning we can get a very good estimate. In the project we used, we are going to show you a balanced insights consensus tool that we used for programming and prototyping and for automating the requirements of the BI reporting platform. We are going to show you some of that when we use the BI solution itself, whether you have Cognos, Business Objects, MicroStrategy, or Microsoft.
And in our opinion in this project perspective, this is where we want to do some data profiling to get at least a heads up on what’s out there from a data quality point of view and where the data skeletons might be hidden before we begin to work in these areas. Then lastly, we go and do the actual delivery. We actually reuse our data modeling tool and the actual tool kit that we use to design building and maintain our BI solutions.
Planning a BI Platform Roadmap
From the executive perspective what we are trying to really get at is a high level estimate with a low degree of variability plus or minus 5% plus or minus 10% as opposed to that plus or minus 40 or 50 or 60%. We are also trying to get to a release roadmap as we understand. It may take us 1, 3, or 6 months to deliver the full set of features and functions, but we certainly do not want the business to have to wait to the very end.
This, of course, is the big efficiency of the waterfall approach. We want to be able to deliver and releases and increments, which may be every 2 weeks or so, we’re delivering something. The release roadmap is really talking about what is the order in which things will be released and moved into production. And in the project what we are trying to do is really get to a fully working prototype where the consensus tool plays a large role.
We want to create something called the business model which I will explain in a bit. Certainly you have to do the data profiling and then the scrum component is where we want to create the story cards and the sprint roadmap in terms of what is the order in which work will get done. And lastly in development we are going to build the physical deliverable the databases, the ETL code, the dashboards and reports themselves.
From a duration point of view one of the things that we see a lot in organizations is that business people don’t want to spend a lot of time and effort in the justification phase or the executive phase because it really cannot be capitalized. Whereas once you begin requirements gathering, that money can be capitalized and therefore depreciated.
So there is a tendency to try to minimize the initial planning, but unfortunately that’s where the economy comes in where we have to get a reasonable estimate with limited information or things just go wacky on us politically and emotionally, and so that again is where we spend a lot of time. There are some methods and tools to get that right. And then we do what’s called the sprint zero.
I want to spend a lot of time talking about what happens in sprint zero. To us it’s the key to this methodology that’s a two to four, two to five week effort, and then we go into the actual development sprints. We try to deliver things in 2 week cycles. So we may use a two week sprint cycle. Some people do three. Some do four. The duration is less important than the fact of keeping them somewhat consistent.
Lessons From Data Warehousing
The core methodology is where we move into next, and there are really some lessons from data warehousing, but we’ve added some of our own thoughts. We end up with what are called two different sets of value chains, and it is really the core of the methodology. It’s where we start with the business value chain, and everything we do derives from the business value chain.
The idea is that we want to keep these things separate because we want to engage with the business and the things that are shown in blue. And we really don’t want to bother the business about the things that are showing in brownish orange. So we began to work at the justification stage with what the business wants to talk about.