it projects

“Why Business Intelligence projects fail”

Peter James Thomas business, business intelligence, it business alignment, project management, technology , , ,

Introduction

James Anderson bowls Sachin Tendulkar for 1 - England v India, 3rd Test, The Oval, August 12, 2007

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?

The British and Irish Lions scrum in South Africa - 1997

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:

  1. The business did not need or want better information
  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
  3. 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:

  1. Businesses are often complex, with many moving parts and many things that need to be measured
  2. Different business people may have different visions of what is important – each of these may have validity, depending on context
  3. Both IT and business people may be unaccustomed to talking about business phenomena in the required way (one that is self-consistent and exhaustive)
  4. IT may not have a proper understanding of business strategy, business terminology and business transactions
  5. 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
  6. 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

Peter James Thomas business intelligence, change management, cultural transformation, project management , , , , , , , , , ,
TechRepublic linkedin

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.

Metamorphosis II - Maurits Cornelis Escher (1898 - 1972)

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

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

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

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

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

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

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

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

 
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.
 

Using multiple business intelligence tools in an implementation – Part II

Peter James Thomas business, business intelligence, dashboards, data warehousing, management information, technology , , , , , , ,

Rather unsurprisingly, this article follows on from: Using multiple business intelligence tools in an implementation – Part I.

On further reflection about this earlier article, I realised that I missed out one important point. This was perhaps implicit in the diagram that I posted (and which I repeat below), but I think that it makes sense for me to make things explicit.

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

The point is that in this architecture with different BI tools in different layers, it remains paramount to have consistency in terminology and behaviour for dimensions and measures. So “Country” and “Profit” must mean the same things in your dashboard as it does in your OLAP cubes. The way that I have achieved this before is to have virtually all of the logic defined in the warehouse itself. Of course some things may need to be calculated “on-the-fly” within the BI tool, in this case care needs to be paid to ensuring consistency.

It has been pointed out that the approach of using the warehouse to drive consistency may circumscribe your ability to fully exploit the functionality of some BI tools. While this is sometimes true, I think it is not just a price worth paying, but a price that it is mandatory to pay. Inconsistency of any kind is the enemy of all BI implementations. If your systems do not have credibility with your users, then all is already lost and no amount of flashy functionality will save you.
 

Using multiple business intelligence tools in an implementation – Part I

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 , , , , , , , ,
linkedin The Data Warehousing Institute 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
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

London Bridge circa 1600
London Bridge circa 1600

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

One-stop shopping
One-stop shopping

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:

  1. Consistent look-and-feel: The tools will have a common look-and-feel, making it easier for people to use them and simplifying training.
  2. Better interoperability: Interoperability between the tools is out-of-the-box, saving on time and effort in developing and maintaining integration.
  3. Clarity in problem resolution: If something goes wrong with your implementation, you don’t get different vendors blaming each other for the problem.
  4. 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.
  5. 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.
  6. 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.

  1. 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.
  2. 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.
  3. 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!
  4. 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.
  5. 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.
  6. 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:

  1. Understand the important business decisions and what figures are necessary to support these.
  2. Understand the data available in the organisation, how it relates to other data and to business decisions.
  3. Transform the data to provide information answering business questions.
  4. 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
 

Business Intelligence Competency Centres

Peter James Thomas business, business intelligence, business intelligence competency centres, change management, cultural transformation, international projects, management, management information, project management, technology , , , , ,

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:

  1. 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).
  2. 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.
  3. 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.
  4. 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?):

  1. Understand the important business decisions and what figures are necessary to support these.
  2. Understand the data available in the organisation, how it relates to other data and to business decisions.
  3. Transform the data to provide information answering business questions.
  4. 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.
 

“Why do CFOs and CEOs hate IT? – ERP” – Thomas Wailgum at CIO.com

Peter James Thomas business, erp, international projects, project management, technology , ,

Thomas Wailgum at CIO.com

This is my second article in response to pieces by Thomas Wailgum at CIO.com (you can read the first one here). In Thomas’ latest piece, entitled Why CFOs and CEOs Hate IT: ERP, he touches on an area of which I have lengthy experience, ERP.

