Business Intelligence Competency Centres

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.

The scope of IT’s responsibility when businesses go bad

27 Apr 20093 Nov 2014 Peter James Thomas bi and the economic crisis, business, business analytics, business intelligence, change management, cultural transformation, it business alignment, technology bi, business analytics, business intelligence, credit crunch, economic crisis, information technology, it business alignment, it strategy, jim anderson, management information


		Chief Information Officer (CIO) Network

This article is another relating to a discussion on LinkedIn.com. As with my earlier piece, Short-term “Trouble for Big Business Intelligence Vendors” may lead to longer-term advantage, this was posted on the Chief Information Officer (CIO) Network group

The thread was initiated by Patrick Gray and was entitled: Is IT partially to blame for the financial crisis? (as ever you need to be a member of LinkedIn.com and the group to view this).

Business Failure

Patrick asked:

Information is one of the key components of any IT organization (I would personally argue it’s more important than the technology aspect). Two facts disturb me when one looks at IT’s role in the financial crisis:

1) We in IT have been pushing data warehouse and business intelligence technology for years, saying these technologies should allow for “proactive” decision making at all levels of an organization, and an ability to spot trends and changes in a business’ underlying financial health.

2) The finance industry is usually spends more on IT than any other industry.

This being the case, if BI actually does what we’ve pitched it to do, shouldn’t one of these fancy analytical tools spotted the underlying roots of the financial crisis in at least one major bank? Is IT partially culpable for either not looking at the right data, or selling a bill of goods in terms of the “intelligence” aspect of BI?

I have written elsewhere on LinkedIn.com about business intelligence’s role in the financial crisis. My general take is that if the people who were committing organisations to collateralised debt obligations and other even more esoteric assent-backed securities were unable (or unwilling) to understand precisely the nature of the exposure that they were taking on, then how could this be reflected in BI systems. Good BI systems reflect business realities and risk is one of those realities. However if risk is as ill-understood as it appears to have been in many financial organisations, then it is difficult to see how BI (or indeed it’s sister area of business analytics) could have shed light where the layers of cobwebs were so dense.

So far, so orthodox, but Patrick’s question got me thinking along a different line, one that is more closely related to the ideas that I propounded in Business is from Mars and IT is from Venus last year. I started wondering, ‘is it just too easy for IT to say, “the business people did not understand the risks, so how were we expected to?”?’ (I think I have that punctuation right, but would welcome corrections from any experts reading this). This rather amorphous feeling was given some substance when I read some of the other responses.

However, I don’t want to focus too much on any one comment. My approach will be instead to take a more personal angle and describe some of the thoughts that the comments provoked in me (I am using “provoked” here in a positive sense, maybe “inspired” would have been a better choice of word). If you want to read my comments with the full context, then please click on the link above. What I am going to do here is to present some excerpts from each of my two lengthier contributions. The first of these is as follows (please note that I have also corrected a couple of typos and grammatical infelicities):

Rather than being defensive, and as a BI professional I would probably have every right to be so, I think that Patrick has at least half a point. If some organisations had avoided problems (or mitigated their impact) through the use of good BI (note the adjective) in the current climate, then BI people (me included) would rush to say how much we had contributed. I have certainly done this when the BI systems that I have implemented helped an organisation to swing from record losses to record profits.

Well if we are happy to do this, then we have to take some responsibility when things don’t go so well. It worries me when IT people say that non-IT managers are accountable for the business and IT is just accountable for IT. Surely in a well-functioning organisation, IT is one department that shares responsibility for business success with all the other front-line and service departments.

I have seen it argued with respect to failed financial institutions that IT can only provide information and that other executives take decisions. Well if this is the case, then I question how well the information has been designed to meet business needs and to drive decisions. To me this is evidence of bad BI (note the adjective again).

There are some specific mitigating factors for IT within the current climate, including poor internal (non-IT) governance and the fact that even the people who were writing some financial instruments did not understand the potential liabilities that the we taking on. If this is the case, then how can such risk be rolled up meaningfully? However these factors do not fully exculpate IT in my opinion. I am not suggesting for a second that IT take prime responsibility, but to claim no responsibility whatsoever is invidious.

So yes either poor information, or a lack of information (both of which are IT’s fault – as well as that of non-IT business folk) are a contributory factors to the current problems.

Also, while IT managers see themselves as responsible only for some collateral department, semi-detached from the rest of the business, we will see poor IT and poor information continuing to contribute to business failure.

This is the second passage:

[…]

I just wonder how it is that IT people at such firms can say that any failures are 100% nothing to do with them, as opposed to say 1% responsibility, or something of that nature.

Part of the role of professionals working in BI is to change the organisation so that numerical decision making (backed up of course by many other things, including experience and judgement) becomes part of the DNA. We are to blame for this not being the case in many organisations and can’t simply throw our hands up and say “wasn’t me”.

[…]

I will freely admit that there was a large dose of Devil’s Advocate in my two responses. As I have stated at the beginning of this piece, I am not so masochistic to believe that IT caused the current financial crisis, however I do not think that IT can be fully absolved of all blame.

