Incremental Progress and Rock Climbing

4 May 201026 January 2022 Peter James Thomas business intelligence, change management, cultural transformation, project management bouldering, lead climbing, ovum, rock climbing

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

Boysen's Groove (V3/4) Dinas Mot, North Wales — 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:

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.
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!]
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

This is why they call lead climbing "the sharp end" — 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 it 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.

Business Sponsorship

8 April 20103 November 2014 Peter James Thomas it business alignment, project management Johann Sebastian Bach, mark anthony

Strong business sponsorship is generally cited as a major success factor for IT projects. From one perspective this is essentially a truism, but looking at the phrase from a different angle perhaps reveals something of interest – indeed perhaps it highlights a reason for some IT projects failing. Let’s look at a definition to start with:

sponsor /spónsər/ n. & v. • n. 2 a a person or organization that promotes or supports an artistic or sporting activity etc. (O.E.D.)

There are other definitions, but maybe surprisingly the one I show above is probably the closest to the meaning of “business sponsorship”. The very first entry in my Oxford English Dictionary for this word is one that brings back memories:

sponsor /spónsər/ n. & v. • n. 1 a person who supports an activity done for charity by pledging money in advance. (O.E.D.)

This takes me back to school (a long time ago) when every year we had a sponsored 20 mile (32 km) walk around the streets of London, each time for a different charity. In an age before such events became mainstream, I believe we held some record for the amount of money raised. It is surprising how many hills you can fit into 20 miles, even in London, and I can well remember how tired I was after doing this as an eleven-year-old.

A good place to go and ask for sponsorship money

I can also recall wandering from house-to-house in my neighbourhood, knocking on doors with my sponsorship form to ask for pledges. As a rather naive child I never really understood why some people were occasionally a little disgruntled to have me appear on their doorstep at 9am on a Sunday. Of course, post walk, I had to do the same rounds again to collect the money. I escapes me how much I raised, several hundred pounds I think, but I also remember some people raising a lot more than that.

Both of the above definitions have the connotation of a kindly benefactor indulging a pet cause, be that the arts, or a small schoolboy. There is also the sense that the sponsor is vicariously involved, no one is asking them to play a recital, or to walk 20 miles. Perhaps here we begin to detect the seed of a problem.

When I read IT people on various on-line forums speaking about ensuring business sponsorship, or gaining business buy in, I get the strong impression of an idea originated in IT which is seeking support. Some of the recent discussions on LinkedIn.com, which formed the basis for my earlier article: Who should be accountable for data quality? are a case in point. Several contributors have made comments along the lines of “IT needs to educate the business about the importance of data quality” – as well as being rather patronising, I think that this perspective on business life is rather wrong-headed.

In my mind it takes me back to an IT colleague (at which company I will not mention) saying “of course we [i.e. IT people] are so much smarter than them [i.e. non-IT people]”. To this day I am unsure whether he was joking or not. In my experience, IT people are just like non-IT people, some are smart, some are not, most are somewhere in between – I suspect the distribution is pretty similar in both cases.

Why have a dog and Bach yourself?

So when people talk about business sponsorship, maybe this is code for convincing the paymasters that some of IT’s ideas are worth spending money on. Maybe it is the same as a penniless 18^th century musician seeking the indulgence of a feudal monarch. IT may have all of the tunes, but he who pays the piper…

On the other hand, if IT and non-IT were well-aligned then maybe it would be more of a case of the business seeking IT sponsorship; i.e. of business folk originating ideas and IT working out how to implement them. Of course I tend to be an advocate of a partnership approach. I read recently on a LinkedIn.com thread about some IT departments being active and others passive. I would recommend IT being active, but not in the sense of pursuing its own agenda, or feeling (as perhaps my IT colleague did) that it knows best.

This was the noblest IT project of them all...

Maybe instead of seeking business sponsorship – which sounds rather like what you would do after IT had already figured out what to do and why – it would make sense to seek business engagement much earlier in the piece – this would hopefully lead to jointly crafted approaches that have business support baked-in from the outset. Surely this is preferable to the corporate equivalent of going door-to-door soliciting money, no matter how noble the cause might appear the the IT person who originated it.

Feasibility studies continued…

28 March 20103 November 2014 Peter James Thomas change management, cultural transformation, general, project management bouldering, feasibility study, injury, rock climbing, turn-around

These make a very disconcerting popping noise when you suffer them — A2 pulley injuries. Partial tear (left) and complete tear (right).
Images © Eric J. Horst, via http://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!

Running before you can walk

5 March 20103 November 2014 Peter James Thomas it business alignment, management, project management, technology bouldering, injury, rock climbing, turn-around

Prelude…

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.

Image and text care of The Institute of Orthopaedic Imaging, with my underlining.

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):

An example of crimping

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.

Old tendon injury to ring finger of right hand

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.

Tommy Caldwell - "high four"

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.

The main reason that teams under-perform - and the main route to addressing this

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.

“Why Business Intelligence projects fail”

4 June 200917 November 2014 Peter James Thomas business, business intelligence, it business alignment, project management, technology bi, information technology, it projects, success factors

Introduction

In this blog, I have generally tried to focus on success factors for Business Intelligence programmes. I suppose this reflects my general character as something of an optimist. Of course failure can also be instructive; as the saying goes “we learn more from our mistakes than from our successes.” Given this, and indeed the Internet’s obsession with “x reasons why y fails”, I have also written on the subject of how Business Intelligence projects can go wrong a few times.

My first foray into this area was in response to coverage of the Gartner Business Intelligence Summit in Washington D.C. by Intelligent Enterprise. The article was entitled, “Gartner sees a big discrepancy between BI expectations and realities” – Intelligent Enterprise; I have always had a way with words!

Rather than simply picking holes in other people’s ideas on this topic, I then penned a more general piece, Some reasons why IT projects fail, which did what it said on the can. Incidentally I was clearly in the middle of a purple patch with respect to article headlines back then, I am trying to recapture some of these former titular glories in this piece.

So what has moved me to put fingertip to keyboard this time? Well my inspiration (if it can be so described) was, as has often been the case recently, some comments made on a LinkedIn.com forum. In breech of my customary practice, I am not going to identify the group, the discussion thread or the author of these comments, which were from a seasoned BI professional and were as follows:

Most BI projects fail because:

a) the business didn’t support it properly or
b) the business didn’t actually know what they wanted

