Warning: Long and philosophical post ahead. Read at your own risk.
Last week I finished a research about QlikView implementations and I’d like to share some of the results with you. The complete document is about 70 pages long (one of the final assignments for my master’s degree), but I’ll try to reduce the theoretical jibber-jabber and only highlight the interesting stuff.
The study was based around a simple question: Why do QlikView initiatives under-deliver? The idea was to widen the scope of the analysis, not only reviewing projects individually, but evaluating the QlikView environment as a whole, because –let’s face it– you may deliver QlikView applications on time and within the budget, but that doesn’t necessarily translate to real and tangible business value.
I wanted a complete outlook, so the sample was divided in 3 groups:
- Consultants: QlikView experts that stay with other companies for a couple of weeks in order to configure the platform and create applications. I had the chance to interview colleagues from different companies including Master Resellers, Solution Providers and Qlik itself.
- Implementation team: People that were directly involved during the process. This includes developers, designers, DBAs, project managers, power users and functional personnel who helped with the definition of business rules and data validation.
- Other stakeholders: These guys are not directly related to the implementation, but certainly have an interest in QlikView. This group is mainly composed of business users, C-level representatives (CEO, CIO, CFO, etc.) and procurement departments.
In the study, the interviewees had to distribute 10 points amongst their answers, giving us a prioritized list of the most common elements that hinder QlikView’s success according to each group. After analyzing the answers, I’ve come up with the main challenges encountered in a QlikView implementation in Mexico:
Narrow-minded QlikView Development
This will not be a popular opinion amongst some of my colleagues, but I believe that there are few true QlikView implementations. The mexican market is composed of two types of companies. First, we have the Master Resellers, who focus on selling licenses in an “I come, I sell and I go” manner. As distributors with a yearly quota, this is an understandable behavior. On the other hand, we have the service-oriented firms, who act as application factories. You need a Sales App? There you go. HR app? No problem. Toilet paper monitoring app? We’ll do it!
These companies focus on the development speed and volume, but don’t necessarily analyze the real business need, the type of users that will interact with the applications, the nature of the data or the impact to the decision-making processes within the organizations. Development for development’s sake.
An integral QlikView implementation clearly should cover a wide variety of technical aspects, but also topics such as strategic alignment, product positioning, growth plans (HW, licenses, departments, data sources), disaster recovery procedures and best practices. After all, our goal is to enable a platform to analyze data, support decisions and encourage real business discovery.
Traditional Project Management
No surprises here, some of the most common problems identified in our study had to do with project management. It is clear that PMI-based methodologies have many advantages. However, QlikView projects are usually dynamic initiatives embedded in a context where the business needs change every day. Sometimes, following these type of rigid and document-intensive frameworks is more trouble than its worth, especially when it comes to requirement gathering and change management. We’ve found that other approaches like Agile Scrum have great results and adapt pretty well to the nature of BI projects. A flexible tool like QlikView combined with a methodology that handles rapidly changing environments is a recipe for efficient development teams and great user satisfaction. We implemented Scum about a year ago and there’s no way we’re going back to our old standards.
During the study, the implementation teams often pointed out that product sub-utilization was an issue in their companies. Surprisingly, some corporations have an inaccurate idea of what Business Intelligence is, which derives in static reporting applications that make QlikView look like fancy Excel spreadsheets.
It’s very often to find misconceptions around BI even in mature organizations. Some of them are subtle, like the confusion between Reporting, Business Intelligence, Business Discovery and Data Mining. Others are a little bit dangerous, like people trying to get rid of their data warehouses because now “all the information is in memory inside QlikView”. And some other are just… different, like some users trying to cancel an invoice in SAP by right clicking a cell in a QV dashboard.
The product positioning in early stages is vital. If everyone understands the role that QlikView plays in the organization and how it interacts with other platforms, it’s more likely that our applications will have greater impact in shorter periods. In addition, it is important to identify all the product’s capabilities. No one wants the newest smartphone just to send SMS.
Probably, one of the most painful side effects of the sales process and SiB events is that people assume that they can have 20 beautiful and robust applications running by the end of the month. After all, they saw an external consultant build an awesome app from the scratch in 3 days. I’m sure I’m not the only one who has heard things like “Surely, after a Designer & Developer course, my team could build seven or eight modules by the end of this quarter.”
Yes, QlikView is a noble platform: it is easy to use, we have many interesting resources available and there is an awesome community willing to help. However, it is not magic. I believe that an adequate balance between expert services, training and internal development could create a stable and self-sufficient QlikView environment to confront business needs.
For me, the best formula starts with consultants (probably because I am one). In the first days, the main task is to present QlikView, explain what BI is and the benefits it can bring to the company, generate a common understanding of the platform and generate a vision (how QV will help the firm to achieve its goals). After that, we enter a hybrid phase that includes training and the development of the first app. After a couple of days, the users and the technical team start to get used to QlikView, so they become more involved.
As the developers (and the QV environment) become more mature, the consultants should gradually step aside. This should not be and abrupt event, so I’d recommend visiting the customer 3 days per week. After that, maybe reducing it to 1 day per week or 1 day every two weeks. I call this the “Fade-out Phase”. In this way, the internal team will gain autonomy and experience, but won’t find itself without support in times of crisis, assuring the continuity and growth of the environment.
This is the basic formula we use to implement QlikView in Evolcon. Of course, there’s a lot more to take into account, but it has proven to give great results for our customers.
Last but not least, an old time classic: data quality. Without any doubts, “Garbage in, garbage out” is a principle that applies perfectly to BI tools. If our data sources are incomplete or inaccurate, it is likely that the information that we display in our dashboards will not be reliable. Sometimes it is better to invest in a data cleansing initiative before releasing critical QlikView applications.
These are the top issues that I’ve found for QlikView implementations here in Mexico. Have you experienced some of them in your projects? Please share your thoughts in the section below!