A BI project should not take longer than 12 weeks. By sticking to the programme, and taking snapshots of projects as they progress, organisations will get better results than they've ever had. That's not fiction. It's fact.
A BI project needs a very different approach to more traditional transactional systems development. Those involved in BI projects worldwide have known that for some time. But what does the trick? What actually works? The answer is common sense and there are some key points in reference for consideration.
Examining snapshots of BI environments, which consist of the end-user community, the cubes, reports, data models and ETL processes, divulges, more often than not, a huge number of cubes and reports, but no happy end-users and project sponsors. The reason is that projects simply take too long and cost too much.
Considering the length of projects, BI practitioners find themselves responding to end-users or departments that shout the loudest. This is a very common, and reactive, approach. BI practitioners should be proactive.
BI roadmaps can help to develop proactive approaches. BI roadmaps only put all the components that impact BI environments into perspective and answer key questions. For example: what resources do BI practitioners have available and how do they develop them? When does the organisation migrate to its new ERP system? When will end-users be properly trained?
Every iterative development cycle should start with revising BI roadmaps. Common roadmap components are an evaluation of the current BI environment, business requirements per information area, source analysis to determine chances of success, and plateau planning.
When creating BI roadmaps, a complete set of high-level business requirements is split up into several plateaus. Each plateau has a limited throughput time of three months and delivers added value to end-users. Advantages to adopting this approach are:
* The focus of all involved is not lost as can be the case with projects that last for extended periods of time; a year or even longer in some cases. End-user commitment is easier to maintain and manage during the shorter time frames of separate plateaus. Instead of gathering all the requirements up-front, end-users are invited back to test results before periods as long as eight months have passed. IT professionals get timely feedback as to whether they're on the right track.
* Sponsors see results sooner and see value for money quicker. The BI solution starts to sell itself.
* There is less danger of constantly changing requirements - a BI environment is naturally dynamic, because the organisation is in data discovery mode. Such changes can be accommodated in the plateau approach.
In time, the total added value of the data warehouse environment is achieved.
During the project there should be room for revising definitions and business rules.
Erwin Bisschops is senior solutions architect at Harvey Jones Solutions.
But how do BI practitioners actually scope for a single plateau within the BI roadmap? The answer is by using the BI time-box.
The different activities within each project can and will provide insight into the relevancy, complexity and feasibility of the desired dimensions, measures and reports. The figure below, illustrating the time-box, indicates what consequences the complexity, volume and number of information areas generate for the size of the time-box. In other words, it answers the question: how much can be done in a certain period of time?
The bigger the cube, the more work required within a project and the less the chances of success are for a BI plateau. The best way to scope plateaus is to work backwards from project conclusion dates. Three-month projects cannot feature two-month requirements phases. In a project of that length, defining requirements would normally take two to three weeks. Any requirement that is not ascertained, defined, or on which organisational consensus has not been reached, should be left for a later plateau, since chances are quite high that it won't be solved in two months either.
During the project there should be room for revising definitions and business rules. Prototyping is a definite consideration because it caters for timely feedback to the end-user community and its representatives in the project.
Taking that approach, BI practitioners should complete the challenge and enjoy a leaner, stronger and better-looking BI environment after just 12 weeks.
* Erwin Bisschops is senior solutions architect at Harvey Jones Solutions.
Share