One of the major marketing themes with QlikView over the past year or so has been it’s mobile credentials (witness the mobile minutes video series). Users are now able to access their apps and get insight anywhere – a revolution in self service BI!
But what about BI developers? Do we get the same freedom to roam and build the QlikView apps that users desire wherever we are? My own feeling on this is that we can, but I am not so sure that we should.
High speed internet enables all kinds of online collaboration options – it also makes the world a much smaller place. My website is global and, whilst AdWords and other marketing effort is tightly locally focussed, hits come in from across the globe.
The same is true for requests for consultancy and development work. So, can a project be delivered successfully for a client on a different continent without any face to face interaction? In short; yes, as a sizeable project I worked on with Visual IO based in Cambridge MA proves.
So is this the future for QlikView development? This developer doesn’t think so, and to be honest I hope not. Whilst travel is definitely not my favourite part of this job, it enables me to be face to face with the users that will have their working lives changed by the apps I create. An exchange of ideas and sharing of what insight a user requires can only really take place sat looking at the same screen. It also ensures I raise my game on design, as users will say they don’t like a certain shade of colour face to face – but may not think it important enough to mention on a conference call. At the end of the day it is all about giving the user the best possible experience.
Technically speaking the barriers to remote QlikView development have been removed. Furthermore, all the interaction I have with IT managers and DBAs could be done on the phone. It’s the interactive (in the true sense) bouncing of ideas to create the perfect user-centric solution that I believe requires an on site presence.
Besides, if I wasn’t with the users I wouldn’t get to see their jaws drop as they have their ‘QlikView Moment‘.
It is well worth hours stuck on the M40 in order to see that!
Hi Steve,
Great post, completely agree.
In my practice I have a few clients who before were with QlikView partners who only do remote development. While the solutions that these partners built were technically correct, all of them missed the fine nuance between what a client asks for and what they really want (or need). The ‘informal requirements’ so to say.
In my opinion the best (possibly only) way to gather these informal/unwritten requirements is to be on-site. When working remotely, all contacts with the client have a formal business purpose. You only get a single side of the story, the ‘official’ version. I find however, that it is in the small, informal ‘off the record’ chats with people that you get a much better view of the true wants, needs and motivation.
People often underestimate (or ignore) the impact that an organization’s culture and, unfortunately, politics can have on the success of your (QlikView) project. Simply being on site and speaking face to face with the stakeholders can go a long way in mitigating these risks.
Or, as Woody Allen put it: “90% of success is just showing up.”
Cheers,
Barry
http://www.qlikfix.com
Interesting piece, Steve.
I’m inclined to agree with you that that you really do need an element of face-to-face interaction to build the most appropriate application for the client. It is impossible to see a serious frown, or a knowing smile via WebEx or conference call, and something like that could potentially change the whole dynamic of a development given the right circumstances.
Having said that, I have definitely had experiences where meeting with the client initially to spec out requirements has been followed up by a period of offsite development with regular checkpoints. I feel that scenario can be quite effective too, but that is probably more the case in situations where the client has very little QlikView knowledge. The more knowledge they have, the more input (and less guidance from the consultant) they generally want into the look and feel of the application.
I suppose that translates to me sitting on the fence slightly. Despite that, there is no replacement for being in the room when the “lightbulb” moment happens. So I would say whilst it’s great to be able to do remote work in the midst of a development, it’s really important to be onsite for the start and the end, to ensure that the “humanity” is not completely erased from the process.
Lots of IT development is done overseas and, honestly, I can’t see why QlikView development is any different from this standpoint. For sure, working face-to-face has many benefits (far not the least is “humanity” mentioned by Brian) and usually, if there is such possibility, it’s much better to collect requirements on-site than remotely. If not, for regular QV project, working remotely won’t harm it anyway. However, for complex and challenging cases where solution is not obvious/typical remote communications may present significant project risk and on-site sessions may be the only way to mitigate it. So I would assume an answer to the OP question is depending on project complexity.
Agree 100% Steve.
Until recently I was developing remotely in that I was based on our Glasgow site with our Head Office in Glasgow.
I am now spending the majority of my time in Oxford and, in doing so, have rewritten quite a lot of my reports as it is obvious that these do not quite hit the mark as far as meeting the users “actual” needs.
The original reports were written to the users specification but only provided part of the solution that QlikView could provide. For example, we had a sales report which the user then dumped into Excel to create graphs from which they then e-mailed to various managers. This report now includes these graphs with the user clicking a button which e-mails them to the managers.
This says to me that face to face interacton is critical in “at least” the specification stage of the development. As Brian says, this coule be “followed up by a period of offsite development with regular checkpoints”.
Thanks guys for your thoughts on this. I should probably mention that a lot of the work that I do is trouble-shooting with short bursts of work for any given client. That means that for those short bursts it is all the more important that I am able to work face to face.