I spent the first eight years of my career working for a a software house, whose central product was in what we now call the ERP space. The big boys at Oracle Financials (then without PeopleSoft and J.D. Edwards in-train) were one of our main rivals and I had the pleasure of being involved in several bids where the little guys prevailed against their more renowned competition.

Later in my career, I was a player in a global selection process involving Oracle, PeopleSoft (then a separate company) and SAP and in laying the foundations for a US/European PeopleSoft implementation. Many years later again, after I had recorded a number of successes in another of my core areas, business intelligence, I was asked to add Financial IT once more to my portfolio. In this capacity, I oversaw the implementation of (by this time) Oracle PeopleSoft Financials in Denmark, Italy and then Australia, Hong Kong, Labuan and Singapore.

So, in one way or another, ERP and I have been around the block a few times. Given this, I could identify with some of Thomas’ observations. Many of these can be summed up in the phrase “an ERP system is for life, not just for Christmas.” Here are a few of Thomas’ thoughts:

A typical company in the CFO survey will spend an average of $1.2 million each year (each year!) to maintain, modify and update its ERP system.

ERP systems have become a noose around companies’ necks which tighten as the business changes every year, each customization gets made to the system and costs continue to spiral upward.

In some ways, ERP implementation is just like any other IT project and is difficult to get right for exactly the same reasons. But, as Thomas points out, some things that make ERP stand out are the massive initial outlays, the continuing cost of modifying what you originally thought you needed and the sheer size and complexity of most modern ERP systems.

You can think of your average ERP system from one of the large vendors as analogous to Microsoft Word. Because Word has to appeal to a lot of different users, with different needs and specialisms, it is chock-full of every single feature that anyone could ever need. However, no single person ever uses more than a fraction of these. I think of myself as a reasonably advanced Word user, but I would bet that I utilise no more than 10% of its capabilities. All of the functionality can make it tough for an entry-level user to employ Word in a basic way to do basic things (or if we are talking about Word 2007, it makes it tough for even an expert user to figure out how to do stuff). The same criticism can be applied to ERP systems. Because they include so much functionality for different companies in different industries, it can sometimes be difficult to configure them to do something as simple as entering and paying an invoice. Difficult that is without an army of consultants.

The way to avoid complexities and to get ERP implemented on time and budget is to ignore its broader capabilities and deploy as plain vanilla a version as you can get away with. Flexibility and the ability to customise might be very seductive at sales time, but they are the worst enemy of implementation and are certain to chew up resource, time and money. Instead the secret is to focus on the ways in which Finance in your organisation is the same as it most other organisations. Once you have this sorted out and a basically successful system in place, you can then think about bells and whistles. Of course by this time, you will probably be focused on upgrading to the latest version of your ERP system, but let’s put this unpleasant thought to one side for the purposes of this discussion.

But this begs another question, which Thomas covers more eloquently that I could. Plain vanilla ERP implementations, where you essentially adapt what your organisation does to the system’s standard functionality, mean that:

[…] employees who actually have to use the ERP system day in, day out will not only dislike the fact that you’re changing their technology interface, but now you’re going to allow the technology system to dictate to them how they should perform their job, with the new business processes.

Hercules and the Hydra - Antonio del Pollaiolo

However, even if we can suppress this second inconvenient truth about ERP, a further one arises – the area is indeed hydra-like. If the best practice for ERP implementations is to customise them as little as possible – shortening projects, reducing costs and simplifying upgrades – then why is there such a large price tag for all of the bells and whistles that it is impractical to actually use?

As Mr Wailgum says in closing:

But, perhaps, [CEOs and CFOs] have been making these decisions without knowing all the facts about the long-term costs associated with ERP systems, that the upfront “sticker price” is almost meaningless.

Which brings us right back to why CFOs and CEOs hate IT.

 

 
Starting in 1987 with CIO magazine, CIO’s portfolio of properties has grown to provide technology and business leaders with insight and analysis on information technology trends and a keen understanding of IT’s role in achieving business goals. The magazine and website have received more than 160 awards to date, including two Grand Neal Awards from the Jesse H. Neal National Business Journalism Awards and two National Magazine of the Year awards from the American Society of Publication Editors.
 

Recipes for success?

Peter James Thomas Biology, business, change management, management, project management, technology , , , , , , , , ,

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.
 
Recipe for Success?
 
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.
 

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

Peter James Thomas business, change management, it business alignment, technology , , , , , , , , , , ,

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