I realise that I should be more emotionally mature about such matters, but comments such as these are rather like a red rag to a bull for me. Having allowed a few days for my blood pressure to return to normal, I’ll try to offer a dispassionate deconstruction of these suggestions, which I believe are not just incorrect, but dangerously wrong-headed. If the attitude of a BI professional is accurately reflected by the above quote, then I think that we need look no further for why some BI projects fail. Let’s look at both assertions in a little more detail.

What does “the business didn’t properly support [BI]” actually mean?

For a change I am going to put my habitual frustration at unhelpful distinctions between “the business” and “IT” to one side (if you want to read about my thoughts on this matter, then please take a look at the Business / IT Alignment and IT Strategy section of my Keynote Articles page).

To me there are three possible explanations here:

The business did not need or want better information
The business needed or wanted better information, initially supported the concept of BI delivering this, but their enthusiasm for this approach waned over time
The business needed or wanted better information, but didn’t think that BI offered the way to deliver this

maybe there are some other possibilities, but hopefully the above covers all the bases. Here are some thoughts on each scenario:

1. The business did not need or want better information

So the rationale for starting a BI project was… ?

On a more serious note, there could be some valid reasons why a BI project would still make sense. First of all, it might be that a BI system could deliver the same information that is presently provided more cheaply. This could be the case where there are multiple different reporting systems, each needing IT care and support; where the technology that existing systems are based on is going out of support; or where BI is part of a general technology refresh or retrenchment (for example replacing fat client reporting tools with web-based ones, thereby enabling the retirement of multiple distributed servers and saving on the cost of people to maintain them). Of course it may well be IT that highlights the needs in these circumstances, but there should surely be a business case developed with some form or payback analysis or return on investment calculation. If these stand up, then an IT-centric BI project may be justifiable. While I would argue that such an approach is a wasted opportunity, if such an initiative is done properly (i.e. competently managed), then the the lack of business people driving the project should not be an obstacle to success.

Second, it could be that the business saw no need for better information, but IT (or possibly IT in conjunction with a numerate department such as Finance, Change or Strategy) does see one. While this observation is perhaps tinged with a little arrogance, one of IT’s roles should be to act as an educator, highlighting the potential benefits of technology and where they may add business advantage. Here my advice is not to start a BI project and hope that “if we build it, they will come”, but instead to engage with selected senior business people to explain what is possible and explore whether a technology such as BI can be of assistance. If this approach generates interest, then this can hopefully lead to enthusiasm with appropriate nurturing. Of course if the answer is still that the current information is perfectly adequate, then IT has no business trying to kick off a BI project by itself. If it does so, then accountability for its likely failure will be squarely (and fairly) laid at IT’s door.

2. The business needed or wanted better information, initially supported the concept of BI delivering this, but their enthusiasm for this approach waned over time

To me this sounds like a great opportunity that the BI team have failed to capitalise on. There is a pressing business need. There is a realisation that BI can meet this. Funding is allocated. A project is initiated. However, some where along the line, the BI team have lost their way.

Why would business enthusiasm wane? Most likely because delivery was delayed, no concrete results were seen for a long time, costs ballooned, the system didn’t live up to expectations, or something else happened that moved executive focus from this area. In the final case, then any responsible manager should be prepared to cut their coat according to their cloth. The BI team may feel that their project is all-important, but it is not inconceivable that another project would take precedence, for example integrating a merger.

Assuming that external events are not the reason for business disenchantment, then all of the other reasons are 100% the responsibility of the BI team themselves. BI projects are difficult to estimate accurately as I described in The importance of feasibility studies in business intelligence, but – as the same article explains – this is not an excuse for drastically inaccurate project plans or major cost overruns. Also the BI team should work hard at the beginning of the project to appropriately set expectations. As with any relationship, business or personal, the key to success is frequent and open communication.

Equally, BI projects often require a substantial amount of time to do well (anyone who tells you the opposite has never been involved with one or is trying to sell you something). This does not mean that the BI team should disappear for months (or years) on end. It is important to have a parallel stream of interim releases to address urgent business needs, provide evidence of progress and burnish the team’s credibility (I explore this area further in Holistic vs Incremental approaches to BI).

If the BI system delivered does not live up to expectations then there are two questions to be answered. In what way does it not meet expectations? and Why did it take until implementation to determine this? It could be that the functionality of the BI tool does not meet what is necessary, but most of these have a wide range of functionality and are at least reasonably intuitive to use. More likely the issue is in the information presented in the tool (which is not judged to be useful) or in an inadequate approach to implementation. The way to address both of these potential problems from the very start of the project is to follow the four-pillared approach that I recommend in many places on this blog; notably in one of the middle sections of Is outsourcing business intelligence a good idea?.

So rather than blaming the business for losing interest in BI, the BI team needs to consider where its own inadequacies have led to this problem. It is sometimes tempting to dwell on how no one really appreciates all of the hard work that us IT types do, but it is much more productive to try to figure out why this is and take steps to address the problem.

3.The business needed or wanted better information, but didn’t think that BI offered the way to deliver this

While I recognise some aspects of the first scenario above, this one is something that I am more intimately familiar with. Back in 2000, I was charged with improving the management information of a large organisation, in response to profitability issues that they were experiencing. No one mentioned data warehouses, or OLAP, or analytics. A business intelligence implementation was my response to the strategic business challenges that the organisation was facing. However I initially faced some scepticism. It was suggested that maybe I was over-engineering my approach (the phrase “we need a diesel submarine, not a nuclear one” being mentioned) when all that was required was a few tweaks to existing reports and writing some new ones.

First of all, a BI professional should welcome such challenges. Indeed they should continually ask the same questions of themselves and their team. If your proposed approach does not stand up to basic scrutiny with respect to cost effectiveness and timeliness, then you are doing a poor job. However good BI people will be able to answer such questions positively, having devised programmes and architectures that are appropriate for the challenges that they seek to meet. A BI solution should clearly not be more expensive than is needed, but equally it should not be cheaper, lest it fails to deliver anything.

A skill that is required in a situation such as the one I found myself in back in 2000 is to be able to lay out your vision and proposals in a way that is logical, compelling, attractive and succinct enough to engage business enthusiasm and engender the confidence of your potential stakeholders. In short you need to be able to sell. Maybe this is not a skill that all IT people have acquired over the years, but it is invaluable in establishing and maintaining project momentum (I cover the latter aspect of this area in three articles starting with Marketing Change).

Again, if the lead of the BI team is not able to properly explain why BI is the best way to meet the information needs of the organisation, then this is essentially the fault of the BI lead and not the business.

