To transform traditional BI projects to fit changing user requirements, many companies are choosing to implement formal methodologies that make use of Agile software development techniques and tools.
Technology teams whose job it is to keep the business informed have more likely than not used multiple resources to define an efficient, meticulous BI system development life cycle, that would find out business users' needs, design a data model to support those needs, pinpoint data sources, load the data into a dimensional model, develop BI objects and then roll out the end product to the users.
The problem is, in terms of BI, getting it right is all about context. What was considered necessary back during the requirements process isn't necessarily what is needed now. It isn't the user's fault that the context changed, but the fact remains the same. In the same way that organisations need to be Agile to succeed, the process by which BI analytics is delivered needs to be flexible too.
Reg Besseling, systems and process improvement lead (Africa) at AIG SA, says with an Agile approach, change in requirements simply happens, it is part of the process and embraced. With traditional methods, change is managed.
Besseling will be presenting on 'How to effectively manage a BI Project - An Agile Approach' during the ITWeb Business Intelligence Summit 2016, on 1 and 2 March at The Forum in Bryanston.
According to him, the four main principals of Agile are individuals and interactions over processes and tools, customer collaboration over contract negotiation, responding to change over following a plan, and working software over comprehensive documentation.
"Often when projects are called Agile, in reality they are really traditional waterfall-type projects with the names of methods changed, mounds of documentation, and restrictive change processes that are bound in red tape."
It is Besseling's view that most BI projects are focused on the end result, a report or dashboard, so the processes put in place focus on getting these produced - perhaps because these are easily understood, measured, tested and signed off - instead of a platform that allows for many combinations of reports that are built in a collaborative way.
Delegates who attend his session, he says, will hear how to get all the data and get it right - reporting toolsets are not as important as you think, consistent, reliable, repeatable results are the key to trust and take-up. They will also learn to be pragmatic - specs that are too detailed can obscure the goal. Finally, he will show how to use tools, templates and standards, and how collaboration builds buy in.
Share