My concerns about IT’s role relate to the situation that I see in some companies where IT is a department set apart, rather than being a central part of the overall business. In this type of circumstance (which is perhaps more common than anyone would like to think), the success of the IT and the non-IT parts of the business are decoupled.

Under these arrangements, it would be feasible for IT to be successful and the business to suffer major losses, or for the business to post record profits while IT fails to deliver projects. Of couse such decoupling can happen in other areas; for example Product A could have a stellar year, while Product B fails miserably – the same could happen with countries or regions. However there is something else here, a sense that IT can sometimes be an organisation within an organisation, in a way that other service departments generally are not.

Rather than expanding further on this concept here, I recommend you read Jim Anderson’s excellent article Here’s What’s Really Wrong With IT And How To Fix It on his blog, The Business of IT. I think that there is a good deal of alignment between Jim and I on this issue; indeed I was very encouraged to find his blog and see that his views were not a million miles from my own.

I would also like to thank Patrick for posting his initial question. It’s good when on-line forums lead you to take an alternative perspective on things.

Continue reading about this area in: Two pictures paint a thousand words… and “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic.

Also check out Jill Dyché’s article: Dear IT: A Letter from Your Business Users

Recipes for success?

17 Apr 20093 Nov 2014 Peter James Thomas Biology, business, change management, management, project management, technology business strategy, change management, creativity, darwin, evolution, information technology, it projects, methodology, natural selection, success factors

I should acknowledge that I am indebted to a conversation that I had with John Collins on his blog, Views from the Bridge, for some of the themes I discuss in this article.

Introduction

Towards the end of a recent article on perseverance I referred to people’s desire to find recipes for success. Here’s what I said:

Sometimes we want to find a magic recipe for success, or – to mix the metaphor – a silver bullet. We want to discover a series of defined steps to take that, if repeated religiously, will guarantee that we get to the desired goal each and every time. That’s why articles entitled “The 5 ways to […]” and “My top tips for […]” are so well-read on the web.

As well as my examples of internet top tips (see any number of articles claiming to tell you how to use twitter successfully to get the idea), this phenomenon is also a major factor behind the enduring popularity of celebrity business books. As far as I can see, these fall into two categories.

1. The Ex-CEO

This is where the extremely successful and well-known Mr Brown (and sadly it is still mostly Mr, rather than Ms Brown), now retired but previously President and CEO of Big Company Inc., writes (or more likely has some one ghost-write) a memoir explaining the secrets of his success. While the book may dwell on their upbringing, education, role models, or character-forming events in their lives, much of the work will probably focus on them just being much smarter, more risk-taking, or having greater insight than the competition (most likely all of these). Of course there may well be some interesting tit-bits amongst the reams of self-aggrandisement, but it is worth questioning just how applicable these might be to your own situation.

Are the things that Mr Brown ascribes his success to really what led to his glittering career? Are there perhaps other factors that are not captured in the memoir, but which, if absent in another organisation, would render implementing Mr Brown’s explicit recommendations valueless? Did Mr Brown’s greatest achievements actually have a big slice of luck attached to them (stumbling upon a market or a product by accident, a major competitor losing their way, events beyond anyone’s control shaping matters and so on)? Would the things that Big Company Inc. did under Mr Brown’s esteemed leadership actually work in another company, in a different market or country and with a distinctive business culture?

Put it this way, if you work in Financial Services, would copying what worked in Retail be a good idea? Alternatively, if two companies are both in Retail, does it make sense for a less successful company to slavishly adopt the strategy of the market leader – wouldn’t it be more sensible if they tried to develop a different strategy in order to differentiate their brand?

Of course there is always value in learning from the mistakes and successes of others, but surely there is a limit to how useful a business memoir can be in forming a business strategy.

2. The Academic Expert

Here Professor Green (probably still male), has a long and distinguished career in academia, reading and deconstructing the memoirs of Mr Brown and his peers, identifying common themes between them, doing primary research and constructing recherché models of business strategy development and execution. If there is a new management fad out there, Professor Green is sure to know about it – in fact it may well be based on an article of his that appeared in HBR.

Well there is certainly some value in trying to tease out commonalities between successful companies, but this is probably a lot harder than it might seem. While there may be some recurring themes, maybe many of our champions of business are one offs, successful for reasons other than their business models or strategies. In fact they may well be as unique as the people who lead them. Maybe there is no equivalent of the standard model of quantum mechanics (to say nothing of a deeper grand unified theory) that underpins business success – perhaps the science of business is different from the more reductionist sciences, such as physics. Maybe there isn’t a formula for business success; perhaps it is more like Darwinian natural selection (I’ll come back to this idea later).

Whichever way you look at it, again there is probably a limit to how much insight you can glean from this type of book.

Other genres

Of course this phenomenon extends into many other areas of human activity. As a youth I can remember only too well poring over cricket manuals in an (ultimately fruitless) attempt to improve my batting or wicket-keeping. My father, at the age of 72, still does the same with golf manuals.

The endless array of cooking books also in the same category and where would we be without the panoply of self-help books such as The Seven Habits of Annoyingly Organised People? All of which goes to show that reliance on recipes for success is a deeply ingrained human trait.

Recipes for success in IT

Having established that people like turning to both “My top tips for […]” and “Mr Brown’s Glittering Career” (available at all good booksellers) how does this aspect of human nature impinge on one of my main areas of endeavour, IT?

Well it has a major impact in my opinion. In fact it is difficult to think of an area of life more obsessed with frameworks, blue-prints, road-maps, procedures, best practices and methodologies (to say nothing of ontologies and taxonomies). All of these are intended to take the risk out of activities – well at least to provide the people following them with the ability to say “well I did what the methodology told me to do”. Of course IT projects and IT development are very complex things and standards of design, coding and behaviour of systems are of paramount importance; but it still seems that IT people have a more visceral relationship with the above-stated areas than would be dictated solely by ticking the necessary boxes.

Nevertheless, having been personally responsible for instigating a thoroughgoing process of standardisation and quality control in a software house (and thereby obtaining an ISO accreditation), it would be churlish of me to argue that that there is no benefit in rigorously applying methodologies in IT.

When it comes to some aspects of project management and to change management in particular, some of the scepticism that I exhibited about celebrity business books returns. It’s not so much that a methodology or even a list of items to tick is not valuable, but that it cannot be an end in itself. The important thing is the thinking that goes into drawing up what you need to do and how you are going to do it, not the method that you use to record these and monitor progress. Sometimes these crucial ingredients get lost. Indeed there does seem to be an entire class of people who focus just on managing lists, rather than the ideas behind them, or the people actually doing the work.

The benefits of a Darwinian approach

Charles Darwin

I raised the idea of a Darwinian approach to business strategy earlier in this article. There do seem to be some crossovers with how we observe businesses in operation. We are familiar with the image of companies competing with each other for limited resources (our wallets, mine being very limited at present). We understand the pressure that organisations are under to come up with better, cheaper, more functional and sexier products (that are now carbon neutral and ethically-sourced as well).

The language of business is suffused by jungle analogies. The adaptation of Tennyson’s “Nature, red in tooth and claw” to capitalism being just one of the most well-known examples. The companies that are best at this game survive and thrive, those that are not fail and are forgotten. Companies in more mature markets are even often referred to as dinosaurs or fossils. The idea of never-ending refinement and progress pushing on is an essential part of business.

However, perhaps this evolutionary approach, so evident at the macro-level can also work on a micro-scale. Maybe, rather than relying on the thoughts of Mr Brown or Professor Green, a better approach would be come up with some ideas of our own, test them, discard the bad ones and nurture the less bad ones. In time, with appropriate development and alteration, the less bad may become good and then even great (hang on, I seem to have found my way back to business books with that phrase!).

To me, such an approach is more likely to result in something novel and valuable. Following a recipe for success can only ever be as good as the recipe itself. Thinking for yourself can transcend these limitations and I would argue that the downside is no greater than attempting to ape someone else’s ideas. In both cases the worst that can happen is only extinction.

Disclaimer – sort of

Of course this article has a degree of self reference. Relying upon your own intellect (hopefully refined and improved by other people’s input) is of course another recipe for success. However I hope it is a less proscriptive one. I recommend giving it a try.

Continue reading about this area in: Synthesis.

The Dictatorship of the Analysts

14 Apr 20093 Nov 2014 Peter James Thomas business, business analytics, business intelligence, change management, management information, sas, SAS BI / BA controversy, technology bi, business analytics, business intelligence, change management, cio magazine, cio.com, information technology, SAS BI / BA controversy

Lest it be thought that I am wholly obsessed by the Business Intelligence vs Business Analytics issue (and to be honest I have a whole lot of other ideas for articles that I would rather be working on), I should point out that this piece is not focussed on SAS. In my last correspondence with that organisation (which was in public and may be viewed here) I agreed with Gaurav Verma’s suggestion that SAS customers be left to make up their own minds about the issue.

However the ripples continue to spread from the rock that Jim Davis threw into the Business Intelligence pond. The latest mini-tsunami is in an article on CIO.com by Scott Staples, President and Co-CEO of IT Services at MindTree. [Incidentally, I’d love to tell you more about MindTree’s expertise in the area of Business Intelligence, but unfortunately I can’t get their web-site’s menu to work in either Chrome or IE8; I hope that you have better luck.]

Scott’s full article is entitled Analytics: Unlocking Value in Business Intelligence (BI) Initiatives. In this, amongst other claims, Scott states the following:

To turn data into information, companies need a three-step process:

Data Warehouse (DW)—companies need a place for data to reside and rules on how the data should be structured.

Business Intelligence—companies need a way to slice and dice the data and generate reports.
Analytics—companies need to extract the data, analyze trends, uncover opportunities, find new customer segments, and so forth.

Most companies fail to add the third step to their DW and BI initiatives and hence fall short on converting data into information.

He goes on to say:

[…] instead of companies just talking about their DW and BI strategies, they must now accept analytics as a core component of business intelligence. This change in mindset will solve the dilemma of data ≠ information:

Current Mindset: DW + BI = Data

Future Mindset: DW + (BI + Analytics) = Information

Now in many ways I agree with a lot of what Scott says, it is indeed mostly common sense. My quibble comes with his definitions of BI and Analytics above. To summarise, he essentially says “BI is about slicing and dicing data and generating reports” and “Analytics is about extracting data, analysing trends, uncovering opportunities and finding new customer segments”. To me Scott has really just described two aspects of exactly the same thing, namely Business Intelligence. What is slicing and dicing for if not to achieve the aims ascribed above to Analytics?

Let me again – and for the sake of this argument only – accept the assertion that Analytics is wholly separate from BI (rather than a subset). As I have stated before this is not entirely in accordance with my own views, but I am not religious about this issue of definition and can happily live with other people’s take on it. I suppose that one way of thinking about this separation is to call the bits of BI that are not Analytics by the older name of OLAP (possibly ignoring what the ‘A’ stands for, but I digress). However, even proponents of the essential separateness of BI and Analytics tend to adopt different definitions to Scott.

To me what differentiates Analytics from other parts of BI is statistics. Applying advanced (or indeed relatively simple) statistical methods to structured, reliable data (such as one would hope to find in data warehouses more often than not) would clearly be the province of Analytics. Thus seeking to find attributes of customers (e.g. how reliably they pay their bills, or what areas they live in) or events in their relationships with an organisation (e.g. whether a customer service problem arose and how it was dealt with) that are correlated with retention/repeat business would be Analytics.

Maybe discerning deeply hidden trends in data would also fall into this camp, but what about the rather simpler “analysing trends” that Scott ascribes to Analytics? Well isn’t that just another type of slice and dice that he firmly puts in the BI camp?

Trend analysis in a multidimensional environment is simply using time as one of the dimensions that you are slicing and dicing your measures by. If you want to extrapolate from data, albeit in a visual (and possibly non-rigorous manner) to estimate future figures, then often a simple graph will suffice (something that virtually all BI tools will provide). If you want to remove the impact of outlying values in order to establish a simple correlation, then most BI tools will let you filter, or apply bands (for example excluding large events that would otherwise skew results and mask underlying trends).

Of course it is maybe a little more difficult to do something like eliminating seasonality from figures in these tools, but then this is pretty straightforward to do in Excel if it is an occasional need (and most BI tools support one-click downloading to Excel). If such adjustments are a more regular requirement, then seasonally adjusted measures can be created in the Data Mart with little difficulty. Then pretty standard BI facilities can be used to do some basic analysis.

Of course paid-up statisticians may be crying foul at such loose analysis, of course correlation does not imply causation, but here we are talking about generally rather simple measures such as sales, not the life expectancy of a population, or the GDP of a country. We are also talking about trends that most business people will already have a good feeling for, not phenomena requiring the application of stochastic time series to model them.

So, unlike Scott, I would place “back-of-an-envelop” and graphical-based analysis of figures very firmly in the BI camp. To me proper Analytics is more about applying rigorous statistical methods to data in order to either generate hypotheses, or validate them. It tends to be the province of specialists, whereas BI (under the definition that I am currently using where it is synonymous with OLAP) is carried out profitably by a wider range of business managers.

So is an absence of Analytics – now using my statistically-based definition – a major problem in “converting data into information” as Scott claims? I would answer with a very firm “no”. If we take information as being that which is generated and consumed by a wide range of managers in an organisation, then if this is wrong then the problem is much earlier on and most likely centred on how the data warehousing and BI parts have been implemented (or indeed in a failure to manage the concomitant behavioural change). I covered what I believe are often the reasons that BI projects fail to live up to their promise in my response to a Gartner report. This earlier article may be viewed here.

In fact I think that what happens is that when broader BI projects fail in an organisation, people fall back on two things: a) their own data (Excel and Access) and b) the information developed by the same statistical experts who are the logical users of Analytic tools. The latter is characterised by a reliance on Finance, or Marketing reports produced by highly numerate people with Accounting qualifications or MBAs, but which are often unconnected to business manager’s day-to-day experiences. The phrase “democratisation of information” has been used in relation to BI. Where BI fails, or does not exist, then the situation I have just described is maybe instead the dictatorship of the analysts.

I have chosen the word “dictatorship” with all of its negative connotations advisedly. I do not think that the situations that I have described above is a great position for a company to be in. The solution is not more Analytics, which simply entrenches the position of the experts to the detriment of the wider business community, but getting the more mass-market disciplines of the BI (again as defined above) and data warehousing pieces right and then focussing on managing the related organisational change. In the world of business information, as in the broader context, more democracy is indeed the antidote to dictatorship.

I have penned some of my ideas about how to give your BI projects the greatest chance of success in many places on this blog. But for those interested, I suggest maybe starting with: Scaling-up Performance Management, “All that glisters is not gold” – some thoughts on dashboards, The confluence of BI and change management and indeed the other blog articles (both here and elsewhere) that these three pieces link to.

Also for those with less time available, and although the article is obviously focussed on a specific issue, the first few sections of Is outsourcing business intelligence a good idea? pull together many of these themes and may be a useful place to start.

If your organisation is serious about adding value via the better use of information, my recommendation is to think hard about these areas rather than leaping into Analytics just because it is the latest IT plat du jour.

Perseverance

31 Mar 20093 Nov 2014 Peter James Thomas business, business intelligence, change management, cultural transformation, project management, technology bouldering, information technology, rock climbing, success factors

This blog is generally focused on topics in business, technology and change; often all three at the same time. However, from time to time, a personal post leaks in. This is one such post… or is it? Read to the end and then I will leave you to make up your own mind about this question.

Introduction

Over the years I have played many sports. For example, both cricket and rugby union consumed much of my youth. I have also recently got into mountain biking and really enjoy it. However, the activity that I am most engaged in currently is rock climbing, something that I alluded to at the beginning of a blog post yesterday. Rock climbing forms a very broad church and I have taken part in many aspects of it. However, for a number of reasons, I have gravitated to the sub-genre of bouldering over the last few years.

For the uninitiated, bouldering is climbing un-roped, often on actual boulders, but also on small outcrops and generally going no more than 5-6m (15-20 ft) off the ground. You carry around crash-pads (bouldering mats) with you to hopefully take the brunt of any falls. Indeed the idea with bouldering is to fall… to try again… and to fall again. In fact maybe Beckett had bouldering in mind when he wrote:

Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

The whole point is that, because bouldering is relatively (and I stress the word relatively) safe, you can try to make moves that are at the limit of your ability; moves that would not be terribly sensible to even contemplate making on a longer, higher, roped climb. In fact bouldering climbs are so difficult that they are generally described as “problems”; an apt name that also conveys the fact that sometimes you have to use extreme subtlety and finesse as well as brute strength to get up them.

People often literally spend years attempting to complete a problem, particularly if it represents a new level of climbing for them, or if no one else has climbed the line before. Because of this, such unclimbed lines are often called projects. It’s common to ask a fellow climber about how their current project is progressing. This choice of name perhaps begins to give some indication of why I am sharing my experiences in bouldering with you today.

Having said that most boulder problems are short, some hardy souls also embrace high-ball bouldering which, as the name suggests, takes you a lot further off the ground. The following video shows one of the world’s best climbers, Chris Sharma, bouldering in Bishop, California. It segues to him and another top climber, Ethan Pringle, attempting a high-ball problem that weighs in at around 11-12m (35-40 ft).

Note 1: Ethan issues an expletive under his breath towards the end of the clip. I might well have been tempted to do so myself in similar circumstances, but count yourselves warned.

Note 2: As will be apparent if you try to click on this video, it is sadly no longer available, probably to do with copyright issues. Instead I would recommend that you take a look at the bouldering section of Dead Point Magazine’s site.

Copyright notice. This piece is taken from the DVD King Lines which features Chris Sharma climbing all over the world. The copyright holder is BigUp Productions, a world-renowned and award-winning producer of climbing DVDs.

So what does this have to do with the price of fish?

Please substitute “the price of eggs” if you are in the US

Green Wall Essential (V2). The Buttermilks, Bishop, CA

I have recently taken to showing the above photograph at the mid-point of my public speaking about business intelligence and change management. Generally I have introduced it with the comment that I wanted to relieve the audience’s boredom by showing them some of my holiday snaps.

As in the above video, this climb is also in Bishop, California, a world-class bouldering venue. The problem is called Green Wall Essential and its grade of difficulty is V2. Without going into enormous detail about the different grading systems for boulder problems, I’ll simply say that V2 is towards the easier end of the spectrum; V15/16 is the hardest that people have climbed.

The reason that I share this image with business/technology audiences is related to the number of times that I tried (and failed) to climb it. Here are some statistics:

More than 80 attempts
On 4 different days
During 2 separate visits to Bishop
Spread over 8 months

I mentioned the term project above; Green Wall Essential became my project and my obsession. The above statistics represent more effort than I have ever put into climbing anything else. The quartz monzonite rock is hard and crystalline. It digs into your fingers and peels off your skin leaving the rock stained with your blood (you can see the tape holding the tips of my fingers together in the photograph). Your muscles and tendons ache from trying to push yourself just that little bit harder in order to attain success. You endlessly try different foot holds and body positions. You try to be slow and precise. When that doesn’t work you try to be aggressive and dynamic. When that doesn’t work… and so on and so on.

Now in order to put in that much effort over that much time, and to put up with that much pain and that much failure, you have to really want to do the problem. You have to be persistent, despite set backs. You have to continue to keep a positive mind-set, to believe that you can be successful, even when you have just failed for the 80th time.

In my experience, that is precisely the same mind-set that you need to be successful with major projects, particularly in the business of change management. Hopefully your fingers will bleed less, but it will not be easy. There will be set-backs. Progress may sometimes seem glacially slow, but if you persevere then the goal is worth it.

Sometimes we want to find a magic recipe for success, or – to mix the metaphor – a silver bullet. We want to discover a series of defined steps to take that, if repeated religiously, will guarantee that we get to the desired goal each and every time. That’s why articles entitled “The 5 ways to […]” and “My top tips for […]” are so well-read on the web. My take is that the secret ingredient may be very simple: plain, pig-headed perseverance.

By way of illustrating the benefits of this approach (and closing this article), here I am having achieved my own personal goal on Green Wall Essential… EVENTUALLY!!!

Me a very happy boulderer having completed my project.

I wish you luck with your own projects, be these in business intelligence, other areas of IT, change management, or even bouldering. My own “Top tip” – if at first you don’t succeed, persevere.

If I have whetted anyone’s appetite about bouldering, you can take a look at my partner’s bouldering blog, which contains bouldering photos and videos, together with her musings on what motivates her to climb.

Some thoughts on IT-Business Alignment from the Chase Zander IT Director Forum

27 Mar 20093 Nov 2014 Peter James Thomas business, change management, it business alignment, technology business projects, business strategy, change management, chase zander, information technology, it business alignment, it director forum, it management, it projects, it strategy, success factors, transparency

This Chase Zander seminar, which I earlier previewed on this site, took place yesterday evening in Birmingham. There was a full house of 20 plus IT Directors, CIOs and other senior IT managers who all engaged fully in some very stimulating and lively discussions.

As I previously mentioned, our intention in this meeting was to encourage debate and sharing of experiences and best practice between the delegates. My role was to faciliate the first session, focussed on IT-Business alignment. I started by sharing a few slides with that group that explained the research we had conducted to determine the content of the forum.

Click to view the introductory presentation as a PDF

After sharing what in my opinion was a not wholly satisfactory definition of IT-Business alignment, I opened up the floor to a discussion of what IT-Business alignment actually was and why it mattered. We used some of the other slides later in the meeting, but most of the rest of the evening was devoted to interaction between the delegates. Indeed the ensuing conversations were so wide ranging that the theme was also carried over to the second session, hosted by my associate Elliot Limb.

Territory initially covered included the suggestion that IT should be an integral part of the business, rather than a separate entity aligned to it (a theme that I covered in my earlier article Business is from Mars and IT is from Venus, which interestingly I penned after a previous Chase Zander forum, this one focussed on change management). The group also made a strong connection between IT-Business alignment and trust. A count of hands in response to the question “do you feel that you have the 100% unqualified confidence of your CEO?” revealed a mixed response and we tried to learn from the experiences of those who responded positively.

The relationship between IT and change was also debated. Some felt that IT, with its experience of project-based work, was ideally placed to drive change in organisations. Others believed that change should be a business function, with IT sticking to its more traditional role. Different organisations were in different places with respect to this issue – one attendee had indeed seen his current organisation take both approaches in the recent past. It was also agreed that there were different types of change: positive change in reaction to some threat or opportunity and the less positive change for change’s sake that can sometimes affect organisations.

Suggestions for enhancing IT-Business alignment included: being very transparent about IT service level agreements and trends in them; focussing more on relationships with senior managers, the CEO and CFO in particular; better calculating the cost of IT activities (including business resource) and using this to prioritise and even directly charge for IT services; applying marketing techniques to IT; learning to better manage business expectations, taking on more realistic workloads and knowing when to say ‘no’; and paying more attention to business processes, particularly via capability maturity modelling.

It was agreed that it generally took quite some time to establish trust between a CIO and the rest of the senior management team. This might be done by initially sorting out problems on the delivery and support side and, only once confidence had been built up, would the CIO be able to focus more on strategic and high value-added activities. This process was not always aided by the not atypical 3-5 year tenure of CIOs.

Later discussions also touched on whether CIOs would generally expect (or want to) become CEOs and, if not, why was this the case. The perspective of both the delegates and the Chase Zander staff was very interesting on this point. There was a degree of consensus formed around the statement that IT people liked taking on challenging problems, sorting them out and then moving on to the next one. While there was some overlap between this perspective and the role of a CEO in both having their hand on the tiller of an organisation and challenging the management team to meet stretch goals, there was less than a perfect fit. Maybe this factor indicated something of a different mindset in many IT professionals.

In the context of forming better relationships with business managers and IT trying to be less transactional in its dealings with other areas, the question of why there were so few women in senior IT positions also came up. This is a large topic that could spawn an entire forum in its own right.

Overall the meeting was judged to be a success. From my perspective it was also interesting to meet a good cross-section of IT professionals working in different industries and to talk about both what the different challenges that we faced and what we had in common.

Continue reading about this area in: The scope of IT’s responsibility when businesses go bad

The Top Business Issues facing CIOs / IT Directors – Results

17 Mar 20093 Nov 2014 Peter James Thomas business, business intelligence, change management, cultural transformation, it business alignment, technology business intelligence, change director forum, change management, chase zander, cultural transformation, information technology, it business alignment, it management, it strategy, management information

Back in January, in collaboration with Chase Zander, I started a process of consulting with senior IT managers to develop a list of the top business issues that they faced. This exercise was intended to shape the content of a IT Director Forum that we were planning. This will now be happening on 26th March in Birmingham (for further information see this post).