So far, the main conclusion that I have drawn is the same as in my earlier piece about the failure of BI projects. I closed this by stating:

I firmly believe that BI done well is both the easiest of IT systems to sell to people and has one of the highest paybacks of any IT initiative. BI done badly (at the design, development, implementation or follow-up stages) will fail.

The issue is basically a simple one: just how good is your BI team? If a BI implementation fails to deliver significant business value, then instead of looking for scape-goats, the BI team should purchase a mirror and start using it.

Let’s see if an exploration of the second suggested reason for problems with BI projects changes my stance at all.

What does “the business didn’t know what they wanted [from BI]” actually mean?

What do I need

Business intelligence, when implemented correctly, helps organisations to be more successful by offering a way to understand the dynamics of their operations and markets and facilitating better business decisions. So, almost by definition, good BI has to be a sort of model of the key things that happen in an company. This is not easy to achieve.

Again I will come back to my four-pillared approach and emphasise the first pillar. There is an imperative to:

Form a deep understanding of the key business questions that need to be answered.

In my opinion, it is the difficulty in managing this process that plays into the assertion that “the business didn’t know what they wanted.” Putting it another way, the BI team were not skilful enough, engaging enough, or business-savvy enough to help the business to articulate what they wanted and to translate this into a formal set of definitions that could then form the basis of IT work. This process can indeed lengthy, tough and difficult to get right because:

Businesses are often complex, with many moving parts and many things that need to be measured
Different business people may have different visions of what is important – each of these may have validity, depending on context
Both IT and business people may be unaccustomed to talking about business phenomena in the required way (one that is self-consistent and exhaustive)
IT may not have a proper understanding of business strategy, business terminology and business transactions
There is often a desire to start with the current state and adapt / add to this, rather than take the more arduous (but more profitable) approach of working out what is necessary and desireable
The process is typically iterative and requires an ongoing commitment to the details, sapping reserves of perseverance

I have written about the level of commitment that can be required in defining BI business requirements in a couple of articles: Scaling-up Performance Management and Developing an international BI strategy. Please take a look at these if you are interested in delving further into this area. For now it is enough to state that you should probably allow a number of months for this work in your BI project plan; more if your objective is to deliver an all-pervasive BI system (as it was in the work I describe in the articles). It is also helpful to realise that you are never “done” with requirements in BI, they will evolve based on actual use of the system and changing business needs. You will end up living this cycle, so it makes sense to get good at it.

Sometimes it may be tempting for either IT or the business people involved to short-cut the process, or to give up on it entirely. This is s sure recipe for disaster. It is difficult to make establishing requirements a fun exercise for all those involved, but it is important the the BI team continually tries to keep energy levels high. This can be done in a number of ways: by reminding everyone about the importance of their work for the organisation as a whole; by trying to use prototypes to make discussions more concrete; and – probably most importantly – by building and maintaining personal relationships with their business counterparts. If you are going to work for a long time with people on something that is hard to do, then it makes sense to at least try to get along. It is on apparently small things such as these essentially human interactions that the success or failure of multi-million dollar projects can hinge.

Helping the business to articulate what they want from BI is extremely important and equally easy to get wrong. Mistakes made at this stage can indeed derail the whole project. However, this is precisely what the BI team should be good at; it should be their core competency. If this work is not done well, then again it is primarily the responsibility of the professionals involved. A statement such as “the business didn’t know what they wanted” simply reflects that the BI team were not very good at running this phase of a BI project.

Conclusion

The case against the BI team

I find myself back at my previous position. Of course the idea of finding scape-goats for the failure of a BI project can be very tempting for the members of the team that has failed. However, this is an essentially futile process and one that proves that the adage about learning from your mistakes does not always apply.

To make things personal. Suppose that I am responsible for leading project in which it is obvious up-front that extensive buy-in and collaboration will be required from a group of people. If the project fails because neither of these things was obtained, then surely that’s my fault and not theirs, isn’t it?

For some further thoughts on this issue, take a look at an article by Ferenc Mantfeld entitled: Top 10 reasons why Business Intelligence Projects fail.

Bogorad on the basics of Change Management – TechRepublic

29 May 20093 November 2014 Peter James Thomas business intelligence, change management, cultural transformation, project management bi, business intelligence, business projects, change management, cultural transformation, Ilya Bogorad, information technology, it projects, maureen clarry, neil raden, techrepublic

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:

Do change for a good reason
Set clear goals
Establish responsibilities
Use the right leverage
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.

Other TechRepublic-related articles on this site inlcude: “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic and Ilya Bogorad on Talking Business.

Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya specializes in building better IT organizations and can be reached at ibogorad@bizvortex.com or (905) 278 4753. Follow him on Twitter at twitter.com/bizvortex.

“Big vs. Small BI” by Ann All at IT Business Edge

19 May 20093 November 2014 Peter James Thomas business, business intelligence, industry commentary, it business alignment, management, management information, project management, technology alex ferguson, ann all, bi, business intelligence, dorothy miller, football, information technology, it business alignment, it business edge, john colbert, management information, manchester united, michael corcoran, nigel Pendse, premier league, success factors

Introduction

Back in February, Dorothy Miller wrote a piece at IT Business Edge entitled, Measuring the Return on Investment for Business Intelligence. I wrote a comment on this, which I subsequently expanded to create my article, Measuring the benefits of Business Intelligence.

This particular wheel has now come full circle with Ann All from the same web site recently interviewing me and several BI industry leaders about our thoughts on the best ways to generate returns from business intelligence projects. This new article is called, Big vs. Small BI: Which Set of Returns Is Right for Your Company? In it Ann weaves together an interesting range of (sometimes divergent) opinions about which BI model is most likely to lead to success. I would recommend you read her work.

The other people that Ann quotes are:

•	John Colbert	Vice president of research and analytics for consulting company BPM Partners.
•	Dorothy Miller	Founder of consulting company BI Metrics (and author of the article I mention above).
•	Michael Corcoran	Chief marketing officer for Information Builders, a provider of BI solutions.
•	Nigel Pendse	Industry analyst and author of the annual BI Survey.

Some differences of opinion

As might be deduced from the title of Ann’s piece the opinions of the different interviewees were not 100% harmonious with each other. There was however a degree of alignment between a few people. As Ann says:

Corcoran, Colbert and Thomas believe pervasive use of BI yields the greatest benefits.

On this topic she quoted me as follows (I have slightly rearranged the text in order to shorten the quote):

