Over time I will be writing a series of posts on what, from experience, I think you need to do to make QlikView a success in your organisation.
In this post I want to cover a common Issue in qlikview implementations. Sometimes it is referred to as Ivory Tower syndrome.
This issue is where the designers, decision makers and developers of BI are removed from the end users, aloof in their ivory tower looking down upon the struggling masses. In banal reality is more often not an ivory tower issue but a heavily overworked BI department often constrained by strict project controls. This workload and rigid structure leads to 2 symptoms. Firstly the developers become detached from the end users and secondly the speed of delivery cannot meet the speed of BI demand. Both of these symptoms will lead to your QlikView implementation failing to meet the needs of your users.
So one part of a successful qlikview implementation is ensuring the developers and the end users are engaged with one another. I find the best way of doing this is to get the developers from their offices/cubicles and out amongst the users. Either floor walking, asking users about their use of BI or actually working for the day there. You want the developers to understand how each part of the organisation works, what they do, how they measure themselves and how they fit into the bigger picture. You want them to have their ears open for BI needs that are not being met. You want them to have that meerkat moment (no not cheaper car insurance) when someone mentions a problem that Qlikview could fix. Basically you want your developers engaged in the business.
This is the bit project managers hate… You should allow developers the freedom to make minor changes adhoc. You have to trust your developers to appreciate a minor change versus something more significant. I generally consider simple amendments to existing objects or adding a new simple object to an application to be minor changes, but could mean hours of saved time or a completely new perspective on data for an end user. You also get that sense of engagement from the end users.
It is not appropriate all the time, but during those crucial phases when the users are still understanding the power of qlikview I cannot emphasise strongly enough the importance of getting your developers out there to show them what it can do and the speed at which most of it can be done.