topic Re: Qlikview Project Management in QlikView

Qlikview Project Management

suniljain — Thu, 22 Dec 2011 12:58:21 GMT

This thread is to discuss the experience gain during SDLC of qlikview project . so that it will helpfull to all member to learn something new.

Re: Qlikview Project Management

johnw — Thu, 22 Dec 2011 23:10:33 GMT

I'm not clear what you're asking for here. Just general words of advice for the whole software development life cycle in QlikView?

Treat your QVDs as a data warehouse rather than making application-specific loads. To the extent possible, PLAN how you want them to look and interact rather than just letting them come together organically. Do NOT build everything at once - only build what you need when you need it, but have a vision of where you're headed in the long term.

Understand and work towards a reasonable overall system architecture from the very beginning. A consultant might show up at your company and create a working dashboard in only two hours, but don't base your entire architecture on a two hour prototype, no matter how impressive.

As a developer, even if you don't understand what the users want, don't be afraid to create and install a simple prototype. Putting something in front of the users, even something wrong, is a great way to prompt user feedback. In my experience, I usually get far better requirements from just installing a prototype than I get from asking users directly about what they want. (Edit: To clarify, installing a prototype is not a replacement for talking to the users. You still need to talk to them about their needs.)

QlikView development is a highly iterative process, much more so than other software development that I've done.

QlikView development is almost never done. The frequency of requests merely diminishes over time as the application gets better and better.

Set analysis is NOT the solution to every problem. Yes, yes, I know you love set analysis. It's a wonderful tool, and when you master that tool, you may find yourself wanting to use it everywhere. Where you get into trouble is when you start doing things with set analysis that can instead be done with the data model itself. Data model solutions, where they are practical alternatives, are often faster to execute, as well as allowing the charts in your application to be better integrated with each other.

If complexity is required, put it in the script, not in the charts.

On the other hand, beware complicated data models and script. I violate this principle all the time, but after a year or two, I often don't remember exactly what I was doing and why, and find it more time consuming than it should be to make changes. I can only imagine the pain of other developers trying to maintain my script many years down the road. At the very least comment your code as clearly as possible.

Never aggregate in script except as the very last resort. If you're aggregating in script, you've lost the flexibility and power that QlikView provides for you. However, you often CAN do things in script that will significantly speed up your chart aggregations without actually aggregating. Consider carefully how you can split responsibility for calculations between script and your charts.

Take the time to read a book or two on dashboard design, displaying quantitative information visually, that sort of thing. Your job is not to IMPRESS your users with your amazing artistic prowess, or even your mastery of all of QlikView's ins and outs. Your job is to INFORM your users by providing the data they need as clearly and obviously as possible. Simpler is usually better.

Re: Qlikview Project Management

suniljain — Fri, 23 Dec 2011 06:26:25 GMT

Thanks a lot John. your knowledge is really useful.

what's your suggestion on intemediate database between qlikview and ERP.?.

Qlikview have abilities to maintain datawarehouse in itself .

kindly share your knowledge on the same.

Re: Qlikview Project Management

johnw — Tue, 27 Dec 2011 16:21:34 GMT

SunilKumar Jain wrote:
what's your suggestion on intemediate database between qlikview and ERP.?.

Our company has no intermediate database between QlikView and our ERP. The QVDs basically serve this function for us. However, I suspect the best approach depends on your environment. For us, we make sure we have well-written SQL using appropriate indexes to read our live transactional data, which combined with some hardware and licensing peculiarities results in very little impact on the transactional systems. People with other environments might well need to stage the data coming out of the transactional systems. I'm not really sure.

I suppose that just means that I'm the wrong person to answer this particular question, as while I'm technically a consultant, I've only worked with a single client on QlikView. I can't provide a more balanced perspective to this issue like I suspect most QlikView consultants could.

Qlikview Project Management

swarup_malli — Tue, 27 Dec 2011 19:15:07 GMT

This post was very informative...thank u ..John

Qlikview Project Management

rwunderlich — Wed, 28 Dec 2011 05:49:09 GMT

Thanks John. Great tips!

-Rob

Qlikview Project Management

suniljain — Wed, 28 Dec 2011 07:20:22 GMT

Thanks john, You tips is really very useful.

Re: Qlikview Project Management

IAMDV — Wed, 28 Dec 2011 18:52:38 GMT

Excellent tips. Thank you John.

Cheers - DV

Qlikview Project Management

Fri, 30 Mar 2012 10:58:36 GMT

Thanks for the information.

Can you suggest some good books on Dashboard Design...

Qlikview Project Management

johnw — Fri, 30 Mar 2012 18:48:14 GMT

I read two or three books by Stephen Few. It's been years, and I don't remember which ones. I think one was Information Dashboard Design: The Effective Visual Communication of Data. I disagree with him on a number of points, but agree with him more often than disagree.

I believe that The Visual Display of Quantitative Information by Edward R. Tufte is a classic and pretty much required reading, but I confess that I've never read it so I can't say anything from personal experience.

It might also be best to get some alternative points of view from experts who aren't design minimalists. I don't have any specific reading to recommend in that regard.