Anyone who is familiar the Waterfall project methodology knows that part of it involves collecting all requirements up front. Compare that to Agile where the project consumes requirements in a more segmented way, through 'user stories'. In my view, these methodologies may have their use in other forms of programming, such as web-development, but when it comes to report writing, neither are ideal (though Agile comes closest).
In BI requirements always change. In fact, its unfair to demand that business user know exactly what they want. The probably do not know the data structure behind the data. It may be that what they want cannot be produced, and this is not realized until later in the development. Once the user has seen the result of the initial database query, they may realize (as they investigate the result) that they needed something quite different, or something extra. They simply couldn't have known that before. BI is all about investigation. That makes it different from other types of development.
In my view, those 'BI Professionals' who demand a REQUIREMENTS DOCUMENT up front, are amateurs. They have often come from development backgrounds, and have great skills in coding. But they don't know about the business realities of BI.
Being a great BI Professional is about so much more than just coding. You have to be able to work with the business; find out what they want, why they want it, and be good at explaining data realities to them, translating technical realities about the data into understandable language.
BI development is a learning process - that's why its called Business Intelligence, not Business Reporting or Business Dashboarding. Its not as simple as creating a report, a dashboard, a cube, a model, or writing a query. That often comes at the end of the process, once the data, usually copied into Excel and looked over by the user several times, has been verified and agreed to. Only then should it be instantiated into a report (turned into a report) or dashboard or tabular model or cube.
In BI requirements always change. In fact, its unfair to demand that business user know exactly what they want. The probably do not know the data structure behind the data. It may be that what they want cannot be produced, and this is not realized until later in the development. Once the user has seen the result of the initial database query, they may realize (as they investigate the result) that they needed something quite different, or something extra. They simply couldn't have known that before. BI is all about investigation. That makes it different from other types of development.
In my view, those 'BI Professionals' who demand a REQUIREMENTS DOCUMENT up front, are amateurs. They have often come from development backgrounds, and have great skills in coding. But they don't know about the business realities of BI.
Being a great BI Professional is about so much more than just coding. You have to be able to work with the business; find out what they want, why they want it, and be good at explaining data realities to them, translating technical realities about the data into understandable language.
BI development is a learning process - that's why its called Business Intelligence, not Business Reporting or Business Dashboarding. Its not as simple as creating a report, a dashboard, a cube, a model, or writing a query. That often comes at the end of the process, once the data, usually copied into Excel and looked over by the user several times, has been verified and agreed to. Only then should it be instantiated into a report (turned into a report) or dashboard or tabular model or cube.
No comments:
Post a Comment