If we have to look at a Business Intelligence (BI) project from the sideline, one of the most common pits a project may fall into, is NOT to include the Business or the end users.
Some rules that we could work by in a BI project could be these (the list is not complete, and is only a guideline)
- Let the Business Users define their needs.
- Constant challenge them, and ask them questions about their perception of their world (data).
- Define a Business Model, Information model and a Process model.
- Explorer data in the area of interest.
- Don’t try to model their entire world (data), regardless that they “need everything”
- Always, and I cannot emphasize that enough, start with the easy achievable goals.
- Instead of working by the Waterfall method, use the much more agile method called Scrum
We know it all beforehand vs. let’s get wiser as we go!
In many projects that I have participated as a developer, some tended to scoped them as a normal application development project. Where there have been a massive analysis and requirement work done beforehand, everything looks dandy and the business might have accepted the scope of the BI project.
But what often happens, is that the world is evolving faster than anyone realizes, and the consequences is that what looked as the best possible solution ½-1 a year ago often tends to be somewhat of. Another risk is that the requirement and specifications of the system is hard to change, or if it is possible – the price for doing so might be high and set the project back.
The above method goes by the name Waterfall.
Some companies that have reached a certain maturity concerning their software development – both their applications and their BI systems, have embraced the agile way of software development.
One of the key advantages of this paradigm is that the project is scoped in much smaller pieces. Instead of the massive specification, that often was the result of a project run by the Waterfall method, the project owner and sponsor agrees on a final product based on a few pages of describing text and or some mockups.
When the project is starting, the project is scoped in smaller pieces that the given team of developers, business consultants, testes and IT can manage to finish in af timeframe of 10 to 15 working days. This way it is cheaper to make changes to the specifications as we go, as every sprint as it is called is in self a mini project.
If you would like to read more about this agile method called SCRUM – you should visit this page