Tactical Meandering

Peter James Thomas bi and the economic crisis, business, business intelligence, it business alignment, project management, technology , , , , , , , ,

Meanders
 

  tactics /táktiks/ n.pl. 2 a the plans and means adopted in carrying out a scheme or achieving some end. (O.E.D.)  
  meander /miándər/ n. 1 a a curve in a winding river etc. b a crooked or winding path or passage. (O.E.D.)  

 
I was reminded of the expression “tactical meandering”, which I used to use quite a bit, by a thread on the LinkedIn.com Business Intelligence Group forum. The title of this was Is BI recession-proof? (as always, you need to be a member of both LinkedIn.com and the group to view this).

The conversation on the thread turned to the fact that, in the current economic climate, there may be less focus on major, strategic BI initiatives and more on quick, tactical ones that address urgent business needs.

My take on this is that it is a perfectly respectable approach, indeed it is one that works pretty well in my experience regardless of the economic climate. There is however one proviso, that the short-term work is carried out with one eye on a vision of what the future BI landscape will look like. Of course this assumes that you have developed such a vision in the first place, but if you haven’t why are you talking about business intelligence when report writing is probably what you are engaged in (regardless of how fancy the tools may be that you are using to deliver these).

I talked about this specific area extensively in my earlier article, Holistic vs Incremental approaches to BI and also offered some more general thoughts in Vision vs Pragmatism. In keeping with the latter piece, and although the initial discussions referred to above related to BI, I wanted to use this article to expand the scope to some other sorts of IT projects (and maybe to some non-IT projects as well).

Some might argue (as people did on the LinkedIn.com thread) that all tactical work has to be 100% complementary to you strategic efforts. I would not be so absolute. To me you can wander quite some way from your central goals if it makes sense to do so in order to meet pressing business requirements in a timely and cost-effective manner. The issue is not so much how far you diverge from your established medium-term objectives, but that you always bear these in mind in your work. Doing something that is totally incompatible with your strategic work and even detracts from it may not be sensible (though it may sometimes still be necessary), but delivering value by being responsive to current priorities demonstrates your flexibility and business acumen; two characteristics that you probably want people to associate with you and your team.

Tactical meandering sums up the approach pretty well in my opinion. A river can wander a long way from a line drawn from its source to its mouth. Sometimes it can bend a long way back on itself in order to negotiate some obstacle. However, the ultimate destination is set and progress towards it continues, even if this is sometimes tortuous.

Oxbow Lake Formation
Oxbow Lake Formation

Expanding on the geographic analogy, sometimes meanders become so extreme that the river joins back to its main course, cutting off the loop and leaving an oxbow lake on one side. This is something that you will need to countenance in your projects. Sometimes an approach, or a technology, or a system was efficacious at a point in time but now needs to be dropped, allowing the project to move on. These eventualities are probably inevitable and the important thing is to flag up their likelihood in advance and to communicate clearly when they occur.

My experience is that, if you keep you strategic direction in mind, the sum of a number of tactical meanders can advance you quite some way towards your goals; importantly adding value at each step. The quickest path from A to B is not always a straight line.
 

A more appropriate metaphor for Business Intelligence projects

Peter James Thomas business, business intelligence, management information, project management, technology , , , , , , , , , ,
A traditional metaphor for IT projects
A traditional metaphor for IT projects

IT people are familiar with a number of metaphors for their projects. The most typical relates to building; IT projects are compared to erecting a skyscraper. The IT literature is suffused with language derived from this metaphor. We build systems. We develop blueprints for them. We design architectures (two-for-one there). This analogy has some strength and there are indeed superficial similarities between the two areas. However, as with most metaphors, if over-extended their applicability often breaks down. I recall one CEO in particular who was obsessed by the “building team” moving on to the next “site”; regardless of the current one requiring further work and dedicated maintenance. One of his predecessors often referred to wanting a “diesel submarine” built, as opposed to a “nuclear one”. Before I fall into the same trap of over-exploiting the metaphor, let’s move hurriedly on.