If BI can trace all the way from the beginning of a sales process to how much money it made the company, and do it in a way that focuses on questions that matter at the different decision points, that’s where I’ve seen it be most effective.

By way of contrast Pendse favours:

smaller and more tactical BI projects, largely due to what his surveys show are a short life for BI applications at many companies. “The median age of all of the apps we looked at is less than 2.5 years. For one reason or another, within five years the typical BI app is no longer in use. The problem’s gone away, or people are unhappy with the vendor, or the users changed their minds, or you got acquired and the new owner wants you to do something different,” he says. “It’s not like an ERP system, where you really would expect to use it for many years. The whole idea here is go for quick, simple wins and quick payback. If you’re lucky, it’ll last for a long time. If you’re not lucky, at least you’ve got your payback.”

I’m sure that Nigel’s observations are accurate and his statistics impeccable. However I wonder whether what he is doing here is lumping bad BI projects with good ones. For a BI project a lifetime of 2.5 years seems extraordinarily short, given the time and effort that needs to be devoted to delivering good BI. For some projects the useful lifetime must be shorter than the development period!

Of course it may be that Nigel’s survey does not discriminate between tiny, tactical BI initiatives, failed larger ones and successful enterprise BI implementations. If this is the case, then I would not surprised if the first two categories drag down the median. Though you do occasionally hear horror stories of bad BI projects running for multiple years, consuming millions of dollars and not delivering, most bad BI projects will be killed off fairly soon. Equally, presumably tactical BI projects are intended to have a short lifetime. If both of these types of projects are included in Pendse’s calculations, then maybe the the 2.5 years statistic is more understandable. However, if my assumptions about the survey are indeed correct, then I think that this figure is rather misleading and I would hesitate to draw any major conclusions from it.

In order that I am not accused of hidden bias, I should state unequivocally that I am a strong proponent of Enterprise BI (or all-pervasive BI, call it what you will), indeed I have won an award for an Enterprise BI implementation. I should also stress that I have been responsible for developing BI tools that have been in continuous use (and continuously adding value) for in excess of six years. My opinions on Enterprise BI are firmly based in my experiences of successfully implementing it and seeing the value generated.

With that bit of disclosure out of the way, let’s return to the basis of Nigel’s recommendations by way of a sporting analogy (I have developed quite a taste for these, having recently penned artciles relating both rock climbing and mountain biking to themes in business, technology and change).

A case study

Manchester United versus Liverpool

The [English] Premier League is the world’s most watched Association Football (Soccer) league and the most lucrative, attracting the top players from all over the globe. It has become evident in recent seasons that the demands for club success have become greater than ever. The owners of clubs (be those rich individuals or shareholders of publicly quoted companies) have accordingly become far less tolerant of failure by those primarily charged with bringing about such success; the club managers. This observation was supported by a recent study^[1] that found that the average tenure of a dismissed Premier League manager had declined from a historical average of over 3 years to 1.38 years in 2008.

As an aside, the demands for business intelligence to deliver have undeniably increased in recent years; maybe BI managers are not quite paid the same as Football managers, but some of the pressures are the same. Both Football managers and BI managers need to weave together a cohesive unit from disparate parts (the Football manager creating a team from players with different skills, the BI manager creating a system from different data sources). So given, these parallels, I suggest that my analogy is not unreasonable.

Returning to the remarkable statistic of the average tenure of a departing Premier League manger being only 1.38 years and applying Pendse’s logic we reach an interesting conclusion. Football clubs should be striving to have their managers in place for less than twelve months as they can then be booted out before they are obsolete. If this seems totally counter-intutitive, then maybe we could look at things the other way round. Maybe unsuccessful Football managers don’t last long and maybe neither do unsuccessful BI projects. By way of corollary, maybe there are a lot of unsuccessful BI projects out there – something that I would not dispute.

By way of an example that perhaps bears out this second way of thinking about things, the longest serving Premier League manager, Alex Ferguson of Manchester United, is also the most successful. Manchester United have just won their third successive Premier League and have a realistic chance of becoming the first team ever to retain the UEFA Champions League.

Similarly, I submit that the median age of successful BI projects is most likely significantly more than 2.5 years.

Final thoughts

I am not a slavish adherent to an inflexible credo of big BI; for me what counts is what works. Tactical BI initiatives can be very beneficial in their own right, as well as being indispensible to the successful conduct of larger BI projects; something that I refer to in my earlier article, Tactical Meandering. However, as explained in the same article, it is my firm belief that tactical BI works best when it is part of a strategic framework.

In closing, there may be some very valid reasons why a quick and tactical approach to BI is a good idea in some circumstances. Nevertheless, even if we accept that the median useful lifetime of a BI system is only 2.5 years, I do not believe that this is grounds for focusing on the tactical to the exclusion of the strategic. In my opinion, a balanced tactical / strategic approach that can be adapted to changing circumstances is more likely to yield sustained benefits than Nigel Pendse’s tactical recipe for BI success.

Nigel Pendse and I also found ourselves on different sides of a BI debate in: Short-term “Trouble for Big Business Intelligence Vendors” may lead to longer-term advantage.

^[1] Dr Susan Bridgewater of Warwick Business School quoted in The Independent 2008

Using multiple business intelligence tools in an implementation – Part I

16 May 200917 November 2014 Peter James Thomas business, business analytics, business intelligence, change management, cognos, cultural transformation, dashboards, data warehousing, ibm, industry commentary, it business alignment, management information, project management, technology bi, business analytics, business intelligence, information technology, it business alignment, it management, it projects, it strategy, management information


		The Data Warehousing Institute (TDWI™) 2.0

Introduction

This post follows on from a question that was asked on the LinkedIn.com Data Warehousing Institute (TDWI™) 2.0 group. Unfortunately the original thread is no longer available for whatever reason, but the gist of the question was whether anyone had experience with using a number of BI tools to cover different functions within an implementation. So the scenario might be: Tool A for dashboards, Tool B for OLAP, Tool C for Analytics, Tool D for formatted reports and even Tool E for visualisation.

In my initial response I admitted that I had not faced precisely this situation, but that I had worked with the set-up shown in the following diagram, which I felt was not that dissimilar:

An example of a multi-tier BI architecture with different tools

