QlikView, like any reporting tool, starts with an empty canvas. As developers it’s our job to fill this with lots of useful widgets, clicky things and nice colours. Technically we have the skills and the challenge now is to understand requirements.

Often users are asked to supply these, is this the best way? Even if we are lucky enough to be sent requirements can we get the best insight by requesting a form or document be completed (probably by a single person)?

It’s worth mentioning QlikView has the flexibility to be developed in small cycles so there’s an opportunity to develop in lieu of requirements. Although QlikView is well suited to this style of development I wouldn’t suggest they’re missed completely.

Any successful dashboard has three elements.

• It has to useful,
• it has to be usable
• and it has to be used.

Being used is the byproduct of being Useful and Usable. So how do we go about this?

Firstly we need to know who the target audience is. Unlike ‘Field of Dreams’, building a dashboard in the hope that ‘they will come’ isn’t a sure fire way for success. By involving your audience in the early stages you can develop to their needs and focus your effort on what matters to them

In my earlier post I talk about tailoring a dashboard design to specific people’s needs. Therefore you need to seek them out and build a rapport.

In a recent role a single dashboard was aimed at line mangers that looked after people answering calls from customers. I created a virtual team by first demoing QlikView to them. Through workshops we discussed what their challenges were and what, on the basis that anything is possible, would they like to see. I purposefully didn’t give limitations at these early meetings so people didn’t focus on them and so I didn’t have to say “no” which may have put people off making a contribution.

Don’t forget to ask the group to prioritize their ‘needs and wants’ as you go; High / Medium / Low or perhaps use the Moscow technique (http://businessanalystlearnings.com/ba-techniques/2013/3/5/moscow-technique-requirements-prioritization)

Look at existing Management Information (MI).The purpose was to understand and document Key Performance Indicators (KPIs) and their calculations. Check many different sources to ensure consistency and never assume that results are report identically even when they should be. The lifespan of reports may mean they’re not up-to-date and calculations have moved on. These of course should be highlighted with a definitive answer sought.

Now that you understand the calculations you can track back to the correct data source and begin looking at extracts. Quick analysis will often give you the answers on how you are going to handle the information.

If the data tables are large maybe all the fields aren’t required. Usually only a few are needed for calculation and filters, the rest are often only used in the final ‘detail’ sheet of your dashboard for context:

1. Do you need all the fields?
2. Are they’re populated?
3. Are they ID’s that need reference tables?
4. How are they used?
5. Is their use documented in a Data Dictionary?

I have a tool which may help review the data. http://community.qlik.com/docs/DOC-3352

Now the requirements are taking shape. At this point the ideas and KPIs are brought together in a simple list. My thoughts on priority and effort required to implement are added, ideas which aren’t possible (for any reason) are separated along with reasons why.

Requirements

Invite senior stakeholders to review and revise priorities. Do this in a meeting environment rather than sending out on email. Work may be split into phases so the dashboard can be released quickly, missing some low priority functionally which will come later.

With the wealth of information you’ve collected writing requirements that cover these basic points should be simple.

Data

• How much historic information will the dashboard hold?
• How often will the dashboard refresh?
• Can old data be aggregated?

Key Fields

• What fields need to be incorporated as key filters within the QlikView dashboard?
• What fields are required for KPI’s
• What fields are required for context (detailed view of the data)

Features

Gleaned from your meetings and written simply (you don’t need to go into technical detail), for example:

• View trend information on KPIs by Day, Week and Month
• Bottom five performers by team and individual prominently shown
• Ability to see performance on each KPI in a league table by site, team and individual

And Finally…..

• Remember to share the requirements, ensure the stakeholders agree and understand what’s going to be delivered and in what order. A project plan will help you understand the development time frames.
• Keep the users informed and don’t let the communication go quite.
• Give regular updates and demos to the users
• Use your virtual team of users to check calculations, test functionality and confirm understanding as you develop.