Several weeks back now, I presented at IRM’s collocated European Master Data Management Summit and Data Governance Conference. This was my second IRM event, having also spoken at their European Data Warehouse and Business Intelligence Conference back in 2010. The conference was impeccably arranged and the range of speakers was both impressive and interesting. However, as always happens to me, my ability to attend meetings was curtailed by both work commitments and my own preparations. One of these years I will go to all the days of a seminar and listen to a wider variety of speakers.

Anyway, my talk – entitled Making Business Intelligence an Integral part of your Data Quality Programme – was based on themes I had introduced in Using BI to drive improvements in data quality and developed in Who should be accountable for data quality?. It centred on the four-pillar framework that I introduced in the latter article (yes I do have a fetish for four-pillar frameworks as per):

Given my lack of exposure to the event as a whole, I will restrict myself to writing about a comment that came up in the question section of my slot. As per my article on presenting in public, I try to always allow time at the end for questions as this can often be the most interesting part of the talk; for delegates and for me. My IRM slot was 45 minutes this time round, so I turned things over to the audience after speaking for half-an-hour.

There were a number of good questions and I did my best to answer them, based on past experience of both what had worked and what had been less successful. However, one comment stuck in my mind. For obvious reasons, I will not identify either the delegate, or the organisation that she worked for; but I also had a brief follow-up conversation with her afterwards.

She explained that her organisation had in place a formal data governance process and that a lot of time and effort had been put into communicating with the people who actually entered data. In common with my first pillar, this had focused on educating people as to the importance of data quality and how this fed into the organisation’s objectives; a textbook example of how to do things, on which the lady in question should be congratulated. However, she also faced an issue; one that is probably more common than any of us information professionals would care to admit. Her problem was not at the bottom, or in the middle of her organisation, but at the top.

In particular, though data governance and a thorough and consistent approach to both the entry of data and transformation of this to information were all embedded into the organisation; this did not prevent the leaders of each division having their own people take the resulting information, load it into Excel and “improve” it by “adjusting anomalies”, “smoothing out variations”, “allowing for the impact of exceptional items”, “better reflecting the opinions of field operatives” and the whole panoply of euphemisms for changing figures so that they tell a more convenient story.

In one sense this was rather depressing, someone having got so much right, but still facing challenges. However, it also chimes with another theme that I have stressed many times under the banner of cultural transformation; it is crucially important than any information initiative either has, or works assiduously to establish, the active support of all echelons of the organisation. In some of my most successful BI/DW work, I have had the benefit of the direct support of the CEO. Equally, it is is very important to ensure that the highest levels of your organisation buy in before commencing on a stepped-change to its information capabilities.

My experience is that enhanced information can have enormous payback. But it is risky to embark on an information programme without this being explicitly recognised by the senior management team. If you avoid laying this important foundation, then this is simply storing up trouble for the future. The best BI/DW projects are totally aligned with the strategic goals of the organisation. Given this, explaining their objectives and soliciting executive support should be all the easier. This is something that I would encourage my fellow information professionals to seek without exception.
 

Introduction

Last week Ovum and @SarahBurnett were kind enough to invite me to speak at their Business Intelligence Masterclass in London.

Unfortunately one of the Ovum presenters, Madan Sheina, was ill, but Sarah did a great job running the session. The set up of the room and the number of delegates both encouraged interaction and there was a great atmosphere with lots of questions from the attendees and some interesting exchanges of ideas. Work commitments meant that I had to leave after lunch, which was a shame as I am sure that – based on what I saw in the morning – the afternoon workshops sessions would have been both entertaining and productive.

I certainly enjoyed my presentation – on Initiating and Developing a BI Strategy – which focussed on both my framework for success in Business Intelligence and, in particular, addressing the important cultural transformation aspects of these. Thank you also to the delegates both for the questions and observations and for kindly awarding my talk an 83% rating via the now ubiquitous seminar questionnaire.
 
 
Bouldering and Cultural Transformation

My partner bouldering the classic Boysen's Groove in Snowdonia