Here there is no analytics tool (in the statistical modelling sense – Excel played that role) and no true visualisation (unless you count graphs in PowerPlay that is), but each of dashboards, OLAP cubes, formatted reports and simple list reports are present. The reason that this arrangement might not at first sight appear pertinent to the question asked on LinkedIn.com is that two of the layers (and three of the report technologies) are from one vendor; Cognos at the time, IBM-Cognos now. The reason that I felt that there was some relevance was that the Cognos products were from different major releases. The dashboard tool being from their Version 8 architecture and the OLAP cubes and formatted reports from their Version 7 architecture.

A little history

Maybe a note of explanation is necessary as clearly we did not plan to have this slight mismatch of technologies. We initially built out our BI infrastructure without a dashboard layer. Partly this was because dashboards weren’t as much of a hot topic for CEOs when we started. However, I also think it also makes sense to overlay dashboards on an established information architecture (something I cover in my earlier article, “All that glisters is not gold” – some thoughts on dashboards, which is also pertinent to these discussions).

When we started to think about adding icing to our BI cake, ReportStudio in Cognos 8 had just come out and we thought that it made sense to look at this; both to deliver dashboards and to assess its potential future role in our BI implementation. At that point, the initial Cognos 8 version of Analysis Studio wasn’t an attractive upgrade path for existing PowerPlay users and so we wanted to stay on PowerPlay 7.3 for a while longer.

The other thing that I should mention is that we had integrated an in-house developed web-based reporting tool with PowerPlay as the drill down tool. The reasons for this were a) we had already trained 750 users in this tool and it seemed sensible to leverage it and b) employing it meant that we didn’t have to buy an additional Cognos 7 product, such as Impromptu, to support this need. This hopefully explains the mild heterogeneity of our set up. I should probably also say that users could directly access any one of the BI tools to get at information and that they could navigate between them as shown by the arrows in the diagram.

I am sure that things have improved immensely in the Cognos toolset since back then, but at the time there was no truly seamless integration between ReportStudio and PowerPlay as they were on different architectures. This meant that we had to code the passing of parameters between the ReportStudio dashboard and PowerPlay cubes ourselves. Although there were some similarities between the two products, there were also some differences at the time and these, plus the custom integration we had to develop, meant that you could also view the two Cognos products as essentially separate tools. Add in here the additional custom integration of our in-house reporting application with PowerPlay and maybe you can begin to see why I felt that there were some similarities between our implementation and one using different vendors for each tool.

I am going to speak a bit about the benefits and disadvantages of having a single vendor approach later, but for now an obvious question is “did our set-up work?” The answer to this was a resounding yes. Though the IT work behind the scenes was maybe not the most elegant (though everything was eminently supportable), from the users’ perspective things were effectively seamless. To slightly pre-empt a later point, I think that the user experience is what really matters, more than what happens on the IT side of the house. Nevertheless let’s move on from some specifics to some general comments.

The advantages of a single vendor approach to BI

I think that it makes sense if I lay my cards on the table up-front. I am a paid up member of the BI standardisation club. I think that you only release the true potential of BI when you take a broad based approach and bring as many areas as you can into your warehouse (see my earlier article, Holistic vs Incremental approaches to BI, for my reasons for believing this).

Within the warehouse itself there should be a standardised approach to dimensions (business entities and the hierarchies they are built into should be the same everywhere – I’m sure this will please all my MDM friends out there) and to measures (what is the point if profitability is defined different ways in different reports?). It is almost clichéd nowadays to speak about “the single version of the truth”, but I have always been a proponent of this approach.

I also think that you should have the minimum number of BI tools. Here however the minimum is not necessarily always one. To misquote one of Württemberg’s most famous sons:

Everything should be made as simple as possible, but no simpler.

What he actually said was:

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

but maybe the common rendition is itself paying tribute to the principle that he propounded. Let me pause to cover what are the main reasons quoted for adopting a single vendor approach in BI:

Consistent look-and-feel: The tools will have a common look-and-feel, making it easier for people to use them and simplifying training.
Better interoperability: Interoperability between the tools is out-of-the-box, saving on time and effort in developing and maintaining integration.
Clarity in problem resolution: If something goes wrong with your implementation, you don’t get different vendors blaming each other for the problem.
Simpler upgrades: You future proof your architecture, when one element has a new release, it is the vendor’s job to ensure it works with everything else, not yours.
Less people needed: You don’t need to hire an expert for each different vendor tool, thereby reducing the size and cost of your BI team.
Cheaper licensing: It should be cheaper to buy a bundled solution from one vendor and ongoing maintenance fees should also be less.

This all seems to make perfect sense and each of the above points can be seen to be reducing the complexity and cost of your BI solution. Surely it is a no-brainer to adopt this approach? Well maybe. Let me offer some alternative perspectives on each item – none of these wholly negates the point, but I think it is nevertheless worth considering a different perspective before deciding what is best for your organisation.

Consistent look-and-feel: It is not always 100% true that different tools from the same vendor have the same look-and-feel. This might be down to quality control at the vendor, it might be because the vendor has recently acquired part of their product set and not fully integrated it as yet, or – even more basically – it may be because different tools are intended to do different things. To pick one example from outside of BI that has frustrated me endlessly over the years: PowerPoint and Word seem to have very little in common, even in Office 2007. Hopefully different tools from the same vendor will be able to share the same metadata, but this is not always the case. Some research is probably required here before assuming this point is true. Also, picking up on the Bauhaus ethos of form dictating function, you probably don’t want to have your dashboard looking exactly like your OLAP cubes – it wouldn’t be a dashboard then would it? Additional user training will generally be required for each tier in your BI architecture and a single-vendor approach will at best reduce this somewhat.
Better interoperability: I mention an problem with interoperability of the Cognos toolset above. This is is hopefully now a historical oddity, but I would be amazed if similar issues do not arise at least from time to time with most BI vendors. Cognos itself has now been acquired by IBM and I am sure everyone in the new organisation is doing a fine job of consolidating the product lines, but it would be incredible if there were not some mismatches that occur in the process. Even without acquisitions it is likely that elements of a vendor’s product set get slightly out of alignment from time to time.
Clarity in problem resolution: This is hopefully a valid point, however it probably won’t stop your BI tool vendor from suggesting that it is your web-server software, or network topology, or database version that is causing the issue. Call me cynical if you wish, I prefer to think of myself as a seasoned IT professional!
Simpler upgrades: Again this is also most likely to be a plus point, but problems can occur when only parts of a product set have upgrades. Also you may need to upgrade Tool A to the latest version to address a bug or to deliver desired functionality, but have equally valid reasons for keeping Tool B at the previous release. This can cause problems in a single supplier scenario precisely because the elements are likely to be more tightly coupled with each other, something that you may have a chance of being insulated against if you use tools from different vendors.
Less people needed: While there might be half a point here, I think that this is mostly fallacious. The skills required to build an easy-to-use and impactful dashboard are not the same as building OLAP cubes. It may be that you have flexible and creative people who can do both (I have been thus blessed myself in the past in projects I ran), but this type of person would most likely be equally adept whatever tool they were using. Again there may be some efficiencies in sharing metadata, but it is important not to over-state these. You may well still need a dashboard person and an OLAP person, if you don’t then the person who can do both with probably not care about which vendor provides the tools.
Cheaper licensing: Let’s think about this. How many vendors give you Tool B free when you purchase Tool A? Not many is the answer in my experience, they are commercial entities after all. It may be more economical to purchase bundles of products from a vendor, but also having more than one in the game may be an even better way of ensuring that cost are kept down. This is another area that requires further close examination before deciding what to do.

