I started my own feasibility study today, climbing [sadly only indoors] for the first time in the six, or so, weeks since I injured myself. Learning from my previous impetuousness I stuck to lowly V0s, working up only as far as V2 (for anyone interested an explanation of bouldering grades can be found here). My patience in forgoing climbing for a month and a half, together with my caution today seems to have paid off. Aside from a few tweaks, my damaged finger seems to have come through OK. I now need to remember to build things up very slowly and back-off at the first sign of any crunchiness whatsoever.
As per my previous analogy, it similarly takes time to turn round business or IT performance. Change is more of a marathon than a sprint (though often some basic things can be done a lot quicker). Staying with the area of rock climbing / business cross-overs, another previous article – Perseverance – highlighted the importance of this attribute in both areas. My aim is to take my own advice!
I seem to have acquired the habit of presenting in public. Early in my career, when I worked for a software house, I did a lot of product demonstrations and also ended up regularly presenting new functionality at my company’s user group; so I guess this is where things started.
When thinking about presenting outside of my own corporate environment, I made my debut at a Cognos Europe press summit in Barcelona back in March 2004. Coincidentally this was also the occasion that Cognos supremo Ron Zambonini took his final bow at the company – I trust it was not my talk that pushed him over the edge.
Since then, I have spoken at over 20 seminars and other events, the most notable of which are listed here. Generally I have had very positive feedback, both in person and via the, now ubiquitous, speaker assessment questionnaires that event organisers love.
Despite my scepticism about recipes for success, I thought that it might be worth passing on a few basic tips; approaches that have worked for me over the years. As with many things that we learn, several of these are pointers that I picked up via getting it a bit wrong and trying something slightly different next time round. I’m a great believer in trial and error!
A couple of notes up-front:
I am an IT person at heart and in the following I often take this perspective, e.g. this is how you should approach IT matters when speaking to people without a background in the area. I will assume readers are more than capable of transposing this to a more general situation when any specialist presents to people without a background in their area of expertise.
A lot of the following assumes that you are using PowerPoint or something similar to present. Many people loathe PowerPoint presentations. My take is the same as with any other tool, it’s not the technology, it’s how people use it. I have sat through deeply boring PowerPoint presentations and highly professional and thoughtfully constructed ones; it’s all down to the presenter. Nevertheless some of the following points would apply to all public speaking, whether accompanied by slides or not.
With these thoughts in mind, let’s leap in.
1. Be careful what you speak about and to whom
This might seem a very obvious point to start with, but I have been guilty of getting this one wrong on at least one occasion. On subject matter, it only makes sense to talk about areas of which you have a really good understanding; why else would anyone want to listen to you? Beyond this, the content of your presentation needs to be pertinent to the audience.
It is no good being a renowned expert on insightful tool-use in corvidae and then looking to address a convention of skate-boarders. More prosaically, on the basis of delivering a well-received talk on Business Intelligence, the company that organised this event convinced me to speak at a further conference whose topic was at best tangentially related. This turned out to be a low point for me in public presenting and I learnt to be a bit more careful about which seminars to speak at. It doesn’t matter how informed and engaging your talk is, if it is not relevant to the people you are delivering it to, then things are not going to go well.
2. Know your audience
Expanding on the second part of point 1. assuming that your audience has some general interest in what you are going to talk about, then it is important that you highlight the elements that are going to be most pertinent to them. So when I speak to a general audience about Business Intelligence, I might preface the talk with a brief introduction to the area and provide some definitions. When presenting to BI professionals, this would clearly be superfluous.
Looking at this the other way round, when talking to people with a technical background in BI, I might spend more time covering my ideas about the role of change management. This is because this may be a success factor that they have not focussed on as much as others. It is also important to tailor your vocabulary to the audience. IT people may love (and understand) your jargon, but it is unlikely to help more general audiences to engage with you.
3. Set the length of your presentation well within the time available
Given that you are going to deliver an informative, entertaining and insightful presentation, it makes sense to make time for all of the excited questions that this will lead to. Allow sufficient time for this.
In general if you have a 30 minute slot, then aim to speak for no more than 20 minutes of it. If your session is scheduled for a hour, then look to speak for no more than 45 minutes. Ideally you will have a break (or at least a change of pace) somewhere in the middle as well, because 45 minutes is a long time to speak for – and an even longer time to listen for! Use dry runs of your presentation (see 8. below) to make sure that you hit the desired time without either rushing or taking too leisurely a pace.
This approach to timing can also help you if you need to help the organisers to make up time after the inevitable overruns of earlier presentations / coffee breaks; something that both they and delegates tend to be grateful for.
4. Be punchy
This follows on from point 3. above. As regular readers of this column will know (and perhaps as attested to by this article) I am no stranger to verbosity. However I hope that I am quite different when presenting. While loquaciousness and elliptical arguments may have their place in written work, they are the enemy of the public speaker (and their audiences). Think about the main points that you want to cover and aim to achieve this in a crisp manner. If listeners are interested in greater detail, then they can ask questions, or chat to you about their specific queries afterwards.
5. Have a structure and tell people about it
In your presentation you are looking to convey ideas, or provide recommendations, or even just to make provocative suggestions. This is going to go a lot better if you work out in advance what you want to do and how you are going to do it. When actually presenting, it is a good idea to start out by explaining what your talk is going to cover and the broad points that you want to make. This could take the form of an agenda slide, or maybe a brief preamble according to your personal style.
In particular if you are speaking for more than say 15 minutes, it is worth breaking up your subject matter into sections. At the end of section A pause to re-emphasise the main points of what you have just covered. Pause again and introduce the next section. If you can put this into the context of the overall talk, then so much the better.
6. A picture paints a thousand words
I tend to have a somewhat visual approach to absorbing ideas and over time this has come to influence my presentation style. To illustrate how my approach has shifted, here are two slides from presentations that I have given. The first is from the Cognos Press Summit I reference at the beginning of this article. The second is a more recent presentation, dating from late 2009. I much more frequently take the latter approach nowadays.
Cognos Press Summit - Barcelona - March 2004Obis Omni Forum - London - September 2009
A more pictorial approach is likely to stick in people’s minds. Also it has the benefit of allowing you some latitude around what points you actually make while displaying the slide. There are going to be times when text is appropriate, but then it should not be so dense that you need opera glasses to read it. Again brevity is the key.
7. Don’t simply recite your bullet points
If you have some text-based slides, which is generally likely to be the case, never, ever, ever, under any circumstances simply repeat what you have written. By all means use bullet points as reminders to discuss a particular area, but assume that your audience is capable of reading themselves!
Your aim should be to use the bullets as a framework around which to weave the story that you are telling. Incidentally this is another argument for not having text-dense slides as if you have 15 bullet points and take two minutes expanding on each, you are going to spend most of your presentation on a single slide; which might become a little dull.
8. If you fail to prepare, you prepare to fail
I am not a big fan of adages, but this one stuck in my mind from early on in my professional career. Although it is a general point, I think it has particular applicability to presenting in public. This activity is not a million miles away from acting. Would you expect to go and see a stage play where the cast were constantly forgetting their lines or speaking in a dull monotone the entire time?
When you actually present, you need to be entirely comfortable about your material so that you can focus on doing the best job of presenting it. It can be nerve-wracking enough standing up to speak, but feeling that you have not prepared well enough is ten times worse. You need to do more than read through your notes a few times. You need to have run through your presentation a few times as well. Ideally this will have been via presenting to someone else.
I am lucky enough that my partner and I both have to give presentations; mine business-focussed, hers scientifically-focussed. This means that we both act as a tame audience for the other. Nevertheless I have also spent quite a bit of time in hotel rooms presenting out loud to myself or the mirror. This may seem mildly psychotic, but trust me it helps.
As mentioned above, another benefit of practice is that you can time yourself in order to get a sense of pace. If you know that you will finish in say 20 minutes with neither rushing, nor dawdling, you can relax a little more and not be constantly focused on clock-watching.
It is also useful to have a dry-run with someone who is not familiar with the subject you are speaking about. At a seminar you are not going to be presenting to people who are au fait with your day-to-day work, or the details of what your organisation does, or the issues that are important in your industry. These are things that you need to make explicit when you speak. Again my partner is invaluable here. She will point out when I say something that might be clear to me, or my colleagues, but impenetrable to the uninitiated.
One thing that is important with any run-throughs is to listen to the feedback that you get. If someone says that you went too fast or too slow, your probably did. If they say that you didn’t make a point clearly, then you probably were unclear. If you were not animated enough (or too animated) then this is something to think about addressing. This type of feedback is invaluable and should be taken constructively.
9. Embrace your nerves
Standing up to speak in front of a group of strangers is undeniably a little intimidating. Even with the number of times that I have done this myself, I still get butterflies in my stomach each time my turn to present approaches. However, I have learnt to tell myself that this is simply a build up of adrenaline and that this hormone will simply condition me to perform better.
Nerves are generally a good sign, they indicate that you care about what you are going to do and that your body is gearing up to give it your best shot. Thought of this way, apprehension can be a positive thing. In any case, it is never going to go away, so if you are going to present in public, you had better get used to it.
10. Check out the venue and your slides
I appreciate that this is not always possible, but if you can get access to the auditorium before the seminar starts, or in a break, this is invaluable. Stand on the stage. Accustom yourself to the room. Work out where you are going to stand, or if you are like me, what scope you have for pacing about. If you are going to be mic’ed-up then go through this with the sound engineer and make sure that everything is OK (also remember to turn off the mic when you are not presenting and to turn it on when you are – both easily forgotten).
If there is a pointing device, or a clicker to advance your slides, check that these work and you know how to use them. Finally flip through all of your slides, checking that the text has not been scrambled and that any builds or animations work OK. If you find a problem, there may not be time to fix it, but at least you won’t be surprised later.
11. Don’t expect to be perfect
If you have properly prepared (see point 8. above) then you will be fine. If you are OK with your material, even if you only say 75% of what you planned to say, this should not be problematic. It is inevitable that you will forget something, or even stumble over a couple of phrases here or there. The important thing is to not let this faze you, no one will notice your omission, and the occasional glitch in your delivery is to be expected. So long as you simply move on and don’t let minor set backs throw you, all will be well.
The worst thing is to focus on a small issue, which will inevitably distract you, leading you to make more mistakes and creating a spiral of death. Often if you do forget to say something on Slide X, you can say it on Slide Y instead, or mention it in the Q&A session. Telling yourself in advance that it doesn’t matter if you are not 100% perfect is perhaps a good way to set yourself up for success.
12. Try to maintain a sense of humour
I am not suggesting that you tell a lot of jokes, particularly if this is not your forte. If there is something that has raised a laugh for you previously then consider using it again, but you are not meant to be a stand-up comedian. However a certain lightness of touch never goes amiss and if you can drop in some self-deprecation along the way, this can help to engage better with your audience. No one is going to warm to an overly serious presenter, let alone a pompous one, so try to display a degree of humility as well.
13. Ask for feedback and actually review any questionnaires that you get back
The same as anything else in life the more that you present in public, the better you will get at it. Talk to the people who asked you to present and ask them how they thought things went and whether they had received any comments about your speech; listen to what they tell you. As mentioned above, it is becoming increasingly common to ask delegates to rate speakers. Instead of getting defensive about any adverse comments, think about how you could do things differently next time.
14. Be yourself
It is an essentially rather contrived thing to stand up in front of an audience and present. Above I have compared it to performing on the stage. There is however one difference. The actors in a play are adopting the personae of their characters; you are playing yourself. That is something important to remember. If you try to be someone else when presenting, you will come across as false. The fact that you have been asked to present is most likely testimony to you having done something right. Your own personality has undoubtedly played a big part in achieving this, so let it shine through.
Will slavishly following the above recommendations make you into a stellar presenter? Probably not, but there may be some things that you can take from what has worked for me, add to your own experiences, garnish with your personal style and arrive at a formula that is right for you. Good luck with this process. Presenting in public can be a very rewarding thing to do, so if you get the chance plunge right in and then maybe you can pass some tips on to me.
With enormous apologies to Randall Munroe of xkcd.com fame; from whose much funnier, and obviously more original, sketch entitled “GOTO” the above was shamelessly adapted.
Comic strip adapted with the kind permission of the copyright holder.
It has become part of the business lexicon, “he’s a big picture guy”, [by contrast] “she’s a details woman”. It is the sort of thing that you hear, file away and which maybe becomes something that colours your view of the person in question going forward.
You often hear the two things said in one breath, “Jane is great at strategy, but isn’t a details person”, “Joe can deal with the nitty gritty, but can’t grasp the big picture”. What could be more sensible to say than that? Doesn’t it chime with the old adage about not seeing the wood for the trees?
I have touched on this area a few times before. In Pigeonholing – A tragedy, I suggested that because someone is good in one area of life, it does not automatically mean that they are bad in another. In Vision vs Pragmatism I argued that both qualities were necessary for success in projects and that they could be embodied in the same person.
To employ a metaphor, in my favourite team sport, cricket, while most players tend to specialise in either batting or bowling (cf. pitching for baseball fans), a significant subset are called all-rounders and do both. While some all-rounders are bits and pieces cricketers, others excel at each discipline and would merit selection on either.
There have been many great all-round cricketers over the centuries, but most people would agree that Jacques Kallis of South Africa is probably the finest currently playing. At a much less lofty level, I used to be a wicket keeper (cf. catcher) and opening batsman, so people who are able to do more than one thing to a reasonable level of competence are not that uncommon in sport.
Foundations of sand?
However, in the more business-focussed case of big picture versus details, I would go further than merely asserting that some people can be good at both. In my opinion, it is rather hard to form an accurate big picture without at least some feeling for the details. If you do not have this firm foundation, then what is there to guarantee any legitimacy for the high-level conclusions that you draw. Findings without analysis may be correct sometimes, but it is more likely that they will not be.
Does that mean that in all circumstances minute forensic scrutiny must be paid to every single detail before deciding what to do? Is my claim the enemy of crisp decision-making and an acknowledgement that analysis paralysis is inevitable? I would say no.
Based on experience, new situations may often remind us of old ones and thereby bring ideas to mind on how to best proceed. This however is also based on the understanding of details, just historical ones, coupled with a facility to make connections between current and prior scenarios. My view is that when your gut instinct tells you to do something, it is worth pausing to kick the tyres. A sensible amount of checking of the facts is probably worth while most of the time.
A gifted Mathematician or Theoretical Physicist may develop a feeling for the general shape of a solution to a problem before they attack the details. However this is thought to be based on sub-concious analysis of lower-level factors. Whatever drives this phenomenon, the general shape of a solution is not the same as a solution and the latter will normally require a lot of painstaking work to realise.
Mulling over these analogous observations, maybe some people who claim to focus exclusively on the big picture are simply covering up the fact that they don’t have the inclination to check that their perspective is valid before offering it.
Look before it leaps
Of course there are exceptions. As a massive feline rears towards your throat, pausing to assess whether it is a leopard or lion may not be overly valuable. But in the situations we normally face, there is generally time for at least a little reflection and to dig a little deeper. To ensure accuracy without compromising speed.
The dazzling images and vibrant colours on your 55″ HD TV are there courtesy of the 2 million plus underlying pixels and the technology that controls them. If ever there was a metaphor for the big picture being based on the details, this is surely it.
The discussion included the predictable references to GIGO, but conversation then moved on to who has responsibility for data quality, IT or the business.
As regular readers of this column will know, I view this as an unhelpful distinction. My belief is that IT is a type of business department, with specific skills, but engaged in business work and, in this, essentially no different to say the sales department or the strategy department. Looking at the question through this prism, it becomes tautological. However, if we ignore my peccadillo about this issue, we could instead ask whether responsibility for data quality should reside in IT or not-IT (I will manfully resist the temptation to write ~IT or indeed IT’); with such a change, I accept that this is now a reasonable question.
Answering a modified version of the question
My basic answer is that both groups will bring specific skills to the party and a partnership approach is the one that is most likely to end in success. There are however some strong arguments for IT playing a pivotal role and my aim is to expand on these in the rest of this article.
Before I enumerate these, one thing that I think is very important is that data quality is seen as a broad issue that requires a broad approach to remedy it. I laid out what I see as the four pillars of improving data quality in an earlier post: Using BI to drive improvements in data quality. This previous article goes into much more detail about the elements of a successful data quality improvement programme and its title provides a big clue as to what I see as the fourth pillar. More on this later.
1. The change management angle
Again, as with virtually all IT projects, the aim of a data quality initiative is to drive different behaviours. This means that change management skills are just as important in these types projects as in the business intelligence work that they complement. This is a factor to consider when taking decisions about who takes the lead in looking to improve data quality; who amongst the available resources have established and honed change management skills? The best IT departments will have a number of individuals who fit this bill, if not-IT has them as well, then the organisation is spoilt for choice.
2. The pan-organisational angle
Elsewhere I have argued that BI adds greatest value when it is all-pervasive. The same observations apply to data quality. If we assume that an organisation has a number of divisions, each with their own systems (due to the nature of their business and maybe also history), but also maybe sharing some enterprise applications. While it would undeniably be beneficial for Division A to get their customer files in order, it would be of even greater value if all divisions did this at the same time and with a consistent purpose. This would allow the dealings of Customer X across all parts of the business to be calculated and analysed. It could also drive cross-selling opportunities in particular market segments.
While it is likely that a number of corporate staff of different sorts will have a very good understanding about the high-level operations of each of the divisions, it is at least probable that only IT staff (specifically those engaged in collating detailed data from each division for BI purposes) will have an in-depth understanding of how transactions and master data are stored in different ways across the enterprise. This knowledge is a by-product of running a best practice BI project and the collateral intellectual property built up can be of substantial business value.
3. The BI angle
It was this area that formed the backbone of the earlier data quality article that I referenced above. My thesis was that you could turn the good data quality => good BI relationship on its head and use the BI tool to drive data quality improvements. The key here was not to sanitise data problems, but instead to expose them, also leveraging standard BI functionality like drill through to allow people to identify what was causing an issue.
One of the most pernicious data quality issues is of the valid, but wrong entry. For example a transaction is allocated a category code of X, which is valid, but the business event demands the value Y. Sometimes it is possible to guard against this eventuality by business rules, e.g. Product A can only be sold by Business Unit W, but this will not be possible for all such data. A variant of this issue is data being entered in the wrong field. Having spent a while in the Insurance industry, it was not atypical for a policy number to be entered as a claim value for example. Sometimes there is no easy systematic way to detect this type of occurrence, but exposing issues in a well-designed BI system is one way of noticing odd figures and then – crucially – being able to determine what is causing them.
4. The IT character angle
I was searching round for a way to put this nicely and then realised that Jim Harris had done the job for me in naming his excellent Obsessive-Compulsive Data Quality blog (OCDQ Blog). I’m an IT person, I may have general management experience and a reasonable understanding of many parts of business, but I remain essentially an IT person. Before that, I was a Mathematician. People in both of those lines of work tend to have a certain reputation; to put it positively, the ability to focus extremely hard on something for long periods is a common characteristic.
Aside: for the avoidance of doubt, as I pointed out in Pigeonholing – A tragedy, the fact that someone is good at the details does not necessarily preclude them from also excelling at seeing the big picture – in fact without a grasp on the details the danger of painting a Daliesque big picture is perhaps all too real!
Improving data quality is one of the areas where this personality trait pays dividends. I’m sure that there are some marketing people out there who have relentless attention to detail and whose middle name is “thoroughness”, however I suspect there are rather less of them than among the ranks of my IT colleagues. While leadership from the pertinent parts of not-IT is very important, a lot of the hard yards are going to be done by IT people; therefore it makes sense if they have a degree of accountability in this area.
In closing
Much like most business projects, improving data quality is going to require a cross-functional approach to achieve its goals. While you often hear the platitudinous statement that “the business must be responsible for the quality of its own data”, this ostensible truism hides the fact that one of the best ways for not-IT to improve the quality of an organisation’s data is to get IT heavily involved in all aspects of this work.
IT for its part can leverage both its role as one of the supra-business unit departments and its knowledge of how business transactions are recorded and move from one system to another to become an effective champion of data quality.
I have been back blogging for a few days, so it is well past time for a rock climbing-related post. Though this site being what it is, I’ve twisted this thought round to apply to the world of IT.
Case of the Month
Symptoms: 42 year-old with recent long finger injury and resultant deformity.
Diagnosis Disruption of the A2 (white arrow), A3 (black arrow), and A4 (black arrowhead) pulleys. The primary function of the pulley system is to provide stability to the flexor tendons during flexion by fixing them to the underlying osseous structures. Injuries to the pulley system, commonly seen in rock climbers, lead to bowstringing of the flexor tendons with abnormal separation from the underlying phalanges.
Living in London, real rock is always a reasonably lengthy drive away, but in normal circumstances I would train indoors at least twice, and normally three times, a week and climb outdoors as often as possible. However, for a variety of reasons (including an ankle injury to myself, a chronic shoulder injury to my partner and both having an awful lot of other things on), I have not been climbing very much for several months. About a month ago, my partner and I decided to make a point of once more getting to the wall at least once a week. The problem is that, after a lay-off, your mind can remember climbing at a certain level but your body is way off the pace.
A combination of keenness, a desire to make up for lost time, pride and pig-headedness often sees a climber who is returning from injury quickly try to get back on to the level of routes/problems that they were achieving before. My limit, both indoors and out, used to be around V4 (fairly low down on the overall scale of climbing), with the occasional V5 indoors only. Having a few tentatively successful sessions under my belt, I found an indoor V5 that played to my strengths and was making some progress on it. It was a bit fingery and required use of a technique called crimping (see the image below):
This is a very effective way of getting purchase on small holds, but puts a lot of pressure on your fingers. Levering my body up from sitting on the ground with both hands crimping like mad I felt a sort of crunching in the ring finger of my left hand. I stopped my attempt and decided that I would warm down on some easier stuff. Sadly even easier stuff can be quite demanding on the fingers and on my next but one climb I ended up pulling quite hard on the same left hand. There was a very audible pop, my left hand exploded off of the hold and I found myself on the floor holding my swollen finger in quite some pain.
After intensive icing at the wall and some therapeutic treatment in the four or so weeks since, I am still able to bend the finger (so hopefully do not have a full rupture of the tendon), but am a long way off of going back to climbing. I also have an unhelpful mental image of the tendon hanging by a thread, it is going to take quite some time for me to get over this; even if the finger itself heals.
It doesn’t help that I fully ruptured the same tendon in my right ring finger when playing rugby as a teenager (see above). I can’t bend the top section of that finger and it has been a bit of an issue for me when climbing on occasion.
Professional climber Tommy Caldwell (above) cut off one of his fingers in a DIY accident and still climbs to an astonishingly high level, so I can’t complain too much about this earlier injury. However I am now rather concerned about having matching tendon problems on both hands. I guess time will tell how serious this new injury is and what level of recovery I will experience. I hope to be able to avoid surgery, which is in any case no guarantee of a cure.
One of the most frustrating aspects of all this is that I feel as if I had a warning with the initial crunchiness, I chose to ignore this, which then led to the more serious injury. I guess it rather feels that I could have avoided getting myself in this situation with a little more thought.
The learning here is twofold: specifically how easy it is to injure yourself when returning from a lay-off; and generally that it is also much too tempting to try things that you are not yet ready for – to run before you can walk. The first lesson applies to climbing and sport in general, the second has wider applicability and some pertinence to the work of IT in particular.
…and Fugue
Running before you can walk seems to be something that particularly afflicts IT departments and IT people when they are in a bit of a hole already. If an IT department has been under-performing, or has become semi-detached from the business (the latter often leading to the former), there can be a desperate desire to get onto firmer ground quickly. I have seen this manifest itself in a couple of ways:
An overwhelming urge to do something that will be appreciated by the business and make a difference – here the desire is for a quick redemption, unfortunately the concomitant rushing and even omission of key steps in the development process are just as likely to lead to more business disappointment and an increasingly tarnished reputation.
The second symptom is virtually antipodal to the first; an unhealthy clinging to formal methodologies, or (much worse) an attempt to introduce new and improved ones – this can have almost a totemic quality, as if by simply adhering to ISO 9000 / Agile / ITIL / RAD (delete as appropriate) things will miraculously turn around.
Unfortunately both of these extremes are essentially displacement activities. I have led the turn-around of a number of IT teams. In my experience, what is generally required is a heavy dose of pragmatism and a focus on doing the basics well and without any elaboration whatsoever. It is nearly always best to try to fix the existing machine, or at most to tinker with it slightly in the first instance, rather than to make drastic modifications or try to build a new machine in entirety.
When IT is under-performing it is not normally a case of absent or ill-adhered to formal procedures. Rather the malaise is more likely to be a human one, relating to a lack of leadership and direction, a consequent lack of motivation and a group that begins to spiral in on itself. If the problem is essentially with people, then the solution often lies with them as well. It is not easy to motivate demotivated people, it is not easy to provide direction to those who are lost. However both of these things are easier to do than relying on the same lost and demotivated people to either make lighting fast redemptive deliveries, or to cheerfully adopt a new and fool-proof development methodology.
If a formal methodology is important – and it generally is – then my recommendation is to implement this once you have put a lot of effort into creating a happier and better functioning IT team. It is a bit like the old adage about not outsourcing a problem. Best practice instead is to resolve the issues and only then outsource a functioning process.
It is worth also saying that, as well as being more effective, working to make your team happier and more functional is a lot more rewarding and a lot more fun. If you achieve this it is amazing how much more easily the successful system deliveries start to flow.
Coda
In business, as in rock climbing, if you try to run before you can walk, try to jump to the desired end-state without putting in the necessary hard work, then you are only likely to get hurt. If you don’t believe me, I can tell you all about my finger injury again.
The context of the above bon mot was – as is often the case – a discussion on LinkedIn.com. I have been rather absent from the LinkedIn.com discussion groups for the same reasons that I have not been blogging and tweeting. In this case, my attention was drawn to the debate by a colleague.
The particular thread was posted by Andy McKnight and is entitled What’s missing from Business Intelligence? and at the time of writing has attracted nearly 60 responses (you have to be a member of the group to view the discussion). It referred to an article published by EMC2 which has the strap-line How CIOs can Reap the Benefits of BI Technology (note: this is a PDF document). Here is a pertinent quote:
The bad news is that only twenty-seven percent of respondents [to a survey of CIOs carried out by IDG Research] who use a BI solution report being extremely successful or very successful with it. Forty-five percent report being only somewhat successful, while seventeen percent say that they are not very, or not at all successful.
I’m not sure what happened to the other 11% of respondents, maybe they just hung up the ‘phone.
Blaming the users
Having stated that “BI has, too often, not lived up to expectations”, the paper goes on to list some reasons why. First on the list is the following:
lack of adoption by users
You don’t have to be Einstein to realise that this is the result of a BI project failing, not the cause of it. The equivalent in athletics terms would be to say that you came last in the race because everyone else was faster than you. While obviously true this observation doesn’t help a lot with how to do better next time.
Of course hidden in the comment is the plaintive whine heard emanating from many an unsuccessful project (or indeed product launch), “the problem is the users”. This is arrant nonsense, returning to the start of article if you write a book that is panned by the critics and not bought by the public, then there is at least some chance that the fault lies with you and not them. It is the job of the IT professional to know their users, understand their needs and provide systems that cause delight, not disillusion.
A more interesting observation later on is:
Many BI initiatives falter because the analytics capabilities that are at the core of the system aren’t even used. Many users simply pull data from the warehouse and dump it in a spreadsheet. […] A true BI implementation includes both reporting and analytics. CIOs indicate a much higher success rate with BI when users embrace both.
I think that there is some truth in this. Some of the BI failures I have seen have gone to the bother of building a warehouse only to front it with flat reports that are only marginally better than what they replaced.
In my career I have taken the opposite approach. While many people warn against analysis paralysis, I have deployed OLAP tools to all users, with fixed format reports de-emphasised, or used mostly for external purposes. This does mean that more effort needs to be put into training, but this is necessary anyway if you want your BI system to be an agent of change (and why else would you be building one if this is not the case?). I cover my general approach to driving user adoption in a series of three articles as follows:
This approach was very successful and we achieved user adoption of 92% – i.e. of those people who attended training, 92% remained active users (defined as using the BI system on average for at least two extended periods each week). We actually felt that the OLAP tools we were implementing were pretty intuitive and easy-to-use and so focussed mostly on how to use them in specific business scenarios. Overall we felt that training was 25% technical and 75% business-related.
Aiming for simplicity
Related to the above point, the EMC2 article also mentions the following reason for failure:
limited functionality/hard to use
This seems a little oxymoronic as normally it is depth of functionality that confuses people. I think I would disagree with both parts of this point. Out of the box, most BI tools have rich functionality and a reasonably intuitive to use. In one response to the LinkedIn.com thread I said the following:
I have been successful in getting users […] weaned […] off ad hoc reports, it wasn’t an easy process and required persistence and selling, but this paid off. […] It is illuminating seeing business managers (some of whom still dictate memos for their secretaries to type) “slicing and dicing”, drilling down/through and generally interacting away merrily and stating that if all IT was this easy to use and informative, they might have taken to it earlier.
My view here is that you can make the tool as complicated or a simple as you choose. Going back to my first warehouse project, in our somewhat naive early attempts at prototype cubes, we had all available dimensions and all available measures included. I think our idea is that the users could help us sift out the ones that were most important. Instead this approach caused the negative reactions that the article refers to.
We subsequently adopted a rule of having as few dimensions and measures as possible in a cube, without compromising the business need that the cube was trying to address. The second part of this rule was that every cube had to be focussed on answering business questions in at least one area and at most two.
Rather than having a small number of monolithic cubes, we went with the option of a slightly larger number of significantly clearer and simpler ones. I think that this was a factor in our success in driving business adoption.
Should the fact that some BI projects fail dissuade you from BI?
I won’t attempt to dissect the rest of the article, the areas that I comment on above are representative. There are some good points and some less good ones – just like any article, including of course my own. Take a look yourself and see whether the findings and recommendations chime with your own experience of success and failure. What I did want to do was to return to the context of the aphorism that starts this post.
The thesis of the original LinkedIn.com post was that because a significant number of organisations had failed to get enormous benefit from BI, BI itself was therefore somehow flawed. I think this is wrong-headed reasoning. If 1,000 people write a book, how many are likely to become acknowledged as great authors? How many are likely to have the lesser accolade of commercial success? The answer in both cases is “not many”. This is because writing well is a very difficult thing to do (I prove this myself with every blog post!). Not everyone who tries it will be successful. BI is also difficult to do well and a major cause of problems is underestimating this difficulty.
Maybe this is too recherché and example, and maybe if the chances of success with BI are as slim as winning the Purlitzer Prize then it is not worth the effort. So I’ll instead I’ll resort to my favourite area of the sporting analogy. Let’s take the same 1,000 people and say that they all take up a new sport – it is mostly immaterial what the sport is, let’s say tennis. How many of them will go on to become proficient in it? By this I don’t mean that they are the next Roger Federer, just that they become competent enough to serve adequately, master the dark arts of the backhand and sustain a few rallies. My feeling is that the stats would look something like those in the EMC2 report.
Is the prize worth it?
Given this, does it mean that some companies are just not cut out for BI and should ignore the area? Well the answer is “it depends”. Going back to tennis, if some one wants to be good, and has the determination to succeed, that is a necessary (though sadly not sufficient) condition. What may drive such a person on is the objective of achieving a goal, or maybe the pleasure of being able to perform at a certain level.
Focussing on business outcomes, I believe that BI can deliver substantial benefits. In fact I have argued elsewhere that BI can have the greatest payback of any IT project. Of course this presupposes that the BI project is done well. If the prize is potentially that great then maybe – like the aspiring tennis player who wants to become better – trying again makes sense. In recent recruitment I have heard frequent mention of organisations that were building their second warehouse as they didn’t get the first one quite right.
However the comparison with tennis breaks down in that business is a team game. If an organisation as a whole has struggled with BI, then this is not a question of simply accepting your genetic limitations. Companies can “evolve” capabilities by hiring people who have been successful in a field. They can also get benefit from targeted consultancy from practitioners who have a track record of success; this can help them to build an internal capability. This is an approach that I took advantage of myself in the initial six months of my first BI project [note: although I often seem to get mistaken for a BI consultant, I am not touting for business here!].
This means that if a company’s BI architecture is currently the equivalent of a Jeffrey Archer novel, it is still possible to transform it into Heart of Darkness. It will not be easy and will take time and effort, but there are people out there who have been successful and can act as guides.
In closing I should also mention that, if you take appropriate precautions, it is far from inevitable that the end of a BI journey will be finding your own version of Kurtz!
I last published a list of the most popular articles on this site at the beginning of July 2009. As I mentioned a couple of days ago, I had a hiatus in blogging which started at the beginning of August 2009. This means that readership figures since then have not been skewed by when articles were posted (they were all posted before the pertinent period).
The following is a list of the top twenty articles in descending order of hits per day over the last eight months.
![A blue[stone]print for your presentation](https://peterjamesthomas.com/wp-content/uploads/2010/03/stonehenge.jpg?w=700 "A blue[stone]print for your presentation")
!["Users are the root of all evil" - anonymous [failed] BI Project Manager](https://peterjamesthomas.com/wp-content/uploads/2010/03/down-with-users.jpg?w=700 "\"Users are the root of all evil\" - anonymous [failed] BI Project Manager")
Peter James Thomas 