Introduction to BA4BI
Books on management and information technology have a half-life of maximum six months. Fads and fashions follow each other in rapid waves and leave few impressions-just like real waves...
So why bother? Why go through the trouble of spending more time to write a book than it will remain on the shelve in the book store?
Maybe it is because I hope to have unveiled a few universal truths about translating strategy into business intelligence architectures and certainly because I haven't met with any course, book or consultant who really pays in depth attention to this crucial aspect of successful BI projects.
Sure there are the obligatory check lists and the people “going through the motions” but as soon as possible, discussions focus on data models, processing capacity and tools. Even the more tenacious who try to push the business analysis issues to the limit often miss the point behind the questions as these are abstractions missing the organisation’s context and its impact on strategy formulation and implementation.
Few business analysts demonstrate deep knowledge of the strategy process and its interaction with information management. There you have the value proposition of this book: to open up the potential of understanding this interaction.
Data Analytics in Project Managment
Here we contributed a chapter on Data Analyyics and Scrum:
This chapter is probably the most exotic one in this book. It deals with reconciling two totally different worlds, each with their own rules and cultures and yet, it may also be one of the most valuable endeavours if you can bridge the gap between these two worlds.
The agile world is about facing the client and responding to his requirements with pragmatism to produce practical solutions delivered rapidly in short cycles of stories that yield a concrete functional aspect of the total solution. Estimating these stories is a joint effort of analysts and developers together with the product owner and each project has its own ecosystem where the complexity if the development may produce internal consistency but this will by no means imply conformity with external, objective standards.
In other words, the maturity of the team members, the group dynamics, the intrinsic motivation of key members, the hygienic factors like a nice office space, flexible working hours and last but not least… the client and the product owner may greatly influence the productivity of the team.
And then there is what I like to call “estimatiophobia” : the deeply engrained fear of developers to address the project with an entrepreneurial spirit, that sense of “I don’t control every aspect of this project but I have the will to succeed. Therefore I stick my neck out and estimate this work at € xyz”. Instead, developers tend to reduce risk as much as possible, act cautiously when the PM asks for commitments of time, quality, cost and all these other tedious metrics that only PMs can be interested in. ”Me, I just want to build a perfect solution!”