A more important consideration

Overall it is still likely that a single-vendor solution is cheaper than a multi-vendor one, but I hope that I have raised enough points to make you think that this is not guaranteed. Also the cost differential may not be as substantial as might be thought initially. You should certainly explore both approaches and figure out what works best for you. However there is another overriding point to consider here, the one I alluded to earlier; your users. The most important thing is that your users have the best experience and that whatever tools you employ are the ones that will deliver this. If you can do this while sticking to a single vendor then great. However if your users will be better served by different tools in different tiers, then this should be your approach, regardless of whether it makes things a bit more complicated for your team.

Of course there may be some additional costs associated with such an approach, but I doubt that this issue is insuperable. One comparison that it may help to keep in mind is that the per user cost of many BI tools is similar to desktop productivity tools such as Office. The main expense of BI programmes is not the tools that you use to deliver information, but all the work that goes on behind the scenes to ensure that it is the right information, at the right time and with the appropriate degree of accuracy. The big chunks of BI project costs are located in the four pillars that I consistently refer to:

Understand the important business decisions and what figures are necessary to support these.
Understand the data available in the organisation, how it relates to other data and to business decisions.
Transform the data to provide information answering business questions.
Focus on embedding the use of information in the corporate DNA.

The cost of the BI tools themselves are only a minor part of the above (see also, BI implementations are like icebergs). Of course any savings made on tools may make funds available for other parts of the project. It is however important not to cut your nose off to spite your face here. Picking right tools for the job, be they from one vendor or two (or even three at a push) will be much more important to the overall payback of your project than saving a few nickels and dimes by sticking to a one-vendor strategy just for the sake of it.

Continue reading about this area in: Using multiple business intelligence tools in an implementation – Part II

Automating the business intelligence process?

14 May 20093 November 2014 Peter James Thomas balanced insight, business, business intelligence, it business alignment, management information, project management, technology bi, business intelligence, information technology, it business alignment, Market Strategies for IT Suppliers, merv adrian, success factors



Balanced Insight	Merv Adrian

Introduction

I enjoy reading the thoughts of vastly experienced industry analyst Merv Adrian on his blog, Market Strategies for IT Suppliers, and also on twitter via @merv. Merv covers industry trends and a wide variety of emerging and established technologies and companies. I would encourage you to subscribe to his RSS feed.

In a recent artcile, Balanced Insight – Automating BI Design to Deployment, Merv reviews the Consensus tool and approach developed by Ohio-based outfit Balanced Insight. I suggest that you read Merv’s thoughts first as I won’t unnecessarily repeat a lot of what he says here. His article also has links to a couple of presentations featuring the use of Consensus to build both Cognos 8 and Proclarity prototypes, which are interesting viewing.

An overview of Balanced Insight

Disclaimer:

I haven’t been the beneficiary of a briefing from Balanced Insight, and so my thoughts are based solely on watching their demos, some information from their site and – of course – Merv’s helpful article.

The company certainly sets expectations high with the strap line of their web site:

Agile & Aligned Business Intelligence - With Balanced Insight Consensus® deliver in half the time without compromising cross project alignment.

Promising to “deliver in half the time without compromising cross project alignment” is a major claim and something that I will try to pay close attention to later.

The presentations / demonstrations start with a set-up of a fictional company (different ones in different demos) who want to find out more about issues in their business: outstanding receivables, or profit margins [Disclosure: the fact that the second demo included margins on mountain bikes initially endeared me to the company]. In considering these challenges, Balanced Insight offers the following slide contrasting IT’s typical response with the, presumably superior, one taken by them:

IT's approach to information problems vs Balanced Insight's

I agree with Balanced Insight’s recommendation, but rather take issue with the assumption that IT always starts by looking exclusively at data when asked to partake in information-based initiatives. I have outlined what I see as the four main pillars of a business intelligence project at many places on this blog, most recently in the middle of my piece on Business Intelligence Competency Centres. While of course it is imperative to understand the available data (what would be the alternative?), the first step in any BI project is to understand the business issues and, in particular, the questions that the business wants an answer to. If you search the web for BI case studies or methodologies, I can’t imagine many of these suggesting anything other than Balanced Insight’s recommended approach.

Moving on, the next stage of both the demos introduces the company’s “information packages”. These are panes holding business entities and have two parts; the upper half contains “Topics and Categories” (things such as date or product), the bottom half contains measurements. The “Topics and Categories” can be organised into hierarchies, for example: day is within week, which is within month, quarter and year. At this point most BI professionals will realise that “Topics and Categories” are what we all call “Dimensions” – but maybe Balanced Insight have a point picking a less technical-sounding name. So what the “information package” consists of is a list of measures and dimensions pertaining to a particular subject area – it is essentially a loose specification for a data mart.

The interesting point is what happens next, the Consensus Integrator uses the “information package” to generate what the vendor claims is an optimised star-schema database (in a variety of databases). It then creates a pre-built prototype that references the schema; this can be in a selection of different BI tools. From what I can tell from the demos, the second stage appears to consist of creating an XML file that is then read by the BI tool. In the first example, the “Topics and Categories” become dimensions in Cognos AnalysisStudio and the measures remain measures. In both demos sample data is initially used, but in the ProClarity one a version with full data is also shown – it is unclear whether this was populated via Consensus or not. The “information package” can also be exported to data modelling tools such as ERwin.

One of the Balanced Insight presentations then mentions that “all that’s left to do is then to develop your ETL”. I appreciate that it is difficult to go into everything in detail in a short presentation, but this does rather seem to be glossing over a major area, indeed one of my four pillars of BI projects referred to above. Such rather off-hand comments do not exactly engender confidence. If there is a better story to tell here, then Balanced Insight’s presentations should try to tell it.