As I mention above, aside from the occasional misapplication, the building analogy works reasonably well for many IT projects; does it also work for business intelligence? I think that there are some problems in applying the metaphor. Building tends to follow a waterfall project plan (as do many IT projects). Of course there may be some iterations, even many of them, but the idea is that the project is made up of discrete base-level tasks whose duration can be estimated with a degree of accuracy. Examples of such a task might include writing a functional specification, developing a specific code module, or performing integration testing between two sub-systems. Adding up all the base-level tasks and the rates of the people involved gets you a cost estimate. Working out the dependencies between the base-level tasks gets you an overall duration estimate.

The problem with BI projects is that some of the base-level tasks are a bit different. An example might be: develop an understanding of a legacy data table, how it relates to other legacy data sets and to more modern systems (this sits under area two of my model of BI development – see BI implementations are like icebergs). This is not an exercise that is very easy to estimate in advance. Indeed it may not be possible to produce an adequate estimate until a substantial amount of work has been done. Even at a late stage in the task, something may be discovered which expands the work required dramatically; surprises may lurk round every corner.

Why is this? Well with legacy data, the people who developed the system may have done so many years ago. Since then, they may have left the company or moved on to other areas, taking their knowledge with them. Their place may have been taken by successive tranches of new staff. Perhaps poor initial documentation meant that later workers did not fully understand the full nature of the system, but nevertheless did their best to build upon it. Perhaps the documentation was good at first, but has not been kept up-to-date and now describes a system that no longer exists.

By definition, legacy systems will have been around for some time and layers of changes will have accumulated on top of each other. Maybe, as a company has expanded, new data has been interfaced to the system from different business units and territories; perhaps each of these cases has its own dedicated interface code, each subtly different from those of other systems. Even where people exist in an organisation who preserve an “oral tradition” about the system, handed down to them over generations; these people may not appreciate how their data interacts with other data – even if the person who looks after another legacy system sits in the adjacent cubicle.

Waterfall Project Plan (intentionally blurred somewhat)

Although these challenges can also occur when trying to understand the data in more modern systems, they are particularly acute with older ones. For a start, the people who designed these systems are more likely to be around. Also legacy systems often sit at the centre of a Byzantine web of inter-connections, batch-processes, over-night jobs and the occasional more modern service. It can be a real mess and this is a situation with which any data analyst with a reasonable amount of experience will be very familiar.

The difficulty of estimating the duration of tasks such as properly analysing legacy data makes overall estimation of BI projects more of an art than a science. Of course techniques such as time-boxing tasks can be applied, but these are not always 100% appropriate. A 75% analysed data source (even assuming that the estimate that only 25% work is left is accurate) is not an analysed data source. Leaving dark corners of knowledge is likely to be reflected in BI cubes and reports that do not reconcile back to their sources. Probably the best way to deal with this problem is to be extremely open about the challenges up-front with executive sponsors and when submitting estimates. It helps to also stress the level of uncertainty in progress reports. The more honest you are initially, the better you will be able to explain any overruns and the more likely it is that you will be believed.

These types of issues mean that the – hopefully more orderly – process of constructing a building is not a fully accurate way to describe a BI project. That is unless the metaphor is extended to include an occurance that is all too common during construction in The City of London. Given the age of Londinium, whenever ground is broken on a new project, it is more likely than not that a mediaeval, Anglo-Saxon or Roman site is unearthed (often all three). These finds, while of enormous interest to academics, can result in projects being put on hold (sometimes for years) while the dig is fully assessed, artefacts are carefully removed and catalogued by experts and so on. Sometimes the remains are of such importance that a structure preserving and protecting them (and even allowing public viewing) has to be made part of the design of the foundations of new building. Many office blocks in The City have such viewing galleries in their basements. Such eventualities can create massive and unexpected overruns in central London building projects.

So this leads me to suggest a different metaphor for BI projects. Major elements of them are much more like archaeological digs than traditional building. The extent and importance of a dig is very difficult to ascertain before work starts and both may change during the course of a project. It is not atypical that an older site is discovered underneath an initial dig, doubling the amount of work required.

So, my belief is that BI professionals should not be likened to architects or structural engineers. Instead the epithet of archaeologist is much more appropriate. And if the fedora fits, wear it!

Fortune and glory in BI?
Fortune and glory in BI?

 

 
Apologies for the initial typo’ in the article heading, which persists in the perma-link. Of course I have the odd error scattered around the place, but in a heading! Maybe I need to employ a proof-reader.