As part of my section on change management, I covered some of the themes that I introduced in my article Perseverance. In this I spoke about one of the types of rock climbing that I enjoy; bouldering. Bouldering is regular rock climbing on steroids, it is about climbing ultra-hard, but short climbs; often on boulders – hence the name. I compared the level of commitment and persistence required for success in bouldering to the need for the same attributes in change management initiatives.

I spoke to a few different delegates about this analogy during a coffee break. One in particular came up with an interesting expansion on my rock climbing theme. He referred to how people engaged in mountaineering and multi-pitch rock climbing make progress in a series of stages, establishing a new base at a higher point before attempting the next challenge. He went on to link this to making incremental progress on IT projects. I thought this was an interesting observation and told the gentleman in question that he had provided the inspiration for a future blog article.
 
 
An introduction to lead climbing

The above video is excerpted from the introduction to Hard Grit a classic 1998 climbing film by Slackjaw productions. It features climbing on the Gritstone (a type of hard sandstone) edges of the UK’s Peak District. This famous sequence shows a pretty horrendous fall off of a Peak District test piece called Gaia at Black Rocks. Amazingly the climber received no worse injuries than a severely battered and lacerated leg. Despite its proximity to my home town of London, Gritstone climbing has never been my cup of tea – it is something of an acquired taste and one that I have never appreciated as much as its many devotees.

As an aside you can see a photo of a latter-day climber falling off the same route at the beginning of my article, Some reasons why IT projects fail. I’m glad to say in this photo, unlike the video above, the climber is wearing a helmet!

What the clip illustrates is the dangers inherent in the subject of this article; traditional lead climbing. OK the jargon probably needs some explanation. First of all climbing is a very broad church, in this piece I’ll be ignoring whole areas such as mountaineering, soloing and the various types of winter and ice climbing. I am going to focus on roped climbing on rock, something that generally requires dry weather (unless you are a masochist or the British weather changes on you).

In this activity, one person climbs (unsurprisingly the climber) and another holds the rope attached to them (the belayer). The belayer uses a mechanism called a belay device to do this, but we will elide these details. With my background in Business Intelligence, I’ll now introduce some dimensions with which you can “slice and dice” this activity:
 

1. multi-pitch / single pitch
   

   ---

   Single-pitch climbs are shorter than a length of rope (typically 50-70m) and often happen on rock outcrops such as in the Peak District mentioned above. The climber completes the climb and then the belayer may follow them up if they want, or alternatively the climber might walk round to find an easy decent and the pair will then go and find another climb.
    

   ---

   Multi-pitch climbs consist of at least two pitches; and sometimes many more. They tend to be in a mountain environment. One person may climb a pitch and then alternate with their partner, or the same person may climb each section first. It depends on the team.
    
2. top roping / leading
   

   ---

   Top roping is not a very precise term (bottom roping might be more accurate) but is generally taken to mean that the rope runs from the belayer, to the top of the climb and then down to the climber.

   

   As the climber ascends, the belayer (hopefully!) takes in the slack, but (again hopefully!) without hauling the climber up the route. This means that if the climber falls (and the belayer is both competent and attentive) they should be caught by the rope almost immediately. Obviously this arrangement only works on single-pitch climbs.
    

   ---

   In lead climbing, or leading, the rope runs from the belayer up to the climber. As the climber ascends, they attach the rope to various points in the rock on the climb (for how they do this see the next bullet point).

   

   Assuming that the climber is able to make a good attachment to the rock (again see next point) the issue here is how far they fall. If they climb 2m above their last attachment point, then a slip at this point will see them swinging 2m below this point – a total fall of 4m, much longer than when top roping. Also if the last attachment point is say 10m above the ground and the climber falls off say 8m above this, then slack in the system and rope stretch will probably see them hit the ground; something that should never happen in top roping.

   [As an aside true top roping is what happens when the belayer climbs up after the climber. Here they are now belayed by the original climber from above. However no one uses the term top roping for this, instead they talk about bringing up the second, or seconding. Top roping is reserved for the practice of bottom roping described above, no one said that climbing was a logical sport!]
    