The main themes

There are a few ideas operating here. First that Balanced Insight’s tools can support a process which will promote best practice in defining and documenting the requirements of a BI project and allow a strong degree of user interaction. Second that the same tools can quickly and easily produce functioning prototypes that can be used to refine these same requirements and also make discussions with business stakeholders more concrete. Finally that the prototypes can employ a variety of database and BI tools – so maybe you prototype on a cheap / free database and BI tool, then implement on a more expensive, and industrial strength, combination later.

Balanced Insight suggest that their product helps to address “the communication gap between IT and the business”. I think it is interesting using the “information package” as a document repository, which may be helpful at other stages of the project. But there are other ways of achieving this as well. How business friendly these are probably depends on how the BI team set them up. I have seen Excel and small Access databases work well without even buying a specific tool. Also I think that if a BI team needs a tool to ensure it sticks to a good process, then there is probably a bigger problem to worry about.

Of course, the production of regular prototypes is a key technique to employ in any BI project and it seems that Balanced Insight may be on to something here, particularly if the way that their “information package” presents subject areas makes it easier for the BI team and business people to discuss things. However, it is not that arduous to develop prototypes directly in most BI tools. To put this in a context drawn from my own experience, building Cognos cubes to illustrate the latest iteration of business requirement gathering was often a matter of minutes, compared to business analysts putting in many days of hard work before this stage.

Having decided to use Consensus to capture information about measures and dimensions, the ability to then transfer these to a range of BI tools in interesting. This may offer the opportunity to change tools during the initial stages of the project and to try out different tools with the same schema and data to assess their effectiveness. This may also be something that is a useful tool when negotiating with BI vendors. However, again I am not sure exactly how big of a deal this is. I would be interested in better understanding how users have taken advantage of this feature.

A potential fly in the ointment

It would be easy to offer a couple of other criticisms of the approach laid out in the demos; namely that it seems to be targeted at developing point solutions rather than a pervasive BI architecture and that (presumably related to this) the examples shown are very basic. However, I’m willing to given them the benefit of the doubt, a sales pitch is probably not the place for a lengthy exploration of broad and complex issues. So I think my overall response to Balanced Insight’s Consensus product could be summed up as guardedly positive.

Nevertheless, there is one thing that rather worries me and this can best be seen by looking at the picture below. [As per the disclaimer above, the following diagram is based on my own understanding of the product and has not been provided by Balanced Insight.]

My perception of how Balanced Insight addresses needs for information

I think I understand the single black arrow on the right of the diagram, I’m struggling to work out what Consensus offers (aside from documentation) for the two black arrows on the left hand side. Despite the fact that Balanced Insight disparaged the approach of looking at available data in their presentation, there is no escaping the fact that some one will have to do this at some point. Connections will then have to be made between the available data and the business questions that need answering.

In both demos Consensus is pre-populated with dimensions, measures and linkages of these to sample data. How this happens is not covered, but this is a key area for any BI project. Unless Balanced Insight have some deus ex machina that helps to cut the length of this stage, then I begin to become a little sceptical about their claim to halve the duration of BI work.

Of course my concerns could be unfounded. It will be interesting to see how things develop for the company and whether their bold claims stand the test of time.

Business Intelligence Competency Centres

11 May 20093 November 2014 Peter James Thomas business, business intelligence, business intelligence competency centres, change management, cultural transformation, international projects, management, management information, project management, technology bi, BICC, business intelligence competency centre, it projects, it strategy, success factors

Introduction

The subject of this article ought to be reasonably evident from its title. However there is perhaps some room for misinterpretation around even this. Despite the recent furore about definitions, most reasonable people should be comfortable with a definition of business intelligence. My take on this is that BI is simply using information to drive better business decisions. In this definition, the active verb “drive” and the subject “business decisions” are the key elements; something that is often forgotten in a rush for technological fripperies.

The central issue

Having hopefully addressed of the “BI” piece of the BICC acronym, let’s focus on the “CC” part. I’ll do this in reverse order, first of all considering what is meant by “centre”. As ever I will first refer to my trusted Oxford English Dictionary for help. In a discipline, such as IT, which is often accused of mangling language and even occasionally using it to obscure more than to clarify, a back-to-basics approach to words can sometimes yield unexpected insights.

centre / séntər / n. & v. (US center) 3 a a place or group of buildings forming a central point in a district, city, etc., or a main area for an activity (shopping centre, town centre).
(O.E.D.)

Ignoring the rather inexcusable use of the derived adjective “central” in the definition of the noun “centre”, then it is probably the “main area for an activity” sense that is meant to be conveyed in the final “C” of BICC. However, there is also perhaps some illumination to be had in considering another meaning of the word:

Centre of a Sphere

n. 1 a the middle point, esp. of a line, circle or sphere, equidistant from the ends, or from any point on the circumference or surface.
(O.E.D.)

As well as appealing to the mathematician in me, this meaning gives the sense that a BICC is physically central geographically, or metaphorically central with respect to business units. Of course this doesn’t meant than a BICC needs to be at the precise centre of gravity of an organisation, with each branch contributing a “weight” calculated by its number of staff, or revenue; but it does suggest that the competency centre is located at a specific point, not dispersed through the organisation.

Of course, not all organisations have multiple locations. The simplest may not have multiple business units either. However, there is a sense by which “centre” means that a BICC should straddle whatever diversity there is an organisation. If it is in multiple countries, then the BICC will be located in one of these, but serve the needs of the others. If a company has several different divisions, or business units, or product streams; then again the BICC should be a discrete area that supports all of them. Often what will make most sense is for the BICC to be located within an organisation’s Head Office function. There are a number of reasons for this:

Head Office similarly straddles geographies and business units and so is presumably located in a place that makes sense to do this from (maybe in an organisation’s major market, certainly close to a transport hub if the organisation is multinational, and so on).
If a BICC is to properly fulfil the first two letters of its abbreviation, then it will help if it is collocated with business decision-makers. Head Office is one place than many of these are found, including generally the CEO, the CFO, the Head of Marketing and Business Unit Managers. Of course key decision makers will also be spread throughout the organisation (think of Regional and Country Managers), but it is not possible to physically collocate with all of these.
Another key manager who is hopefully located in Head Office is the CIO (though this is dispiritingly not always the case, with some CIOs confined to IT ghettos, far from the rest of the executive team and with a corresponding level of influence). Whilst business issues are pre-eminent in BI, of course there is a major technological dimension and a need to collaborate closely with those charged with running the organisation’s IT infrastructure and those responsible for care and feeding of source data systems.
If a BI system is to truly achieve its potential, then it must become all pervasive; including a wide range of information from profitability, to sales, to human resources statistics, to expense numbers. This means that it needs to sit at the centre of a web of different systems: ERP, CRM, line of business systems, HR systems etc. Often the most convenient place to do this from will be Head Office.

