For Business Intelligence Architects, it’s not at all unusual to be deeply involved with the requirements gathering phase of new initiatives. That is familiar territory for those who have spent time on a number of BI projects and have become accustomed to the manner in which BI projects differ from traditional applications development efforts. But oftentimes senior IT leaders, especially those who did not rise through BI or at least have a rotational assignment within the scope of the data warehouse or analytics group, do not appreciate the differences and can become impatient when BI development projects diverge from what they expect.
For example, traditional applications development initiatives are focused toward a particular goal, which if almost always known fairly precisely at the outset. Requirements then center on the work to explore what is needed to deliver those goals. Whether those goals are process Return on Investment (ROI) delivery, cost reduction or avoidance, or service improvements, the results we expect to achieve are known from the outset (even if they change later or are not achieved for whatever reason).
For BI projects though, we almost always assemble data and stage powerful analytical tools not to solve a particular problem, but to (in essence) see what we can learn. Even in cases where we have a particular problem to solve, experienced BI architects know that the first question we answer will merely be the starting point for a new investigative avenue seeking new insights. That is, we can build a system toward answering a question, but we must anticipate that it will drive us into new questions by the very nature of BI as a discipline. Said differently, a successful BI project asks more questions than it answers.
That said, BI requirements gathering efforts cannot focus in quite the same way as other projects. BI Architects and customers must expect an iterative approach, that initial requirements will inevitably drive the discovery of new requirements. This is one reason Agile delivery methodologies can be particularly well-suited to BI projects.
Additionally, whereas traditional requirements gathering work can perhaps be distilled into completing the sentence: ìI need X so that I can Y,î BI efforts can generate requirements from a different set of questions. In my experience, many of the following have often resulted in effective discussions around a customerís initial desires for their system:
What business concern keeps you up at night?
What question canít you answer right now?
If you knew the answer to that, what question would you ask next?
What could you know about the market, your competitors, your customers, suppliers, etc. that would make you more effective in your business? (e.g.: If I knew my highest-value customers most likely to defect to a competitor in the next three months, I could target them for retention activities)
There are many more questions that can spark effective conversations around a BI customerís real needs, at least as well as he or she can articulate them at the start of a project like this. In a future conversation, well take this conversation to its conclusion: how to use BI projects inherent flexibility to lift customer satisfaction with the delivered result.
Mr. Briggs has been active in the fields of Data Warehousing and Business Intelligence for the entirety of his 17-year career. He was responsible for the early adoption and promulgation of BI at one of the world’s largest consumer product companies and developed their initial BI competency centre. He has consulted with numerous other companies about effective BI practices. He holds a Master of Science degree in Computer Science from the University of Illinois at Urbana-Champaign and a Bachelor of Arts degree from Williams College (Mass).
View Linkedin Profile->
Other Articles by Douglas->