3. sport / traditional

   In the last point I referred to a lead climber mysteriously attaching themselves to the rock as they ascend. The way that they do this determines whether they are engaged in sport or traditional climbing (though there is some blurriness around the edges).
    

   ---

   In sport climbing, holes are pre-drilled into the rock at strategic intervals (normally 3-5m apart, but sometimes more). Into these are glued either a metal staple or a single bolt with a metal hanger on it that has a hole in it.

   

   The process of equiping a sport route in this way can take some time, particularly if it is overhanging and of course it needs to be done well if the bolts are to hold a climber’s fall. A single-pitch sport climb may have 10 or more of these bolts, plus generally a lower-off point at the top.

   

   The climber will take with them at least the same number of quick draws as there are bolts. These are two spring-loaded carabiners joined by a section of strong tape. As the climber ascends, they clip one end of a quick-draw to the staple or hanger and the other end over the rope attaching them to their belayer.

   So long as the person who drilled and inserted the bolts did a good job and so long as the climber is competent in clipping themselves into these; then sport climbing should be relatively safe. At this point I should stress that I know of good climbers who have died sport climbing, often by making a simple mistake, often after having completed a climb and looking to lower off. Sport climbing is a relatively safer form of climbing, but it is definitively not 100% safe; no form of climbing is.

   Because of its [relative] safety, sport climbing has something of the ethos of bouldering, with a focus on climbing at your limit as the systems involved should prevent serious injury in normal circumstances.
    

   ---

   In traditional climbing (uniformly called trad) the difference is that there are no pre-placed bolts, instead the climber has to take advantage of the nature of the rock to arrange their own attachment points. This means that you have to take the contents of a small hardware store with you on your climb. The assorted pieces of gear that you might use to protect yourself include:

   Nuts/wires (which you try to wedge into small cracks):

   

   Hexes (which you try to wedge into large cracks):

   

   Cams/Friends (spring-loaded mechanical devices that you place in parallel cracks – the latter name being a make of cams):

   

   Slings (which you use to lasso spikes, or thread through any convenient holes in the rock):

   

   Once you have secured any of the above into or around the rock, you clip in with a quick-draw as in Sport climbing and heave a sigh of relief.
    

In the video that started this section, Jean-minh Trin-thieu falls (a long way) on to a cam, which thankfully holds. The issue on this particular climb is that there are no more opportunities to place gear after the final cam at round about half-way up. The nature of the rock means that a lot of Gritsone climbing is like this; one of the reasons that it is not a favourite of mine.

In any case, having established the above dimensions, I am going to drill down via two of them to concentrate on just trad leading. My comments apply equally to multi- and single-pitch, but the former offers greater scope for getting yourself into trouble.
 
 
The many perils of trad leading

Dave Birkett on 'Nowt Burra Fleein' thing' E8 6c, Cam Crag, Wasdale, The English Lake District - © Alastair Lee - Posingproductions.com

One of the major issues with trad climbing, particularly multi-pitch trad climbing in a mountain environment is that you are never quite sure what you need to take. The more gear you clip to your harness, the more likely you are to be able to deal with any eventuality, but the heavier you are going to be and the harder it will be to climb. Some one once compared trad leading to climbing wearing a metal skirt.

The issue here is that not only do you have to find somewhere to place this protective gear, you have to place it well so that is not dislodged as you climb past, or pulls out if you fall. What adds to this problem is that you may have to try to place say a wire in a situation where you are holding on to a small hold with one hand, with only one foot on a hold and the other dangling. You may also be on an overhang and thus with all gravity’s force coming to bear on your tendons. At such moments thoughts like “how far below was my last piece of gear?”, “how confident am I that I placed it well?” and “what happens if I can’t fiddle this piece of metal into this crack before my fingers un-peal?” tend to come to mind with alarming ease.

It is not unheard of for a trad leader to climb up many metres, placing an assortment of gear en route, only to fall off and have all of it rip out, a phenomenon call “unzipping”, thankfully not something I have experienced directly; though I have seen it happen to other people.

These additional uncertainties tend to lead to a more cautious approach to trad leading, with many people climbing within their abilities on trad climbs. Some people push themselves on trad and some get away with it for a while. However there is a saying about there being old climbers and bold climbers, but no old bold climbers.
 
 
The links with business projects

I have written quite a few times before about the benefits of an incremental approach, so long as this bears the eventual strategic direction in mind (see for example: Tactical Meandering and Holistic vs Incremental approaches to BI). In rock climbing, even within a single pitch, it is often recommended to break this into sections, particularly if there are obvious places (e.g. ledges) where you can take a bit of a rest and consider the next section. This also helps with not being too daunted; often the biggest deal is to start climbing and once you are committed then things become easier (though of course this advice can also get you in over your head on occasion).

Splitting a climb into sections is a good idea, but – in the same way as with business projects – you need to keep your eye on your eventual destination. If you don’t you may be so focussed on the current moves that you go off route and then have to face potentially difficult climbing to get back where you need to be. The equivalent in business would be projects that do not advance the overall programme.

However the analogy doesn’t stop there. If we break a single-pitch trad lead climb into smaller sections, those between each piece of gear that you place, then it is obvious that you need to pay particular attention to the piece of equipment that you are about to employ. If you do this well, then you have minimised the distance that you will fall and this will bolster your confidence for the next piece of climbing. If you rush placing your gear, or assume that it is sort of OK, then at the best you will give yourself unnecessary concerns about your climbing for the next few metres. At worst a fall could lead to this gear ripping and a longer fall, or even hitting the ground.

In business projects, if you take an incremental approach, then in the same way you must remember that you will be judged on the success or failure of the most recent project. Of course if you have a track record of earlier success then this can act as a safety net; the same as when your highest piece of gear fails, but the next one catches you. However, it is not the most comfortable of things to take a really long leader fall and similarly it is best to build on the success of one project with further successes instead of resting on your laurels.

Of course the consequences of rushing your interim steps in rock climbing can be a lot more terminal than in business. Nevertheless failure in either activity is not welcome and it is best to take every precaution to avoid it.
 

	Tweet this article on twitter.com

Bookmark this article with:
| Facebook	| del.icio.us	| digg	| Reddit	| Stumble

A2 pulley injuries. Partial tear (left) and complete tear (right).
Images © Eric J. Horst, via www.nicros.com

Back in May 2009 I wrote about The importance of feasibility studies in business intelligence. More recently I penned a piece entitled Running before you can walk, which compared the circumstances behind me injuring my finger rock climbing to how IT teams can sometimes behave when under pressure.

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!
 

	Tweet this article on twitter.com

Bookmark this article with:
| Facebook	| del.icio.us	| digg	| Reddit	| Stumble

		CIO Magazine forum

Asking the wrong question

Once more this post is inspired by a conversation on LinkedIn.com, this time the CIO Magazine forum and a thread entitled BI tool[s] can not deliver the expected results unless the company focuses on quality of data posted by Caroline Smith (normal caveat: you must be a member of LinkedIn.com and the group to view the actual thread).

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.

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.
 

	Tweet this article on twitter.com

Bookmark this article with:
| Facebook	| del.icio.us	| digg	| Reddit	| Stumble

Jeffrey Archer	Joseph Conrad

Introduction

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.

	CIOs.com: Chief Information Officer Network

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 EMC² 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:

• Marketing Change
• Education and cultural transformation
• Sustaining Cultural Change

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 EMC² 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 EMC² 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!
 

	Tweet this article on twitter.com

Bookmark this article with:
| Facebook	| del.icio.us	| digg	| Reddit	| Stumble

Once more I have decided to pen this article based on a question that was raised on LinkedIn.com. The group in question on this occasion was Business Intelligence and the thread was entitled Is it time that the CBIO (Chief Business Intelligence Officer) position and organization become commonplace in today’s corporate structure? This was posted by John Thielman.

Standard note: You need to be a member of both LinkedIn.com and the group mentioned to view the discussions.
 
 
The case for a CBIO

I won’t republish all of John’s initial post, but for those who cannot access the thread these are the essential points that he raised:

1. There is an ever-increasing need for more and better information in organisations
2. Increasingly Business Intelligence is seen as a major source of competitive advantage
3. A CBIO would bring focus and (more importantly) accountability to this area
4. The CBIO should report directly to the CEO, with strong relations with the rest of the executive team
5. The CBIO’s team would be a hybrid business / technical one (as I strongly believe the best BI teams should be)
6. This team should also be at the forefront of driving change, based on the metrics that it generates

Now obviously creating a senior role with a portfolio spanning BI and change is going to be music that falls sweetly on my ears. I did however attempt to be objective in my response, which I reproduce in full below:

As someone who is (primarily) a BI professional, then of course my response could be viewed as entirely self-serving. Nevertheless, I’ll offer my thoughts.

In the BI programmes that I have run, I have had reporting lines into people such as the CIO, CFO or sometimes a combined IT / Operations lead. However (and I think that this is a big however), I have always had programme accountability to the CEO and have always had the entire senior leadership team (business and service departments) as my stakeholders. Generally my direction has come more from these dotted lines than from the solid ones – as you would hope would be the case in any customer-centric IT area.

I have run lots of different IT projects over the years. Things such as: building accounting, purchasing and sales systems; configuring and implementing ERP systems; building front-end systems for underwriters, marketing and executive teams; and so on. Given this background, there is definitely something about BI that makes it different.

Any IT system must be aligned to its users’ needs, that much is obvious. However with BI it goes a long way beyond alignment. In a very real sense, BI systems need to be the business. They are not there to facilitate business transactions, they are there to monitor the heartbeat of the organisation, to help it navigate the best way forward, to get early warning of problems, to check the efficacy of strategies and provide key input to developing them.

In short a good BI system should be focussed on precisely the things that the senior leadership team is focussed on, and in particular what the CEO is focussed on. In order to achieve this you need to understand what makes the business tick and you need to move very close to it. This proximity, coupled with the fact that good BI should drip business value means that I have often felt closer to the overall business leadership team than the IT team.

Please don’t misunderstand my point here. I have been an IT person for 20 years and I am not saying that BI should not be fully integrated with the overall IT strategy – indeed in my book it should be central to it as a major function of all IT systems is to gather information (as well as to support transactions and facilitate interactions with customers). However, there is something of a sense in which BI straddles the IT and business arenas (arenas that I have long argued should be much less distinct from each other than they are in many organisations).

The potentially massive impact of BI, the fact that it speaks the language of business leaders, the need for it to be aligned with driving cultural change and that the fact that the skills required for success in BI are slightly different for those necessary in normal IT projects all argue that something like a CBIO position is maybe not such a bad idea.

Indeed I have begun to see quite a few BI roles that are part of change directorates, or the office of the CEO or CFO. There are also some stand-alone BI roles out there, reporting directing to the board. Clearly there will always be a strong interaction with IT, but perhaps you have detected an emerging trend.

I suppose a shorter version of the above would run something like: my de facto reporting line in BI programmes has always been into the CEO and senior management team, so why not recognise this by making it a de jura reporting line.

BI is a weird combination of being both a specialist and generalist area. Generalist in needing to play a major role in running all aspects of the business, specialist in the techniques and technologies that are key to achieving this.
 
 
Over to the jury

Maybe the idea of a CBIO is one whose time has come. I would be interested in people’s views on this.
 

	Tweet this article on twitter.com

Bookmark this article with:
Technorati	| del.icio.us	| digg	| Reddit	| Stumble

I have been a featured blogger on SmartDataCollective.com almost as long as I have been a blogger. SDC.com is Social Media Today’s community site, focussed on all aspects of Business Intelligence, Data Warehousing and Analytics, with a pinch of social media thrown in to the mix.

Brian Roger, the SDC.com editor, was recently kind enough to interview me about my career in BI, the challenges I have faced and what has helped to overcome these. This interview is now available to listen to as part of their Podcast series – click on the image below to visit their site.

SmartDataCollective.com Intervew

I would be interested in feedback about any aspect of this piece, which I am grateful to Brian for arranging.
 

Social Media Today LLC, is a battle-tested, nimble team of former journalists, online managers, and advertising professionals who have come together to make a new kind of media company. With their backgrounds, and passions for, business-to-business and public policy conversations, they have decided to focus their efforts in this area. To facilitate the types of convresations that they would like to see Social Media Today is assembling the world’s best bloggers and providing them with an independent “playground” to include their posts, to comment and rate posts, and to connect with each other. On their flagship site, SocialMediaToday.com, they have brought together many of the most intriguing and original bloggers on media and marketing, covering all aspects of what makes up the connective tissue of social media from a global perspective.
 

	Tweet this article on twitter.com

Bookmark this article with:
Technorati	| del.icio.us	| digg	| Reddit	| Stumble

Following on from my series of posts about the inaugural Chase Zander IT Director Forum that I helped to organise earlier in the year, a report covering the event, which was held in Birmingham, has just been released by Chase Zander themselves.

Anyone interested in learning more about what goes on at these events is welcome to view the document, a PDF version of which may be downloaded here.
 

 
Registration starts at 17:30 and the event itself kicks of at 18:15.

Details of the programme will be published nearer the date.

Attendance is free, but prior registration is required. Please mail Emily White at emily.white@chasezander.com or call her on 0870 997 9014.
 

	Tweet this article on twitter.com

Bookmark this article with:
Technorati	| del.icio.us	| digg	| Reddit	| Stumble

As always any LinkedIn.com links require you to be a member of the site and the group links require you to be a member of the group.

In recent weeks, I have posted two pieces relating how a discussion thread on the LinkedIn.com Chief Information Officer (CIO) Network group had led to an article on TechRepublic. The first of these was, The scope of IT’s responsibility when businesses go bad and the second, “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic.

This week, by way of variation, I present an article on TechRepublic that has led to heated debate on the LinkedIn.com Organizational Change Practitioners group. Today’s featured article is by one of my favourite bloggers, Ilya Bogorad and is entitled, Lessons in Leadership: How to instigate and manage change.

The importance of change management in business intelligence projects and both IT and non-IT projects in general is of course a particular hobby-horse of mine and a subject I have written on extensively (a list of some of my more substantial change-related articles can be viewed here). I have been enormously encouraged by the number of influential IT bloggers who have made this very same connection in the last few months. Two examples are Maureen Clarry writing about BI and change on BeyeNetwork recently (my article about her piece can be read here) and Neil Raden (again on BeyeNetwork) who states:

[...] technology is never a solution to social problems, and interactions between human beings are inherently social. This is why performance management is a very complex discipline, not just the implementation of dashboard or scorecard technology. Luckily, the business community seems to be plugged into this concept in a way they never were in the old context of business intelligence. In this new context, organizations understand that measurement tools only imply remediation and that business intelligence is most often applied merely to inform people, not to catalyze change. In practice, such undertakings almost always lack a change management methodology or portfolio.

You can both read my reflections on Neil’s article and link to it here.

Ilya’s piece is about change in general, but clearly he brings both an IT and business sensibility to his writing. He identifies five main areas to consider:

1. Do change for a good reason
2. Set clear goals
3. Establish responsibilities
4. Use the right leverage
5. Measure and adjust

There are enormous volumes of literature about change management available, some academic, some based on practical experience, the best combining elements of both. However it is sometimes useful to distil things down to some easily digestible and memorable elements. In his article, Ilya is effectively playing the role of a University professor teaching a first year class. Of course he pitches his messages at a level appropriate for the audience, but (as may be gauged from his other writings) Ilya’s insights are clearly based on a more substantial foundation of personal knowledge.

When I posted a link to Ilya’s article on the LinkedIn.com Organizational Change Practitioners group, it certainly elicited a large number of interesting responses (74 at the time of publishing this article). These came from a wide range of change professionals who are members. It would not be an overstatement to say that debate became somewhat heated at times. Ilya himself also made an appearance later on in the discussions.

Some of the opinions expressed on this discussion thread are well-aligned with my own experiences in successfully driving change; others were very much at variance to this. What is beyond doubt are two things: more and more people are paying very close attention to change management and realising the pivotal role it has to play in business projects; there is also a rapidly growing body of theory about the subject (some of it informed by practical experience) which will hopefully eventually mature to the degree that parts of it can be useful to a broader audience change practitioners grappling with real business problems.
 

	Tweet this article on twitter.com

Bookmark this article with:
Technorati	| del.icio.us	| digg	| Reddit	| Stumble

Yesterday I was moved to post the above section from one of my favourite books on the LinkedIn.com Organisational Change Practitioners forum. The precise thread was entitled, Commitment during Change (as ever you need to be a member of LinkedIn.com and thr group to access the preceding links). The context was an increasingly intricate discussion about what constituted a “burning platform”; if this was a good thing to be standing on, or not; and whether such a situation was likely to lead to a positive or negative reaction on behalf of those standing on it.

My first contribution to this section of the discussion was as follows (with some light editing):

A burning platform tends to suggest panic and an imperative to do something (anything) right now. Think about it; the burning bit and… well… being on a platform. I am not sure that this is the best metaphor for instilling commitment.

Commitment may be passionate, but it is more rational, more of an active choice as opposed to, “what do I have to do to get out of here, my toes are getting hot?”

Telling someone that they are on a burning platform will certainly get their attention – they may also be willing to listen to you if you have some suggestion that might help, but this does not sound like instilling commitment in them to me; more like instilling fear.

Commitment tends to suggest a belief on behalf of the committed that what they are being asked to do is right for them and necessary for the broader organisation (despite it potentially being difficult and/or painful).

Commitment is not fleeing a burning platform – that’s just a survival instinct. Instead commitment might be exhibited by a person deciding to return to a burning platform to rescue some one.

The Alice quote came after I had posted the above thoughts, but before the post that I wanted to focus on in this article. This was about professional jargon and was as follows (again lightly edited):

When I was studying Mathematics, the use of words to mean something other than their ordinary meaning became second nature. The uninitiated would never have guessed the recherché meanings we ascribed to everyday words such as “ring”, “field” or “group”.

Early in my IT career I went over to the dark side, quoting impenetrable acronyms with the best of them. However as my role became more part of the business, I had something of an epiphany. I realised that people were not really that impressed by jargon, that they were more likely to assume (sometimes correctly) that the jargon-user was trying to cover something up or sound clever, and that maybe there was a better way.

Nowadays I am sometimes guilty of using complicated English, but I hope that it is mostly just English (as opposed to English 2.0 – now with even more terminology and even less meaning). I will crave your indulgence about the bit of French above of course :-o.

I think that jargon is both useful and inescapable when communicating efficiently with fellow professionals in a field (no not the Maths meaning of “field”); in all other cases it is mostly a hindrance to being understood.

Now I am sure that an assidious reader would have no problem whatsoever in finding counter-examples to my call for plain-speaking about IT; they are probably sprinkled liberally throughout this blog. Maybe this is a case of doing what I say, rather than what I do. However, it is interesting the number of commentators who have suggested that it would help IT professionals to increase their standing with their colleagues if they dropped the technical jargon and learned to speak more like a business person (e.g. see my comments on Ilya Bogorad’s article about Talking Business).

While getting business people to terminate their love affair with their own version of jargon might be wishful thinking, it is pleasing to go beyond Ilya’s recommendation and contemplate a world where a spade is called a spade and not a terrain relocation appliance.

Sadly it is all too often the case that the number of words used in a business context is inversely proportional to the quantum of meaning that they convey. Perhaps it is time for professionals in all walks of life to take a lead from Humpty Dumpty and begin to better assert their mastery of vocabulary.
 

	Tweet this article on twitter.com

Bookmark this article with:
Technorati	| del.icio.us	| digg	| Reddit	| Stumble