Thusfar, I haven’t commented on the business benefits of a BICC. Instead I have confined myself to explaining what people mean by the second “C” in the name and why this might be convenient. Rather than making this an even longer piece, I am going to cover both the benefits and disadvantages of a BICC in a follow-on article. Instead let’s now move on to considering the first “C”: Competency.

Compos centris

Returning to our initial theme of generating insights via an examination of the meaning of words in a non-IT context, let’s start with another dictionary definition:

Motar board

	competence /kómpit’nss/ n. (also competency /kómpitənsi/) 1 (often foll. by for, or to + infin.) ability; the state of being competent.

and given the recursive reliance of the above on the definition of competent…

	competent /kómpit’nt/ adj. 1 a (usu. foll. by to + infin.) properly qualified or skilled (not competent to drive); adequately capable, satisfactory. b effective (a competent bastman*). (O.E.D.)

* People who are not fully conversant with the mysteries of cricket may substitute “batter” here.

To me the important thing to highlight here is that, while it is to be hoped that a BICC will continue to become more competent once it is up and running, in order to successfully establish such a centre, a high degree of existing competence is a prerequisite. It is not enough to simply designate some floor space and allocate a number of people to your BICC, what you need is at least a core of seasoned professionals who have experience of delivering transformational information and know how to set about doing it.

There are many skills that will be necessary in such a group. These match the four main pillars of a BI implementation (I cover these in more depth in several places on the blog, including BI implementations are like icebergs and the middle section of Is outsourcing business intelligence a good idea?):

Understand the important business decisions and what figures are necessary to support these.
Understand the data available in the organisation, how it relates to other data and to business decisions.
Transform the data to provide information answering business questions.
Focus on embedding the use of information in the corporate DNA.

So a successful BICC must include: people with strong analytical skills and an understanding of general business practices; high-calibre designers; reliable and conscientious ETL and general programmers; experts in the care, feeding and design of databases; excellent quality assurance professionals; resource conversant with both whatever front-end tools you are using to deliver information and general web programming; staff with skills in technical project management; people who can both design and deliver training programmes; help desk personnel; and last, but by no means least, change managers.

Of course if your BI project is big enough, then you may be able to afford to have people dedicated to each of these roles. If resources are tighter (and where is this not the case nowadays?) then it is better to have people who can wear more than one hat: business analysts who can also design; BI programmers who will also take support calls; project managers who will also run training classes; and so on. This approach saves money and also helps to deal with the inevitable peaks and troughs of resource requirements at different stages in a project. I would recommend setting things up this way (or looking to stretch your people’s abilities into new areas) even if you have the luxury of a budget that would allow a more discrete approach. The challenge of course is going to be finding and retaining such multi-faceted staff.

Also, it hopefully goes without saying that BI is a very business-focussed area and some BICCs will explicitly include business people in them. Even if you do not go this far, then the BICC will have to form a strong partnership with key business stakeholders, often spread across multiple territories. The skill to manage this effectively is in itself a major requirement of the leading personnel of the centre.

Given all of the above, the best way to staff a BICC is with members of a team who have already been successful with a BI project within your organisation; maybe one that was confined to a given geographic region or business unit. If you have no such team, then starting with a BICC is probably a bridge too far. Instead my recommendation would be to build up some competency via a smaller BI project. Alternatively, if you have more than one successful BI team (and, despite the manifold difficulties in getting BI right, such things are not entirely unheard of) then maybe blending these together makes sense. This is unless there is some overriding reason not to (e.g. vastly different team cultures or methodologies. In this case, picking a “winner” may be a better course of action.

Such a team will already have the skills outlined above in abundance (else they could never have been successful). It is also likely that whatever information was needed in their region or business unit will be at least part of what is needed at the broader level of a BICC. Given that there are many examples of BI projects not delivering or consuming vastly more resource than anticipated, then leveraging those exceptional people who have managed to swim against this tide is eminently sensible. Such battle-hardened professionals will know what pitfalls to avoid, which areas are most important to concentrate on and can use their existing products to advertise the benefits of a wider system. If you have such people at the core of your BICC, then it will be easier to integrate new joiners and quickly shepherd them up the learning curve (something that can be particularly long in BI due to the many different aspects of the work).

Of course having been successful in one business unit or region is not enough to guarantee success on a larger scale. I spoke about some of the challenges of doing this in an earlier article, Developing an international BI strategy. Another issue that is likely to raise its head is the political dimension, in particular where different business units or regions already have a management information strategy at some stage of development. This is another area that I will also cover in more detail in a forthcoming piece.

Conclusions

It seems that simply musing on the normal meanings of the words “competency” and “centre” has led us into some useful discussions. As mentioned above, at least two other blog postings will expand upon areas that have been highlighted in this piece. For now what I believe we have learned so far is:

BICCs should (by definition) straddle multiple geographies and/or business units.
There are sound reasons for collocating the BICC with Head Office.
There is need for a wide range of skills in your BICC, both business-focussed and technical.
At least the core of your BICC should be made up of competent (and experienced) BI professionals .

More thoughts on the benefits and disadvantages of business intelligence competency centres and also the politcs that they have to negotiate will appear on this blog in future weeks.

	Welcome to: peterjamesthomas.com, a site which covers my thoughts on the confluence of business, technology and change.
+44 (0) 2088 956 826
	[Web-site Contact]
	[Commercial Contact]
	[Creative Commons]
	[Report Problems]

Peter James Thomas

Data & Analytics: Consultancy, Interim Services and Research

project management

Incremental Progress and Rock Climbing

Like this:

Business Sponsorship

Like this:

Feasibility studies continued…

Like this:

Running before you can walk

Like this:

“Why Business Intelligence projects fail”

Like this:

Bogorad on the basics of Change Management – TechRepublic

Like this:

“Big vs. Small BI” by Ann All at IT Business Edge

Like this:

Using multiple business intelligence tools in an implementation – Part I

Like this:

Automating the business intelligence process?

Like this:

Business Intelligence Competency Centres

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: