If you have ever worked with consulting companies, or at least considered involving BI consultants on a project, then at some point you might have the question – what do these “development” men-hours include? Isn’t QlikView development simply writing a rather short load script and tweaking some UI settings as it was shown during product demonstration? Well, despite the fact that QlikView indeed speeds up development and reduces total project time, there is still some work to be done, that doesn’t depend on the BI tool itself. Here are some tasks that I typically perform as a QlikView developer.
- Fill the gaps in requirements. Often a task description looks like a rather incomplete mix of business and technical requirements, full of company-specific terms and abbreviations, and some paragraphs look more like wishes than a detailed description of what has to be done. And that’s OK – because it might be hard for you to foresee what kind of information might be required for developing a BI application simply because you do not develop them every day. Therefore I ask a lot of questions to understand the task better and fill in the gaps. And that takes some time.
- Data profiling of source data. I don’t automatically trust source data. I have to be sure that source data contains what it should contain to avoid surprises like unexpected nulls, or numbers instead of text, or text instead of numbers, or dates from King James epoch, etc. Also I check relationships to make sure, for instance, that reference table (e.g. list of products) has all products IDs mentioned in fact table (e.g. journal of sales).
- Create UI layout design. Because the dashboard layout is often missing in requirement specifications, I need to figure out which UI layout best suits the needs of business users. Sometimes this is a repetitive process because users need to try the layout in daily work and they often come back with suggestions for improvement. Also, QlikView is a bit different from other BI tools – because it is not only a BI tool, but it’s actually a Lego for analytical applications thanks to its flexible UI customization capabilities. However all this beauty requires time to set up, and users like the final result.
- Test It. Finally, before giving the application to the end users, I test it. I know that users don’t have much time to thoroughly test the application, so I try to reproduce various combinations of selections and source data before I hand over the application for user acceptance testing.
At the end of the day, “pure” development barely takes more than 50% of actual effort. Often even less than that because it’s only a part of a bigger effort, required to produce a correct, reliable and user-friendly analytical application.