Questionaire Responses — The Top Business Issues faced by CIOs / IT Directors

Back then, I promised to share some of the findings from this study. These are summarised in the above diagram. The input was based on public comments made by a selection of senior people on the CIO group of LinkedIn.com, plus e-mails sent to me on the topic and feedback received by Chase Zander.

A textual version of the data appeas below (sample size ~60):

	Issue	% of Votes

	IT / Business Alignment	27%
	Cost-saving	13%
	Managing change	8%
	Status of the IT Director	8%
	Legacy Systems	5%
	Customer focus	5%
	Enterprise Architecture	5%
	Business Intelligence	5%
	Avoiding the latest and greatest	3%
	Cloud Computing	3%
	Only one response	17%

	Total	100%

I would like to thank all of the IT professionals who contributed to this survey.

Some reasons why IT projects fail

12 Mar 20093 Nov 2014 Peter James Thomas business, change management, it business alignment, project management, technology business projects, business strategy, change management, information technology, it business alignment, it management, it projects, it strategy

© Alex Messenger - http://www.alexmessenger.co.uk/

Having yesterday been somewhat disparaging about the efforts of others to delineate the reasons for BI projects failing, I realised that I had recently put together just such a list myself. By way of context, this was in response to being asked for some feedback in a subject area where I had little expertise and experience. Instead of bailing out of answering, I put together a more general response, a lightly edited and mildly expanded version of which appears below.

Please note that there is no claim on my part that this list is exhaustive; in common with all humans, us IT types can be very creative in finding new ways to fail, I am sure there are some out there that I have not come across yet.

The objectives of the project not being clear. By this I mean the business objectives. There are two layers of problems, the actual business issues may not be understood well enough to form an effective response and, if the business knows what it needs to do in general terms, IT may not fully appreciate this for a number of reasons (mostly down to lack of communication) or may be unable to translate this into a suitable programme of work (possibly because of a lack of knowledge of how the business operates). Where IT is not part of the senior management team, or sees itself as a department apart, this issue is more likely to occur.
Strategy formation being skipped. If you don’t understand what a project is meant to be about, it is difficult (to say the least) to form a strategy. However, if the test in point 1. is passed, then it may be tempting (or there may be pressure applied) to get to the end game as soon as possible without either forming a strategy for the project, or fitting this into both over-arching business and IT strategies (which one fervently hopes are complementary). As I know all too well, the strategy formation step can be tough one and people may sometimes be keen to skip it. The current economic climate may lead to this happening more frequently and my opinion is that this will be storing up trouble for the future.
Fragmented systems’ landscapes. Related to the above, it is often very difficult to make progress when there is a patchwork of different systems and approaches throughout an organisation and little desire to address this short-coming. Often some sort of revolution (albeit sometimes a quiet one sustained over many years) is required to move forward. Sometimes this requires some crisis, internal or external, as virtually every organisation is inherently conservative; no matter what their marketing spiel may claim to the contrary.
Lack of Change Management. Projects often also have an organisational change aspect (what else are they for?) and the problems here are: a) people do not like change and resist it; and b) many otherwise able managers are not experienced in change – indeed we tend to educate most managers to be efficient in a steady-state environment. Even when this aspect is recognised, it is often underestimated and work does not start until too late in the game.
People. Aside from these, the main other problem is people. Projects, even small ones, are difficult and not everyone is up to running them. Simple errors in execution can derail projects that otherwise tick all of the boxes.

Of course any passing Gartner analyst is more than welcome to rip this to shreds if they see fit.

“Gartner sees a big discrepancy between BI expectations and realities” – Intelligent Enterprise

11 Mar 20093 Nov 2014 Peter James Thomas business, business intelligence, change management, education, it business alignment, management information, project management, technology bi, business intelligence, business projects, business strategy, change management, cultural transformation, Doug Henschen, education, gartner, information technology, intelligent enterprise, it business alignment, it projects, management information

Doug Henschen at Intelligent Enterprise reports from the Gartner Business Intelligence Summit in Washington D.C., explaining that Gartner analysts John Van Decker and Kurt Schlegel cited five reasons why BI projects do not live up to expectations (article link here):

No IT-Business Partnership – “We have to get away from thinking of it as a vendor-customer relationship,” said Schlegel.
No Link to Corporate Strategy – BI team have to listen to the executives and develop metrics and measures that are aligned with their goals.
No connection to the Process – “BI has been overtly disconnected for too long,” Schlegel proclaimed. It’s not enough to deliver the right information to the right users. You have to insert those insights into the processes and interfaces that business users live in every day.”
No Governance or Too Much – It has to be just the right amount of governance. BI grew up departmentally, so it’s all too common to have many silos of BI. At the other extreme, some companies are so uptight about data standards that companies can’t get their data into the warehouse.
No Skills – Business users often lack skills, chimed in Van Decker, citing the one area where the business side was said to be falling short. “Most companies have very sophisticated capabilities available that folks just aren’t taking advantage of,” he said, pointing to corporate performance management (CPM) software as a leading example.

I come close to the situation of words failing me when I read a list like this (though not close enough to prevent me penning an article of course). I appreciate that maybe a public seminar is not the easiest place to provide deep insights (I present a lot myself), but the commentary against each of the problem areas seems odd to me. I’m not sure that these are really the five reasons for BI continuing to disappoint in some organisations, while it continues to delight in others, but here are my thoughts on each headline.

No IT-Business Partnership – We have to stop talking about IT and Business as if they were two parties trying to negotiate a cease-fire. IT is a business department, it carries out business projects. It would be ridiculous to say that there needs to be a Sales-Business Partnership, it should be equally so with IT. I expand on this theme in the very first article on this blog.
No Link to Corporate Strategy – There should not be a link to Corporate Strategy, BI does not exist as a separate entity that requires linkage. Instead BI work should be an expression of Corporate Strategy (as should any IT project), what else is it an expression of? This is not about listening to executives (though that is important) it is about IT being part of the senior management team of an organisation and not some semi-detached entity, focussed only on the beauty of its own navel. I give some indication of how to go about ensuring that this is the case in two articles, one focussed on a European environment and one spanning four continents.
No connection to the Process – I agree that embedding good BI in a coporoate culture requires effort (indeed I have written a series of articles on the subject, starting with this one), however I struggle to see how any BI team could fail to realise this and pay the area due attention. If this is truly a reason for failure, then it is because of a lack of basic project and change management skills in BI teams.
No Governance or Too Much – I’m not sure that achieving the Goldilocks approach to Governance is the issue here. BI’s impact on an organisation is directly proportional to how pervasive it is. This means that silos of BI reduce value and the walls need to be knocked in. Does this have to be all in one go? of course not, there are always benefits in a balance between incremental progress and paradigm shifts. Any organisation who has gatekeepers who refuse access to the warehouse because of and overly rigid approach to data standards is going to have problems. Equally where systems are developed with little thought to the information that they provide and data is simply thrown over the wall to the BI team, this is going to destroy value. As ever, there needs to be a sensible balance struck, one that yields the greatest business benefit for the lowest cost.
No Skills – “Business users often lack skills”, this seems both incredibly patronising (are only IT people smart enough to get it?) and also a poor excuse for BI teams not paying enough attention to education (see point 3. above). If business people truly lack the skills to use good BI, then they are probably unfit to be in business as the tools are pretty intuitive (if not over-engineered by an approach that is too technology-focussed). More likely, training has been poor, or the BI deliveries have failed to be tailored to answering questions that the business wants to ask.

In summary, I don’t have five reasons for BI failing to live up to expectations, I have one. 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.

Continue reading about this area in: Some reasons why IT projects fail

Doug Henschen joined Intelligent Enterprise as Editor in 2004 and was named Editor-in-Chief in January 2007. He has specialized in covering the intersection of business intelligence, performance management, business process management and rules management technologies within enterprise applications and architectures. He previously served as Editor-in-Chief of Transform Magazine, which covered content management and business process management challenges.

I comment on another Intelligent Enterprise article, this one by Cindi Howson, here.

The confluence of BI and change management

24 Feb 20093 Nov 2014 Peter James Thomas business, business intelligence, change management, cultural transformation, enterprise performance management, it business alignment, management information, technology actionable information, bi, business change, business intelligence, change management, cultural transformation, Heraclitus, information technology, it business alignment, management information, marketing change, performance management

The tag-line of this blog brings together business intelligence and cultural transformation. While one driver for this is that I have led BI projects that had explicit goals of cultural transformation, I think that there is a deeper connection to be explored here.

In other articles (notably “Can You Really Manage What You Measure?” by Neil Raden and Actionable Information), I discuss my experience that BI only adds value if:

The information it provides answers pertinent business questions, and
The answers to these questions lead to people taking action.

This means that any successful BI implementation has to consider such messy and difficult things as changing how people behave. This is where the link with change management arises.

Now of course you can argue that change management is an indispensible discipline for any business project (my strong opinion is that any IT project is a type of business project) and this is clearly true. However the parameters within which a new transaction processing system has to operate are different. Here if a person does not use the system, then work does not get done. Either it is impossible to carry out your job without the system (maybe only the system generates the necessary documentation), or not using the system to record transactions is a breech in compliance (keeping paper copies in your drawer).

BI systems are not like this. People chose to use them because they judge that they either make their business life easier, or they help to improve their decision-making (hopefully both). If someone doesn’t want to use a BI system, then they won’t and can probably get on with other parts of their job. The reason that change management is even more important in BI projects is that the element of compliance (or even coercion) is absent. If you want people to use the system and behave differently as a result, then you need to think about how best to influence them in these directions.

I have written elsewhere about the importance of marketing, education and follow-up in these areas. It also is important to explicitly recognise that a BI practitioner needs to be fully engaged in change management if they are to be successful.

A final thought also worth considering is that, as the BI industry matures and focus turns more to making it work in a business context than the latest flashy dashboard technology, it is likely that one of the things that will differentiate the best users of BI is how well they manage the necessary and desirable change that it drives.