Forming an Information Strategy: Part III – Completing the Strategy

Forming an Information Strategy
I – General Strategy II – Situational Analysis III – Completing the Strategy

Maybe we could do with some better information, but how to go about getting it? Hmm...

This article is the final of three which address how to formulate an Information Strategy. I have written a number of other articles which touch on this subject [1] and have also spoken about the topic [2]. However I realised that I had never posted an in-depth review of this important area. This series of articles seeks to remedy this omission.

The first article, Part I – General Strategy, explored the nature of strategy, laid some foundations and presented a framework of questions which will need to be answered in order to formulate any general strategy. The second, Part II – Situational Analysis, explained how to adapt the first element of this general framework – The Situational Analysis – to creating an Information Strategy. In Part I, I likened formulating an Information Strategy to a journey, Part III – Completing the Strategy sees us reaching the destination by working through the rest of the general framework and showing how this can be used to produce a fully-formed Information Strategy.

As with all of my other articles, this essay is not intended as a recipe for success, a set of instructions which – if slavishly followed – will guarantee the desired outcome. Instead the reader is invited to view the following as a set of observations based on what I have learnt during a career in which the development of both Information Strategies and technology strategies in general have played a major role.
 
 
A Recap of the Strategic Framework

Forth Rail Bridge
© http://www.thomashogben.co.uk

I closed Part I of this series by presenting a set of questions, the answers to which will facilitate the formation of any strategy. These have a geographic / journey theme and are as follows:

  1. Where are we?
  2. Where do we want to be instead and why?
  3. How do we get there, how long will it take and what will it cost?
  4. Will the trip be worth it?
  5. What else can we do along the way?

Part II explained the process of answering question 1 through the medium of a Situational Analysis. It is worth pointing out at this juncture that the Situational Analysis will also naturally form the first phase of the more lengthy process of gathering and analysing business requirements. For the purposes of the rest of this article, when such requirements are mentioned, they are taken as being the embryonic ones captured as part of the Situational Analysis.

In this final article I will focus on how to approach obtaining answers to questions 2 to 5. Having spent quite some time considering question 1 in the previous chapter, the content here will be somewhat briefer for the remaining questions; not least as I have covered some of this territory in earlier articles [3].
 
 
2. Where do we want to be instead and why?

My thoughts here split into two sub-sections. The second, What does Good look like?, is (as will be obvious from the title) more forward looking than backward. It covers reasons why the destination may be worth the journey. The first is more to do with why staying in the current location may not be a great idea [4]. However, one motivation for not staying put is that somewhere else may well be better. For this reason, there is not definitive border between these two sub-sections and it will be evident from the text that they instead bleed into each other.

2a. Drivers for Change

Change Next Exit

People often say that the gains that result from Information Programmes are intangible. Of course some may indeed be fairly intangible, but even the most ephemeral of these will not be entirely immune from some sort of valuation. Other benefits, when examined closely enough, can turn out to be surprisingly tangible [5]. In making a case for change (and of course the expenditure associated with this) it is good to try to have a balance of tangible and intangible factors. Here is a selection which may be applicable:

Internal IT drivers

  • These often centre around both the cost and confusion associated with a fragmented and inconsistent Information Landscape; something which, even as we head in to 2015, is still not atypical.
  • Opportunity costs may arise from an inability to combine data from different repositories or to roll up data to cover an entire organisation.
  • There is also a case to be made here around things like the licensing costs that result from having too many information repositories and too many tools being used to access them.
  • However, the cost of remediating such fragmentation can often appear in the shape of additional IT headcount devoted to maintaining a complex landscape and additional business headcount devoted to remediating information shortcomings.

Productivity gains

  • Less number crunching, more business-focussed analysis. Often an organisation’s most highly qualified (and highly paid) staff can spend much of their time repeating quotidian tasks that computers could do far more reliably. Freeing up such able and creative people to add more business value should be an objective and should have benefits.
  • At one company I estimated that teams would spend 5-7 days assembling the information necessary to support a meeting with one of a number of key business partners or a major client; our goal became to provide the same information effectively instantaneously; these types of benefits can be costed and also tend to resonate with business stakeholders.

Increasing sales / improving profitability

  • All information programmes (indeed most any business activity) should be dedicated to increasing profitability of course. In some specific industries the leverage of high-quality information is more readily associated with profitability than others. However, with enough time spent understanding the dynamics of an organisation, I would suggest that it is possible to make this linkage in a credible manner in pretty much any industry sector.
  • With respect to sales, sometimes if you want to increase say cross-selling, a very effective way is simply to measure it, maybe by department and salesperson. If there is some reliable way to track this, improvements in cross-selling will inevitably follow.

Mitigating operational risk

  • More reliable, unbiased and transparent production of information can address a number of operational risks; what these are specifically will vary from organisation to organisation.
  • However, most years see some organisation or another have to restate their results – there have been cases where adding two figures rather than subtracting them has led to a later restatement. Cases can often be built around the specific pain points in an organisation, or sometimes even near misses that were caught at the 11th hour.
  • Equally the cost of checking and re-checking figures before publication can be extremely high.

It is also generally worth asking business users what value they would ascribe to improved information, for example what things could they do under new arrangements that they cannot do now? It is important here that any benefits – and in particular any ones which prove to be intangible – are expressed in business language, not technical jargon.

2b. What does Good look like?

OK this dates me - I don't care!

Answering this question is predicated on both experience of successful information improvement programmes and a degree of knowledge about the general information market. There are two main elements here, what does good look like technically and what does it look like from a process / people perspective.

To cover the technical first, this is the simpler area, not least as we have understood how to develop robust, flexible and highly-performing information architectures for at least 15 years.

Integrated Information Architecture (click to view a larger version in a new tab)

The basics are shown in the diagram above [6]. Questions to consider here include:

  • What would a new information architecture look like?
  • What are the characteristics of the new which would indicate that it is an improvement on the old, can these be articulated to non-technical people?
  • What are required elements and how do they relate to the high-level needs captured in the Situational Analysis?
  • How does the proposed architecture relate to incumbent technologies and current staff skills?
  • Can any elements of existing information provision be leveraged, either temporarily or on an ongoing basis?
  • What has worked for other organisations and why would this be pertinent to the organisation in question?
  • Are any new developments in technology pertinent?

Arguably the more important area is the non-technical. Here there is a range of items to consider, some of which are captured in the following exhibit [7]:

Information Process (click to view a larger version  in a new tab)

I could spend an separate set of articles commenting on the elements of the above diagram; indeed I already have and interested readers are directed to the footnotes for links to some of these [8]. However it is worth pointing out the critical role to be played by both user education (a more apt phrase than training) and formal Data Governance. Also certain elements of information tend to work well when they sit within a regular business process; such as a monthly or quarterly review of specific aspects of results and future projections.
 
 
3. How do we get there, how long will it take and what will it cost?

Tube ticket machines

3a. Outline an Indicative Programme of Work

I am not going to offer Programme Planning 101 here, but briefly the first step in putting together an indicative programme of work is to decompose the overall journey into chunks, each of which can then be estimated. Each chunk should cover a group of reports / analyses and include activities from requirements gathering through to testing and finally deployment [9]. For the purposes of an indicative programme within a strategy document, the strategist can rely upon both information gathered in the Situational Analysis and their own experience of how to best decompose such work. Ultimately the size and number of the chunks should be dictated by business need, but at this stage estimates can be based upon experience and reasonable assumptions.

It is important that each chunk (or sub-chunk) delivers value and offers an opportunity for the approach and progress to be reviewed. A further factor to consider when estimating these chunks is that they should be delivered at a pace which allows them to be properly digested by users; resource allocations should reflect this. For each chunk the strategist should consider the type and quantum of resource required and the timing with which these are applied.

The indicative programme plan should also include a first phase which relates to reviewing the plan itself. Forming a strategy involves less people than running a programme. Even if initial estimation is carried out very diligently, it is likely that further issues will emerge once more detailed work later commences. As the information programme team ramps up, it is important that time is allocated for new team members to kick the tyres on the plan and make recommendations for improvement.

3b. How much will it cost?

Coins on scales

A big element of cost estimates will be a by-product of the indicative programme plan, which will cover programme duration and the amount of resource required at different points. Some further questions to consider when looking to catalogue costs include the following:

  • What are baseline costs for current information provision?
  • To what degree to these need to be incurred in parallel to an information improvement programme, are there ways to reduce these legacy costs to free up funds for the central programme?
  • What transitional costs are needed to execute the Information Strategy?
    • Hardware and software: is change necessary?
    • People: what is the best balance between internal, contract and outsourced resources, to what degree can existing staff be leveraged without compromising their current responsibilities?
    • How will costs vary by programme phase, will these taper as elements of older information systems are replaced by new facilities?
    • Can costs be reduced by having people play different roles at different points in the programme?
  • What costs will be ongoing once the strategy has been executed?
  • How do these compare to the current baseline?
  • Sometimes one aim of an Information Strategy will be to reduce to cost of ongoing support and maintenance, if so, how will this be achieved and how will any transition be managed?

A consideration here is whether the most important thing is to maximise speed of delivery or minimise risk? Things that will reduce risk could include: initial exploratory phases; starting with a small number of programme resources and increasing these based only on success; and instigating appropriate governance processes. However each of these will also increase duration and therefore cost. In some areas a trade off will be necessary and which side of these equations is more important will vary from organisation to organisation.
 
 
4. Will the trip be worth it?

Pros and cons

Answering parts of question 2 will help with getting a handle on potential benefits of executing an Information Strategy. Work on question 3 will get us an idea of the timeframes and costs involved. There is a need to combine the two of these into a cost / benefit analysis. This should be an honest and transparent assessment of the potential payback of adopting the Information Strategy. Given that most Information Strategies will take more than a year to implement and that benefits may equally be realised on an ongoing basis, it will generally make sense to look at figures over a 3-5 year period. It may be possible to draw up a quasi-P&L statement showing the impact of adopting the strategy, such an approach can resonate with senior stakeholders.

Points to recall and questions to consider here include:

  • Costs will emerge from the Indicative Programme Plan, but remember the ongoing costs of maintaining existing information capabilities.
  • As with most initiatives, the benefits of information programmes split into tangible and intangible components:
    • Where possible make benefits tangible even if this requires a degree of guesstimation [10].
    • Remember that many supposed intangibles can be estimated with some thought.
  • What benefits have other companies seen from similar programmes, particularly ones in the same industry sector?
  • Is it possible to perform “what if?” scenarios with current and future capabilities; could better information could have led to better outcomes? [11]
  • Ask business people to estimate the impact of better information.
  • Intangible benefits resonate where they are expressed in clear business language, not IT speak.

It should be borne in mind here that the cost / benefit analysis may not add up. If this is the case, then either a less expensive approach is more suitable for the company, or the potential benefits need to be looked at again. Where progress can genuinely not be made on either of these areas, the responsible strategist will acknowledge that doing nothing may well be the logical approach for the organisation in question.
 
 
5. What else can we do along the way?

Here be elephants

Finally, it is worth noting that short-term tactical deliveries can strongly support a strategy [12]. Interim work can meet urgent business needs in a timely manner. This is a substantial benefit in itself and also evidences progress in the area of improving information capabilities. It also demonstrates that that the programme team understands commercial pressures. This type of work is also complementary in that it can be used to:

  • Validate some elements of the cost / benefit analysis.
  • Round out requirements gathering.
  • Highlight any areas which have been overlooked.
  • Provide invaluable deployment and training experience, which can be leveraged for the implementation of more strategic capabilities.

It can also be useful make mistakes early and with small deliverables, not later with major ones. For these reasons, it is suggested that any Information Strategy should embrace “throw away” work. However this should be reflected in the overall programme plan and resources should be specifically allocated to this area. If this is not done, then tactical work can easily overwhelm the team and prevent progress on more strategic areas from being made; generally a death knell for a programme.
 
 
A Recap of the Main Points

  1. Carry out a Situational Analysis.
  2. As part of this, start the process of capturing High-level Business Requirements.
  3. Establish Drivers for Change, what benefits can be realised by better information, or by producing information in a better way?
  4. Ask “What Does Good Look Like?”, from both a technical and a process / people point of view.
  5. Develop an Indicative Programme of Work with realistic resource estimates and durations.
  6. Estimate Current, Transitional and Ongoing Costs.
  7. Itemise some of the major Interim Deliverables.
  8. Create a Cost / Benefits Analysis.

 
Bringing everything together

Chickie in dee Basget! Ing vurn spuur dee Chickie, Uun yeh vurn spay dee Basget!

There is a need to take the detailed work described over the course of the last three articles and the documentation which has been created as part of the process and to distill these down into a format that is digestible by senior management. There is no silver bullet here, summarising screeds of detail in a way that preserves the main points and presents them in a way that resonates is not easy. It takes judgement, an understanding of how businesses operate and strong analytical, writing and often diagrammatic skills. These will not be acquired by reading a blog article, but by honing experience and expertise over many years of work. To an extent, producing relevant and cogent summaries is where good IT professionals earn their money.

Unfortunately, at the time of writing, there is no book entitled Summarising Complex Issues for Dummies [13], [14].

This article and its two predecessors have been akin to listing the ingredients required to make a complex meal. While it is difficult to make great food without good ingredients or with some key spice missing, these things are not sufficient to ensure culinary excellence; what is also needed is a competent chef [15]. I cook a lot myself and, whenever I try a recipe for the first time, it can be a bit fraught. Sometimes I don’t get all of the elements of the meal ready at the same time, sometimes while I’m paying attention to reading the instructions for one part, another part boils over, or gets burnt. These problems with cooking tend dissipate with repetition. In the same way, what is generally needed in developing a sound Information Strategy is the equivalents great ingredients, a competent chef and an experienced one as well.
 

Forming an Information Strategy
I – General Strategy II – Situational Analysis III – Completing the Strategy

 
Notes

 
[1]
 
These include (in chronological order):

 
[2]
 
IRM European Data Warehouse and Business Intelligence Conference
– November 2012
 
[3]
 
Where this is the case, I will of course provide links back to my previous work.
 
[4]
 
Some of the factors here may come to light as a result of the previous Situational Analysis of course.
 
[5]
 
I grapple with estimating the potential payback of Information Programmes in a series of earlier articles:

 
[6]
 
This is an expanded version of the diagram I posted as part of Using multiple business intelligence tools in an implementation – Part I back in May 2009. I have elided details such as the fine structure of the warehouse (staging, relational, multidimensional etc.), master data sources and also which parts of it are accessed by different tools and different types of users. In a severe breach with the traditional IT approach, I have also left some arrows out.
 
[7]
 
This is an updated version of an exhibit I put together working with an actuarial colleague back in 2001, early in my journey into information improvement programmes.
 
[8]
 
These include my trilogy on the change management aspects of information programmes:

and a number of articles relating to Data Governance / Data Quality, notably:

 
[9]
 
Sometimes the first level of decomposition will need to be broken up into further and smaller chunks with this process iterating until the strategist reaches tasks which they are happy to estimate with a degree of certainty.
 
[10]
 
It may make sense to have different versions of the cost / benefit analysis, more conservative ones including only the most tangible benefits and more aggressive ones taking in to account benefits which have to be somewhat less certain.
 
[11]
 
Again see the series of three articles starting with Using historical data to justify BI investments – Part I.
 
[12]
 
For further thoughts on the strategic benefits of tactical work see:

 
[13]
 
Given both the two interpretations of this phrase and the typical audience for summaries of strategies, perhaps this is a fortunate thing.
 
[14]
 
I did however find the following title:

I can't however seem to find either Quantum Chromodynamics or Brain Surgery for Dummies

 
[15]
 
Contrary to the image above, a muppet (in the English sense of the word) won’t suffice.

 

 

The need for collaboration between teams using the same data in different ways

The Data Warehousing Institute

This article is based on conversations that took place recently on the TDWI LinkedIn Group [1].

The title of the discussion thread posted was “Business Intelligence vs. Business Analytics: What’s the Difference?” and the original poster was Jon Dohner from Information Builders. To me the thread topic is something of an old chestnut and takes me back to the heady days of early 2009. Back then, Big Data was maybe a lot more than just a twinkle in Doug Cutting and Mike Cafarella‘s eyes, but it had yet to rise to its current level of media ubiquity.

Nostalgia is not going to be enough for me to start quoting from my various articles of the time [2] and neither am I going to comment on the pros and cons of Information Builders’ toolset. Instead I am more interested in a different turn that discussions took based on some comments posted by Peter Birksmith of Insurance Australia Group.

Peter talked about two streams of work being carried out on the same source data. These are Business Intelligence (BI) and Information Analytics (IA). I’ll let Peter explain more himself:

BI only produces reports based on data sources that have been transformed to the requirements of the Business and loaded into a presentation layer. These reports present KPI’s and Business Metrics as well as paper-centric layouts for consumption. Analysis is done via Cubes and DQ although this analysis is being replaced by IA.

[…]

IA does not produce a traditional report in the BI sense, rather, the reporting is on Trends and predictions based on raw data from the source. The idea in IA is to acquire all data in its raw form and then analysis this data to build the foundation KPI and Metrics but are not the actual Business Metrics (If that makes sense). This information is then passed back to BI to transform and generate the KPI Business report.

I was interested in the dual streams that Peter referred to and, given that I have some experience of insurance organisations and how they work, penned the following reply [3]:

Hi Peter,

I think you are suggesting an organisational and technology framework where the source data bifurcates and goes through two parallel processes and two different “departments”. On one side, there is a more traditional, structured, controlled and rules-based transformation; probably as the result of collaborative efforts of a number of people, maybe majoring on the technical side – let’s call it ETL World. On the other a more fluid, analytical (in the original sense – the adjective is much misused) and less controlled (NB I’m not necessarily using this term pejoratively) transformation; probably with greater emphasis on the skills and insights of individuals (though probably as part of a team) who have specific business knowledge and who are familiar with statistical techniques pertinent to the domain – let’s call this ~ETL World, just to be clear :-).

You seem to be talking about the two of these streams constructively interfering with each other (I have been thinking about X-ray Crystallography recently). So insights and transformations (maybe down to either pseudo-code or even code) from ~ETL World influence and may be adopted wholesale by ETL World.

I would equally assume that, if ETL World‘s denizens are any good at their job, structures, datasets and master data which they create (perhaps early in the process before things get multidimensional) may make work more productive for the ~ETLers. So it should be a collaborative exercise with both groups focused on the same goal of adding value to the organisation.

If I have this right (an assumption I realise) then it all seems very familiar. Given we both have Insurance experience, this sounds like how a good information-focused IT team would interact with Actuarial or Exposure teams. When I have built successful information architectures in insurance, in parallel with delivering robust, reconciled, easy-to-use information to staff in all departments and all levels, I have also created, maintained and extended databases for the use of these more statistically-focused staff (the ~ETLers).

These databases, which tend to be based on raw data have become more useful as structures from the main IT stream (ETL World) have been applied to these detailed repositories. This might include joining key tables so that analysts don’t have to repeat this themselves every time, doing some basic data cleansing, or standardising business entities so that different data can be more easily combined. You are of course right that insights from ~ETL World often influence the direction of ETL World as well. Indeed often such insights will need to move to ETL World (and be produced regularly and in a manner consistent with existing information) before they get deployed to the wider field.

Now where did I put that hairbrush?

It is sort of like a research team and a development team, but where both “sides” do research and both do development, but in complementary areas (reminiscent of a pair of entangled electrons in a singlet state, each of whose spin is both up and down until they resolve into one up and one down in specific circumstances – sorry again I did say “no more science analogies”). Of course, once more, this only works if there is good collaboration and both ETLers and ~ETLers are focussed on the same corporate objectives.

So I suppose I’m saying that I don’t think – at least in Insurance – that this is a new trend. I can recall working this way as far back as 2000. However, what you describe is not a bad way to work, assuming that the collaboration that I mention is how the teams work.

I am aware that I must have said “collaboration” 20 times – your earlier reference to “silos” does however point to a potential flaw in such arrangements.

Peter

PS I talk more about interactions with actuarial teams in: BI and a different type of outsourcing

PPS For another perspective on this area, maybe see comments by @neilraden in his 2012 article What is a Data Scientist and what isn’t?

I think that the perspective of actuaries having been data scientists long before the latter term emerged is a sound one.

I couldn't find a suitable image from Sesame Street :-o

Although the genesis of this thread dates to over five years ago (an aeon in terms of information technology), I think that – in the current world where some aspects of the old divide between technically savvy users [4] and IT staff with strong business knowledge [5] has begun to disappear – there is both an opportunity for businesses and a threat. If silos develop and the skills of a range of different people are not combined effectively, then we have a situation where:

| ETL World | + | ~ETL World | < | ETL World ∪ ~ETL World |

If instead collaboration, transparency and teamwork govern interactions between different sets of people then the equation flips to become:

| ETL World | + | ~ETL World | ≥ | ETL World ∪ ~ETL World |

Perhaps the way that Actuarial and IT departments work together in enlightened insurance companies points the way to a general solution for the organisational dynamics of modern information provision. Maybe also the, by now somewhat venerable, concept of a Business Intelligence Competency Centre, a unified team combining the best and brightest from many fields, is an idea whose time has come.
 
 
Notes

 
[1]
 
A link to the actual discussion thread is provided here. However You need to be a member of the TDWI Group to view this.
 
[2]
 
Anyone interested in ancient history is welcome to take a look at the following articles from a few years back:

  1. Business Analytics vs Business Intelligence
  2. A business intelligence parable
  3. The Dictatorship of the Analysts
 
[3]
 
I have mildly edited the text from its original form and added some new links and new images to provide context.
 
[4]
 
Particularly those with a background in quantitative methods – what we now call data scientists
 
[5]
 
Many of whom seem equally keen to also call themselves data scientists

 

 

Forming an Information Strategy: Part II – Situational Analysis

Forming an Information Strategy
I – General Strategy II – Situational Analysis III – Completing the Strategy

Maybe we could do with some better information, but how to go about getting it? Hmm...

This article is the second of three which address how to formulate an Information Strategy. I have written a number of other articles which touch on this subject[1] and have also spoken about the topic[2]. However I realised that I had never posted an in-depth review of this important area. This series of articles seeks to remedy this omission.

The first article, Part I – General Strategy, explored the nature of strategy, laid some foundations and presented a framework of questions which will need to be answered in order to formulate any general strategy. This chapter, Part II – Situational Analysis, explains how to adapt the first element of this general framework – The Situational Analysis – to creating an Information Strategy. In Part I, I likened formulating an Information Strategy to a journey, Part III – Completing the Strategy sees us reaching the destination by working through the rest of the general framework and showing how this can be used to produce a fully-formed Information Strategy.

As with all of my other articles, this essay is not intended as a recipe for success, a set of instructions which – if slavishly followed – will guarantee the desired outcome. Instead the reader is invited to view the following as a set of observations based on what I have learnt during a career in which the development of both Information Strategies and technology strategies in general have played a major role.
 
 
A Recap of the Strategic Framework

LCP

I closed Part I of this series by presenting a set of questions, the answers to which will facilitate the formation of any strategy. These have a geographic / journey theme and are as follows:

  1. Where are we?
  2. Where do we want to be instead and why?
  3. How do we get there, how long will it take and what will it cost?
  4. Will the trip be worth it?
  5. What else can we do along the way?

In this article I will focus on how to answer the first question, Where are we? This is the province of a Situational Analysis. I will now move on from general strategy and begin to be specific about how to develop a Situational Analysis in the context of an overall Information Strategy.

But first a caveat: if the last article was prose-heavy, this one is question-heavy; the reader is warned!
 
 
Where are we? The anatomy of an Information Strategy’s Situational Analysis

The unfashionable end of the western spiral arm of the Galaxy

If we take this question and, instead of aiming to plot our celestial coordinates, look to consider what it would mean in the context of an Information Strategy, then a number of further questions arise. Here are just a few examples of the types of questions that the strategist should investigate, broken down into five areas:

Business-focussed questions

  • What do business people use current information to do?
  • In their opinion, is current information adequate for this task and if not in what ways is it inadequate?
  • Are there any things that business people would like to do with information, but where the figures don’t exist or are not easily accessible?
  • How reliable and trusted is existing information, is it complete, accurate and suitably up-to-date?
  • If there are gaps in information provision, what are these and what is the impact of missing data?
  • How consistent is information provision, are business entities and calculated figures ambiguously labeled and can you get different answers to the same question in different places?
  • Is existing information available at the level that different people need, e.g. by department, country, customer, team or at at a transactional level?
  • Are there areas where business people believe that data is available, but no facilities exist to access this?
  • What is the extent of End User Computing, is this at an appropriate level and, if not, is poor information provision a driver for work in this area?
  • Related to this, are the needs of analytical staff catered for, or are information facilities targeted mostly at management reporting only?
  • How easy do business people view it as being to get changes made to information facilities, or to get access to the sort of ad hoc data sets necessary to support many business processes?
  • What training have business people received, what is the general level of awareness of existing information facilities and how easy is it for people to find what they need?
  • How intuitive are existing information facilities and how well-structured are menus which provide access to these?
  • Is current information provision something that is an indispensable part of getting work done, or at best an afterthought?

Design questions

  • How were existing information facilities created, who designed and built them and what level of business input was involved?
  • What are the key technical design components of the overall information architecture and how do they relate to each other?
  • If there is more than one existing information architecture (e.g. in different geographic locations or different business units), what are the differences between them?
  • How many different tools are used in various layers of the information architecture? E.g.
    • Databases
    • Extract Transform Load tools
    • Multidimensional data stores
    • Reporting and Analysis tools
    • Data Visualisation tools
    • Dashboard tools
    • Tools to provide information to applications or web-portals
  • What has been the role of data modeling in designing and developing information facilities?
  • If there is a target data model for the information facilities, is this fit for purpose and does it match business needs?
  • Has a business glossary been developed in parallel to the design of the information capabilities and if so is this linked to reporting layers?
  • What is the approach to master data and how is this working?

Technical questions

  • What are the key source systems and what are their types, are these integrated with each other in any way?
  • How does data flow between source systems?
  • Is there redundancy of data and can similar datasets in different systems get out of synch with each other, if so which are the master records?
  • How robust are information facilities, do they suffer outages, if so how often and what are the causes?
  • Are any issues experienced in making changes to information facilities, either extended development time, or post-implementation failures?
  • Are there similar issues related to the time taken to fix information facilities when they go wrong?
  • Are various development tools integrated with each other in a way that helps developers and makes code more rigourous?
  • How are errors in input data handled and how robust are information facilities in the face of these challenges?
  • How well-optimised is the regular conversion of data into information?
  • How well do information facilities cope with changes to business entities (e.g. the merger of two customers)?
  • Is the IT infrastructure(s) underpinning information facilities suitable for current data volumes, what about future data volumes?
  • Is there a need for redundancy in the IT infrastructure supporting information facilities, if so, how is this delivered?
  • Are suitable arrangements in place for disaster recovery?

Process questions

  • Is there an overall development methodology applied to the creation of information facilities?[3]
  • If so, is it adhered to and is it fit for purpose?
  • What controls are applied to the development of new code and data structures?
  • How are requests for new facilities estimated and prioritised?
  • How do business requirements get translated into what developers actually do and is this process working?
  • Is the level, content and completeness of documentation suitable, is it up-to-date and readily accessible to all team members?
  • What is the approach to testing new information facilities?
  • Are there any formal arrangements for Data Governance and any initiatives to drive improvements in data quality?
  • How are day-to-day support and operational matters dealt with and by whom?

Information Team questions

  • Is there a single Information Team or many, if many, how do they collaborate and share best practice?
  • What is the demand for work required of the existing team(s) and how does this relate to their capacity for delivery?
  • What are the skills of current team members and how do these complement each other?
  • Are there any obvious skill gaps or important missing roles?
  • How do information people relate to other parts of IT and to their business colleagues?
  • How is the information team(s) viewed by their stakeholders in terms of capability, knowledge and attitude?

 
An Approach to Geolocation

It's good to talk. I was going to go with a picture of the late Bob Hoskins, but figured that this might not resonate outside of my native UK.

So that’s a long list of questions[4], to add to the list: what is the best way of answering them? Of course it may be that there is existing documentation which can help in some areas, however the majority of questions are going to be answered via the expedient of talking to people. While this may appear to be a simple approach, if these discussions are going to result in an accurate and relevant Situational Analysis, then how to proceed needs to be thought about up-front and work needs to be properly structured.

Business conversations

A challenge here is the range and number of people[5]. It is of course crucial to start with the people who consume information. These discussions would ideally allow the strategist to get a feeling for what different business people do and how they do it. This would cover their products/services, the markets that they operate in and the competitive landscape they face. With some idea of these matters established, the next item is their needs for information and how well these are met at present. Together feedback in these areas will begin to help to shape answers to some of the business-focussed questions referenced above (and to provide pointers to guide investigations in other areas). However it is not as simple an equation as:

Talk to Business People = Answer all Business-focussed Questions

The feedback from different people will not be identical, variations may be driven by their personal experience, how long they have been at the company and what part of its operations they work in. Different people will also approach their work in different ways, some will want to be very numerically focussed in decision-making, others will rely more on experience and relationships. Also even getting information out of people in the first place is a skill in itself; it is a capital mistake for even the best analyst to theorise before they have data[6].

This heterogeneity means that one challenge in writing the business-focussed component of a Situational Analysis within an overall Information Strategy is sifting through the different feedback looking for items which people agree upon, or patterns in what people said and the frequency with which different people made similar points. This work is non-trivial and there is no real substitute for experience. However, one thing that I would suggest can help is to formally document discussions with business people. This has a number of advantages, such as being able to run this past them to check the accuracy and completeness of your notes[7] and being able to defend any findings as based on actual fact. However, documenting meetings also facilitates the analysis and synthesis process described above. These meeting notes can be read and re-read (or shared between a number of people collectively engaged in the strategy formulation process) and – when draft findings have been developed – these can be compared to the original source material to ensure consistency and completeness.

IT conversations

I preferred Father Ted (or the first series of Black Books) myself; can't think where the inspiration for these characters came from.

Depending on circumstances, talking to business people can often be the largest activity and will do most to formulate proposals that will appear in other parts of the Information Strategy. However the other types of questions also need to be considered and parallel discussions with general IT people are a prerequisite. An objective here is for the strategist to understand (and perhaps document) the overall IT landscape and how this flows into current information capabilities. Such a review can also help to identify mismatches between business aspirations and system capabilities; there may be a desire to report on data which is captured nowhere in the organisation for example.

The final tranche of discussions need to be with the information professionals who have built the current information landscape (assuming that they are still at the company, if not then the people to target are those who maintain information facilities). There can sometimes be an element of defensiveness to be overcome in such discussions, but equally no one will have a better idea about the challenges with existing information provision than the people who deal with this area day in and day out. It is worth taking the time to understand their thoughts and opinions. With both of these groups of IT people, formally documented notes and/or schematics are just as valuable as with the business people and for the same reasons.

Rinse and Repeat

The above conversations have been described sequentially, but some element of them will probably be in parallel. Equally the process is likely to be somewhat iterative. It is perhaps a good idea to meet with a subset of business people first, draw some very preliminary conclusions from these discussions and then hold some initial meetings with various IT people to both gather more information and potentially kick the tyres on your embryonic findings. Sometimes after having done a lot of business interviews, it is also worth circling back to the first cohort both to ask some different questions based on later feedback and also to validate the findings which you are hopefully beginning to refine by now.

Of course a danger here is that you could spend an essentially limitless time engaging with people and not ever landing your Situational Analysis; in particular person A may suggest what a good idea it would be for you to also meet with person B and person C (and so on exponentially). The best way to guard against this is time-boxing. Give your self a deadline, perhaps arrange for a presentation of an initial Situational Analysis to an audience at a point in the not-so-distance future. This will help to focus your efforts. Of course mentioning a presentation, or at least some sort of abridged Situational Analysis, brings up the idea of how to summarise the detailed information that you have uncovered through the process described above. This is the subject of the final section of this article.
 
 
In Summary

Sigma

I will talk further about how to summarise findings and recommendations in Part III, for now I wanted to focus on just two aspects of this. First a mechanism to begin to identify areas of concern and second a simple visual way to present the key elements of an information-focussed Situational Analysis in a relatively simple exhibit.

Sorting the wheat from the chaff

To an extent, sifting through large amounts of feedback from a number of people is one way in which good IT professionals earn their money. Again experience is the most valuable tool to apply in this situation. However, I would suggest some intermediate steps would also be useful here both to the novice and the seasoned professional. If you have extensive primary material from your discussions with a variety of people and have begun to discern some common themes through this process, then – rather than trying to progress immediately to an overall summary – I would recommend writing notes around each of these common themes as a good place to start. These notes may be only for your own purposes, or they may be something that you also later choose to circulate as additional information; if you take the latter approach, then bear the eventual audience in mind while writing. Probably while you are composing these intermediate-level notes a number of things will happen. First it may occur to you that some sections could be split to more precisely target the issues. Equally other sections may overlap somewhat and could benefit from being merged. Also you may come to realise that you have overlooked some areas and need to address these.

Whatever else is happening, this approach is likely to give your subconscious some time to chew over the material in parallel. It is for this reason that sometimes the strategist will wake at night with an insight that had previously eluded them. Whether or not the subconscious contributes this dramatically, this rather messy and organic process will leave you with a number of paragraphs (or maybe pages) on a handful of themes. This can then form the basis of the more summary exhibit which I describe in the next section; namely a scorecard.

An Information Provision Scorecard

Information provision scorecard (click to view a larger version in a new tab)

Of course a scorecard about the state of information provision approaches levels of self-reference that Douglas R Hofstadter[8] would be proud of. I would suggest that such a scorecard could be devised by thinking about each of the common themes that have arisen, considering each of the areas of questioning described above (business, design, technical, process and team), or perhaps a combination of both. The example scorecard which I provide above uses the areas of questions as its intermediate level. These are each split out into a number of sub-categories (these will vary from situation to situation and hence I have not attempted to provide actual sub-category names). A score can be allocated (based on your research) to each of these on some scale (the example uses a 5 point one) and these base figures can be rolled up to get a score for each of the intermediate categories. These can then be further summarised to give a single, overall score [9].

While a data visualisation such as the one presented here may be a good way to present overall findings, it is important that this can be tied back to the notes that have been compiled during the analysis. Sometimes such scores will be challenged and it is important that they are based in fact and can thus be defended.
 
 
Next steps

Next steps

Of course your scorecard, or overall Situational Analysis, could tell you that all is well. If this is the case, then our work here may be done[10]. If however the Situational Analysis reveals areas where improvements can be made, or if there is a desire to move the organisation forward in a way that requires changes to information provision, then thought must be given to either what can be done to remediate problems or what is necessary to seize opportunities; most often a mixture of both. Considering these questions will be the subject of the final article in this series, Forming an Information Strategy: Part III – Completing the Strategy.
 


 
Addendum

When I published the first part of this series, I received an interesting comment from Gary Nuttall, Head of Business Intelligence at Chaucer Syndicates (you can view Gary’s profile on LinkedIn and he posts as @gpn01 on Twitter). I reproduce an extract from this verbatim below:

[When considering questions such as “Where are we?”] one thing I’d add, which for smaller organisations may not be relevant, is to consider who the “we” is (are?). For a multinational it can be worth scoping out whether the strategy is for the legal entity or group of companies, does it include the ultimate parent, etc. It can also help in determining the culture of the enterprise too which will help to shape the size, depth and span of the strategy too – for some companies a two pager is more than enough for others a 200 pager would be considered more appropriate.

I think that this is a valuable additional perspective and I thank Gary for providing this insightful and helpful feedback.
 

Forming an Information Strategy
I – General Strategy II – Situational Analysis III – Completing the Strategy

 
Notes

 
[1]
 
These include (in chronological order):

 
[2]
 
IRM European Data Warehouse and Business Intelligence Conference
– November 2012
 
[3]
 
There are a whole raft of sub-questions here and I don’t propose to be exhaustive in this article.
 
[4]
 
In practice its at best a representative subset of the questions that would need to be answered to assemble a robust situational analysis.
 
[5]
 
To get some perspective on the potential range of business people it is necessary to engage in such a process, again see the aforementioned Developing an international BI strategy.
 
[6]
 
With apologies to Arthur Conan Doyle and his most famous creation.
 
[7]
 
It is not atypical for this approach to lead to people coming up with new observations based on reviewing your meeting notes. This is a happy outcome.
 
[8]
 
B.T.L. - An eternal golden braid (with apologies to Douglas R Hofstadter

Gödel, Escher, Bach: An Eternal Golden Braid has been referenced a number of times on this site (see above from New Adventures in Wi-Fi – Track 3: LinkedIn), but I think that this is the first time that I have explicitly acknowledged its influence.

 
[9]
 
You can try to be cute here and weight scores before rolling them up. In practice this is seldom helpful and can give the impression that the precision of scoring is higher than can ever actually be the case. Judgement also needs to be exercised in determining which graphic to use to best represent a rolled up score as these will seldom precisely equal the fractions selected; quarters in this example. The strategist should think about whether a rounded-up or rounded-down summary score is more representative of reality as pure arithmetic may not suffice in all cases.
 
[10]
 
There remains the possibility that the current situation is well-aligned with current business practices, but will have problems supporting future ones. In this case perhaps a situational analysis is less useful, unless this is comparing to some desired future state (of which more in the next chapter).

 

 

Forming an Information Strategy: Part I – General Strategy

Forming an Information Strategy
I – General Strategy II – Situational Analysis III – Completing the Strategy

Maybe we could do with some better information, but how to go about getting it? Hmm...

This article is the first of three which address how to formulate an Information Strategy. I have written a number of other articles which touch on this subject[1] and have also spoken about the topic[2]. However I realised that I had never posted an in-depth review of this important area. This series of articles seeks to remedy this omission.

Part I – General Strategy explores the nature of strategy, lays some foundations and presents a framework of questions which will need to be answered in order to form any general strategy. Part II – Situational Analysis adapts the first part of this general framework – The Situational Analysis – to the task of starting to form an Information Strategy. The final chapter, Part III – Completing the Strategy, rounds out this process by working through the rest of the general framework and explaining how this can be used to produce a fully-formed Information Strategy.

As with all of my other articles, this essay is not intended as a recipe for success, a set of instructions which – if slavishly followed – will guarantee the desired outcome. Instead the reader is invited to view the following as a set of observations based on what I have learnt during a career in which the development of both Information Strategies and technology strategies in general have played a major role.
 
 
What is a Strategy?

A more optimal strategy would probably have been to beware the Ides of March

This would seem to be a relatively easy question to answer as the word is used (more likely over-used) in many areas of human endeavour and in business in particular. Let’s start by seeing if we can reach a consensus by the power of Google:

Wikipedia Strategy (from Greek στρατηγία stratēgia, “art of troop leader; office of general, command, generalship”) is a high level plan to achieve one or more goals under conditions of uncertainty. [and also later in the same article] Max McKeown (2011) argues that “strategy is about shaping the future” and is the human attempt to get to “desirable ends with available means”.
The Oxford English Dictionary[3] /stráttiji/ n. 1 the art of war. 2 a the management of an army or armies in a campaign. b the art of moving troops, ships, aircraft, etc. into favourable positions (cf. TACTICS). c an instance of this or a plan formed according to it. 3 a plan of action or policy in business or politics etc. (economic strategy) [F stratégie f. Gk strātegia generalship f. stratēgeos]
Meta-entry […] a plan of action designed to achieve a long-term or overall aim.
“time to develop a coherent economic strategy” […]
The Business Dictionary […] a method or plan chosen to bring about a desired future, such as achievement of a goal or solution to a problem. […]

So – assuming we decide, in the context of this blog, that the objective is probably not to better order military affairs, or to teach infantry men and women to write MDX – some sort of loose consensus emerges from the various definitions above. It seems that a strategy is something which seeks to influence the future, to bring about some conditions or cause an event, neither of which would manifest themselves without some action being taken[4]. I am going to adopt the definition that a strategy is a method to achieve some future objective; or at least to make the realisation of this aim more likely. This means that a strategy implies change. If the situation is now X then after the strategy has been successfully enacted then the situation will then be Y[5].
 
 
A Metaphor for Strategy

Plotting a Strategy

The role of change in strategy leads me to think about strategy formulation in the following way[6]. I think of situation X (the current one) as a place on a map. Then situation Y (the desired one) is a second place on the same map. We are at X and we want to get to Y, we have a starting point and a destination, an origin and a terminus. The shortest distance between two points is of course a straight line[7]. However a straight line between between X and Y may not exist (there could be a lake in between with no method to traverse this), or it might not be the quickest route (if the line passes over an intervening mountain, which could instead be more quickly circumnavigated). In general there may be more than one route between X and Y and each may have its advantages and disadvantages. I tend to think of strategy formation as the process by which the best (or, if this is all that is achievable, least bad) route is established.

Of course a challenge here is that – outside the realms of mathematics (or indeed SatNav) – there may not be an optimum route and equally no optimum strategy. Even if an optimum strategy does exist, the strategist may not have enough information[8] to hand to discern this. Also, while effecting change is the objective of a strategy, this aim may itself be impacted by change; to employ our metaphor of travel, change to the destination, or to the territory in between. This may mean that the route (the strategy) must be adjusted, or in some cases wholly abandoned in favour of a different approach. Strategy formulation has some scientific-like qualities and I will focus on some of these shortly. However for the reasons just put forward (and indeed others we will examine later) elements of the strategy formation process can sometimes be more of an art form.

Of course another problem could be that you don’t have a map!

Having introduced a geographic quality to describing strategy formation, I’ll leverage this analogy[9] for the rest of the article. However, first a slight detour to establish the credentials of your guide to the terrain of Information Strategy; namely me. Any readers who are already familiar with my work are encouraged to scroll past the next section.
 
 
So what do I know about Information Strategies anyway?

Résumé

I have worked in IT for over quarter of a century with much of that related to turning data into information. Indeed one of my early tasks during my first job at a software house was to help design and develop the automated Balance Sheet and Profit and Loss statements provided as part of the company’s flagship product. These took the transactions entered into the company’s General Ledger system and assembled them into sensible Financial statements, which could be sliced and diced[10] by period, cost centre or project code. However, my full initiation to the related areas of Business Intelligence and Data Warehousing was not until the beginning of 2000, when I was asked to establish a Management Information function for a pan-European insurance organisation. This means that I don’t reach my 15-year BI/DW milestone until New Year (actually probably some point in the middle of January 2015)[11].

Having both developed and executed an Information Strategy for the European part of this company, I extended both of these processes to encompass Latin America. I then developed a broader Information Strategy which included all of their International operations. It is gratifying to note that this strategy still guides information provision at this organisation to this day. After this, I went on to shape Information Strategies for other companies in sectors such as Manufacturing, Retail and back to Reinsurance / Insurance again. In each of these cases, I either saw the execution of these strategies through to at least their first delivery, or the programmes of work that I crafted were then executed by the teams that I had built.

My teams also won a couple of awards for this work along the way.
 
 
The Questions driving Strategy Formation

Questions

There are many good resources available in printed form and on-line for those who want to understand various approaches to general strategy formulation. For readers who are interested in strategy outside of a technology context and specifically outside of the area of Information Strategy, then Google is your friend. For anyone who is still with us, then while I would not claim to be an all-purpose strategy guru, I think that it is worth starting by presenting some general questions that pertain to the area of strategy formation. I am going to cast these in the shape of the geographic / journey metaphor that I developed above. Adopting this framework, any general strategy will have to answer the following questions:

  1. Where are we?
    Answering this question is the province of a Situational Analysis. Such a study will highlight what is good about the current situation as well as what needs to be changed.
     
  2. Where do we want to be instead and why?
    Here it is useful to consider two things: first Drivers for Change (which may emerge from the Situational Analysis); second a further question, What does good look like? This area is thus a mixture of what is wrong with the current situation and what would be good about the one proposed as the objective of the strategy[12].
     
  3. How do we get there, how long will it take and what will it cost?
    Thinking of the most perfect of destinations is going to be of little use if it costs too much to get there or the journey time is prohibitive. Here the strategist needs to get more concrete and consider realistic estimates of time and money.
     
  4. Will the trip be worth it?
    There is a relation here to areas covered under the earlier bullet points, but answering this question will normally require some sort of cost/benefit analysis. In describing what good looks like, many potential benefits may be articulated, here there is a need to quantify them as best as is possible.
     
  5. What else can we do along the way?
    Some might quibble at the inclusion of this item. However I think that the metaphor of a journey lends itself to considering what tactical work can help buttress the central activities of the strategy.

The framing of the above in terms pertinent to a journey may not be familiar[13], but I think that it is useful. This metaphor also has the benefit of alluding to what is inevitably the case with each of strategy development, strategy execution and the most worthwhile of journeys; they seldom happen overnight.

Having laid some general foundations, the next article in this series, Part II, will begin to be more specific and consider how these questions can be applied to forming the first element an Information Strategy, a Situational Analysis.
 

Forming an Information Strategy
I – General Strategy II – Situational Analysis III – Completing the Strategy

 
Notes

 
[1]
 
These include (in chronological order):

 
[2]
 
IRM European Data Warehouse and Business Intelligence Conference
– November 2012
 
[3]
 
Actually The Oxford English Dictionary and Thesaurus (1997). Ink on cellulose pulp edition (this format used to be quite popular once upon a time). Also still available from antiquarian booksellers.
 
[4]
 
Yes Minister
Here I assume that waiting around for something to happen, when it was going to happen anyway, is not a strategic approach; “that would be to mistake lethargy for strategy” (© Antony Jay and Jonathan Lynn. Yes Minister – The Writing on the Wall)
 
[5]
 
I suppose the assumption here is that situation Y is preferable to situation X; at least from the point of view of the strategist.
 
[6]
 
Amongst many other articles on this site, see The confluence of BI and change management for an explicit link between change and Business Intelligence.
 
[7]
 
Assuming Euclidean Geometry, if not then maybe try this instead.
 
[8]
 
Here I am using the term generally rather than in the sense of information generated by systems, which even today remains mostly numeric; albeit that other forms of data have streaked ahead of dowdy old numbers some time ago. Numeric data tends to be somewhat easier to transform into information than non-numeric; at least for now.
 
[9]
 
Perhaps it is worth introducing a note of caution about the over-extension of analogies here – I do this in an earlier article bearing the same name.
 
[10]
 
To this day, I have a compulsion to write “dice and slice” as opposed to “slice and dice”, despite the latter being a more logical sequence of events when approaching – say – a butternut squash.
 
[11]
 
I am looking forward to my engraved TDWI decanter immensely.
 
[12]
 
Sometimes the current situation is so bad that simply addressing its shortcomings is enough work for a strategy to consider. More often a strategy will look to ad value beyond just remediating current issues.
 
[13]
 
Though I can hardly claim to be the first person to come up with this metaphor.

 

 

Some thoughts on the IRM(UK) DW/BI conference

As previously advertised, I presented at the recent IRM(UK) DW/BI seminar in London. As a speaker I was entitled to attend the full three days, but as is typically the case, other work commitments meant that I only went along on the day of my session, 4th November. A mixture of running into business acquaintances, making sure that audio/visual facilities work and last minute run-throughs of my slides all conspired to ensure that I was able to listen to fewer talks that I would have liked. In comparing notes with other speakers, it is generally the same for them. Maybe I should consider attending a seminar as a delegate sometime!

Nevertheless, I did get along to some presentations and also managed to finally meet Dylan Jones of dataqualitypro.com (@DataQualityPro) in person after running into each other virtually for years. Unfortunatlely, I also managed to fail to connect with a number of tweeps of my acquaintance including: Loretta Mahon Smith (@silverdata) – who even attended my talk without us bumping into each other – and Scott Davis (@scottatlyzasoft); I guess that is just how it goes with seminars sometimes.
 
 
Story-telling and Information Quality

Ma mère l'oye by Gustave Doré (for the avoidance of doubt, I'm not saying that Lori is Mother Goose)

At face value these may seem odd bed-fellows. However, Lori Silverman of Partners for Progress managed to intertwine the two effectively. This was despite being handicapped by an attack of laryngitis that meant that her, already somewhat nasal tones, from time to time morphed into a shriek. Sitting as I was directly beside a loudspeaker, I felt some initial discomfort and even considered departing for a less auricularly challenged part of the conference centre. However I was glad that I decided to tough it out because Lori turned out to be a very entertaining, engaging and insightful speaker. I won’t steal her thunder by revealing her main thesis and instead suggest that you try to catch her speaking at some future point, she is well worth listening to in my opinion.
 
 
Open Source BI makes headway in the Irish Government sector

Jaspersoft and System Dynamics

I next attended a presentation by leading open source BI company Jaspersoft. This was kicked-off by their CEO Brian Gentile who then introduced a case study about an Irish Government department rolling-out the company’s products. The implementer, was System Dynamics, Ireland’s largest indigenous IT business solutions company*.

System Dynamics CEO Tony McGuire and BI Team Lead Emmet Burke both spoke about this recent project, which covered 500+ users. Open source has traditionally had something of a challenge establishing a foothold in the public sector. The assertion made in this session was that the current fiscal challenges faced by the Irish Republic meant that it was becoming an option they were giving greater credence to. I guess, as with many areas of open source applications, it is probably a case of waiting to see whether a trend establishes itself.

John Taylor of Information Builders was speaking in the room that would next host my session and so I was able to catch the last 15 minutes of his presentation on Information Management, which seemed to have been well-attended and well-received.
 
 
Measuring the benefits of BI

My presentation occupied the graveyard slot of 4:30pm and I led by saying that I fully realised that all that stood between delegates and the drinks reception was my talk. Given the lateness of the hour, I had been a little concerned about attendance, but I guess that there were at least 50 or so people present. All of them stuck it out to the bitter end, which was gratifying.

There is always the moment of frisson in public speaking when, at the end of the talk, you ask whether are any questions with an image of tumbleweed spinning across the prairie in your mind (something that happened to me on one previous occasion a long time ago). Thankfully the audience asked a number of interesting and insightful questions, which I answered to the best of my ability. Indeed I was locked in discussions with a couple of delegates long after the meeting had officially broken up.

Measuring the success of BI - Agenda

In my introduction, I began by issuing my customary caveat about the danger of too blindly following any recipe for success. I then provided some background about my first major achievement in data warehousing and went on to present the general framework for success in BI/DW programmes that I developed as a result of this. In concluding the first part of the speech, I attempted to delineate the main benefits of BI and also touched on some of its limitations.

Having laid these hopefully substantial foundations, the meat of the presentation expanded on ideas I briefly touched on in my earlier article Measuring the Benefits of Business Intelligence. This included highlighting some of the reasons why measuring the impact of BI on, say, profitability can be a challenge, but stressing that this was still often an objective that it was possible to achieve. I also spent some time examining in detail different techniques for quantifying the different tangible and intangible impacts of BI (most of which are covered in the above referenced article).

A sporting analogy by the back-door - England's victory in the 2003 Rugby World Cup, which was clearly inspired by the successful launch of the first phase of the EMIR BI/DW system at Chubb Insurance earlier in the year

My closing thought was that, in situations where it is difficult to precisely assess the monetary impact of BI, the wholehearted endorsement of your business customers can be a the best indirect measurement of the success (or otherwise) of your work. I would recommend that fellow BI professionals pay close attention to this important indicator at all stages of their projects.
 
 


 
You can view some of the tweets about IRM(UK) DW/BI here, or here.
 
Disclosure: At the time of writing, System Dynamics is a business partner, but not in the field of business intelligence.
 

Business Sponsorship

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

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

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

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

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

A good place to go and ask for sponsorship money

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

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

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

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

Why have a dog and Bach yourself?

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

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

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

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

Who should be accountable for data quality?

The cardinality of a countable set - ex-mathematicians are allowed the occasional pun

linkedin CIO Magazine CIO Magazine forum

Asking the wrong question

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

The discussion included the predictable references to GIGO, but conversation then moved on to who has responsibility for data quality, IT or the business.

My view on how IT and The Business should be aligned

As regular readers of this column will know, I view this as an unhelpful distinction. My belief is that IT is a type of business department, with specific skills, but engaged in business work and, in this, essentially no different to say the sales department or the strategy department. Looking at the question through this prism, it becomes tautological. However, if we ignore my peccadillo about this issue, we could instead ask whether responsibility for data quality should reside in IT or not-IT (I will manfully resist the temptation to write ~IT or indeed IT’); with such a change, I accept that this is now a reasonable question.
 
 
Answering a modified version of the question

In information technology, telecommunications, and related fields, handshaking is an automated process of negotiation that dynamically sets parameters of a communications channel established between two entities before normal communication over the channel begins. It follows the physical establishment of the channel and precedes normal information transfer.

My basic answer is that both groups will bring specific skills to the party and a partnership approach is the one that is most likely to end in success. There are however some strong arguments for IT playing a pivotal role and my aim is to expand on these in the rest of this article.

The four pillars of improved data quality

Before I enumerate these, one thing that I think is very important is that data quality is seen as a broad issue that requires a broad approach to remedy it. I laid out what I see as the four pillars of improving data quality in an earlier post: Using BI to drive improvements in data quality. This previous article goes into much more detail about the elements of a successful data quality improvement programme and its title provides a big clue as to what I see as the fourth pillar. More on this later.
 
 
1. The change management angle

Again, as with virtually all IT projects, the aim of a data quality initiative is to drive different behaviours. This means that change management skills are just as important in these types projects as in the business intelligence work that they complement. This is a factor to consider when taking decisions about who takes the lead in looking to improve data quality; who amongst the available resources have established and honed change management skills? The best IT departments will have a number of individuals who fit this bill, if not-IT has them as well, then the organisation is spoilt for choice.
 
 
2. The pan-organisational angle

Elsewhere I have argued that BI adds greatest value when it is all-pervasive. The same observations apply to data quality. If we assume that an organisation has a number of divisions, each with their own systems (due to the nature of their business and maybe also history), but also maybe sharing some enterprise applications. While it would undeniably be beneficial for Division A to get their customer files in order, it would be of even greater value if all divisions did this at the same time and with a consistent purpose. This would allow the dealings of Customer X across all parts of the business to be calculated and analysed. It could also drive cross-selling opportunities in particular market segments.

While it is likely that a number of corporate staff of different sorts will have a very good understanding about the high-level operations of each of the divisions, it is at least probable that only IT staff (specifically those engaged in collating detailed data from each division for BI purposes) will have an in-depth understanding of how transactions and master data are stored in different ways across the enterprise. This knowledge is a by-product of running a best practice BI project and the collateral intellectual property built up can be of substantial business value.
 
 
3. The BI angle

It was this area that formed the backbone of the earlier data quality article that I referenced above. My thesis was that you could turn the good data quality => good BI relationship on its head and use the BI tool to drive data quality improvements. The key here was not to sanitise data problems, but instead to expose them, also leveraging standard BI functionality like drill through to allow people to identify what was causing an issue.

One of the most pernicious data quality issues is of the valid, but wrong entry. For example a transaction is allocated a category code of X, which is valid, but the business event demands the value Y. Sometimes it is possible to guard against this eventuality by business rules, e.g. Product A can only be sold by Business Unit W, but this will not be possible for all such data. A variant of this issue is data being entered in the wrong field. Having spent a while in the Insurance industry, it was not atypical for a policy number to be entered as a claim value for example. Sometimes there is no easy systematic way to detect this type of occurrence, but exposing issues in a well-designed BI system is one way of noticing odd figures and then – crucially – being able to determine what is causing them.
 
 
4. The IT character angle

I was searching round for a way to put this nicely and then realised that Jim Harris had done the job for me in naming his excellent Obsessive-Compulsive Data Quality blog (OCDQ Blog). I’m an IT person, I may have general management experience and a reasonable understanding of many parts of business, but I remain essentially an IT person. Before that, I was a Mathematician. People in both of those lines of work tend to have a certain reputation; to put it positively, the ability to focus extremely hard on something for long periods is a common characteristic.

  Aside: for the avoidance of doubt, as I pointed out in Pigeonholing – A tragedy, the fact that someone is good at the details does not necessarily preclude them from also excelling at seeing the big picture – in fact without a grasp on the details the danger of painting a Daliesque big picture is perhaps all too real!  

Improving data quality is one of the areas where this personality trait pays dividends. I’m sure that there are some marketing people out there who have relentless attention to detail and whose middle name is “thoroughness”, however I suspect there are rather less of them than among the ranks of my IT colleagues. While leadership from the pertinent parts of not-IT is very important, a lot of the hard yards are going to be done by IT people; therefore it makes sense if they have a degree of accountability in this area.
 
 
In closing

Much like most business projects, improving data quality is going to require a cross-functional approach to achieve its goals. While you often hear the platitudinous statement that “the business must be responsible for the quality of its own data”, this ostensible truism hides the fact that one of the best ways for not-IT to improve the quality of an organisation’s data is to get IT heavily involved in all aspects of this work.

IT for its part can leverage both its role as one of the supra-business unit departments and its knowledge of how business transactions are recorded and move from one system to another to become an effective champion of data quality.
 

Running before you can walk

Prelude…

I have been back blogging for a few days, so it is well past time for a rock climbing-related post. Though this site being what it is, I’ve twisted this thought round to apply to the world of IT.

Case of the Month

Symptoms: 42 year-old with recent long finger injury and resultant deformity.

A2 pulley damage - this is not my finger, but is most likely the injury that I have

Diagnosis Disruption of the A2 (white arrow), A3 (black arrow), and A4 (black arrowhead) pulleys. The primary function of the pulley system is to provide stability to the flexor tendons during flexion by fixing them to the underlying osseous structures. Injuries to the pulley system, commonly seen in rock climbers, lead to bowstringing of the flexor tendons with abnormal separation from the underlying phalanges.

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

Living in London, real rock is always a reasonably lengthy drive away, but in normal circumstances I would train indoors at least twice, and normally three times, a week and climb outdoors as often as possible. However, for a variety of reasons (including an ankle injury to myself, a chronic shoulder injury to my partner and both having an awful lot of other things on), I have not been climbing very much for several months. About a month ago, my partner and I decided to make a point of once more getting to the wall at least once a week. The problem is that, after a lay-off, your mind can remember climbing at a certain level but your body is way off the pace.

A combination of keenness, a desire to make up for lost time, pride and pig-headedness often sees a climber who is returning from injury quickly try to get back on to the level of routes/problems that they were achieving before. My limit, both indoors and out, used to be around V4 (fairly low down on the overall scale of climbing), with the occasional V5 indoors only. Having a few tentatively successful sessions under my belt, I found an indoor V5 that played to my strengths and was making some progress on it. It was a bit fingery and required use of a technique called crimping (see the image below):

An example of crimping

This is a very effective way of getting purchase on small holds, but puts a lot of pressure on your fingers. Levering my body up from sitting on the ground with both hands crimping like mad I felt a sort of crunching in the ring finger of my left hand. I stopped my attempt and decided that I would warm down on some easier stuff. Sadly even easier stuff can be quite demanding on the fingers and on my next but one climb I ended up pulling quite hard on the same left hand. There was a very audible pop, my left hand exploded off of the hold and I found myself on the floor holding my swollen finger in quite some pain.

After intensive icing at the wall and some therapeutic treatment in the four or so weeks since, I am still able to bend the finger (so hopefully do not have a full rupture of the tendon), but am a long way off of going back to climbing. I also have an unhelpful mental image of the tendon hanging by a thread, it is going to take quite some time for me to get over this; even if the finger itself heals.

Old tendon injury to ring finger of right hand

It doesn’t help that I fully ruptured the same tendon in my right ring finger when playing rugby as a teenager (see above). I can’t bend the top section of that finger and it has been a bit of an issue for me when climbing on occasion.

Tommy Caldwell - "high four"

Professional climber Tommy Caldwell (above) cut off one of his fingers in a DIY accident and still climbs to an astonishingly high level, so I can’t complain too much about this earlier injury. However I am now rather concerned about having matching tendon problems on both hands. I guess time will tell how serious this new injury is and what level of recovery I will experience. I hope to be able to avoid surgery, which is in any case no guarantee of a cure.

One of the most frustrating aspects of all this is that I feel as if I had a warning with the initial crunchiness, I chose to ignore this, which then led to the more serious injury. I guess it rather feels that I could have avoided getting myself in this situation with a little more thought.

The learning here is twofold: specifically how easy it is to injure yourself when returning from a lay-off; and generally that it is also much too tempting to try things that you are not yet ready for – to run before you can walk. The first lesson applies to climbing and sport in general, the second has wider applicability and some pertinence to the work of IT in particular.
 
 
…and Fugue

Running before you can walk seems to be something that particularly afflicts IT departments and IT people when they are in a bit of a hole already. If an IT department has been under-performing, or has become semi-detached from the business (the latter often leading to the former), there can be a desperate desire to get onto firmer ground quickly. I have seen this manifest itself in a couple of ways:

  1. An overwhelming urge to do something that will be appreciated by the business and make a difference – here the desire is for a quick redemption, unfortunately the concomitant rushing and even omission of key steps in the development process are just as likely to lead to more business disappointment and an increasingly tarnished reputation.
  2. The second symptom is virtually antipodal to the first; an unhealthy clinging to formal methodologies, or (much worse) an attempt to introduce new and improved ones – this can have almost a totemic quality, as if by simply adhering to ISO 9000 / Agile / ITIL / RAD (delete as appropriate) things will miraculously turn around.

Unfortunately both of these extremes are essentially displacement activities. I have led the turn-around of a number of IT teams. In my experience, what is generally required is a heavy dose of pragmatism and a focus on doing the basics well and without any elaboration whatsoever. It is nearly always best to try to fix the existing machine, or at most to tinker with it slightly in the first instance, rather than to make drastic modifications or try to build a new machine in entirety.

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

When IT is under-performing it is not normally a case of absent or ill-adhered to formal procedures. Rather the malaise is more likely to be a human one, relating to a lack of leadership and direction, a consequent lack of motivation and a group that begins to spiral in on itself. If the problem is essentially with people, then the solution often lies with them as well. It is not easy to motivate demotivated people, it is not easy to provide direction to those who are lost. However both of these things are easier to do than relying on the same lost and demotivated people to either make lighting fast redemptive deliveries, or to cheerfully adopt a new and fool-proof development methodology.

If a formal methodology is important – and it generally is – then my recommendation is to implement this once you have put a lot of effort into creating a happier and better functioning IT team. It is a bit like the old adage about not outsourcing a problem. Best practice instead is to resolve the issues and only then outsource a functioning process.

It is worth also saying that, as well as being more effective, working to make your team happier and more functional is a lot more rewarding and a lot more fun. If you achieve this it is amazing how much more easily the successful system deliveries start to flow.
 
 
Coda

In business, as in rock climbing, if you try to run before you can walk, try to jump to the desired end-state without putting in the necessary hard work, then you are only likely to get hurt. If you don’t believe me, I can tell you all about my finger injury again.
 

Is the time ripe for appointing a Chief Business Intelligence Officer?

linkedin Business Intelligence Business Intelligence

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

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

The Office of the CBIO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

An in-depth interview with the author – by Ajay Ohri at DecisionStats.com

DecisionStats

I have been following DecisionStat’s excellent series of interviews with leading figures in the IT industry who have a focus on Business Intelligence, Analytics and Data Management. So I was delighted when I received the invitation to be interviewed by Ajay myself.

This turned into a wide-ranging discussion on a number of areas including the perception of science in society, but most of the content refers to Business Intelligence, analytics, cloud computing, data quality and related areas. You can read the interview in full by clicking on the image or text below.

DecisionStats.com Interview

DecisionStats.com Interview

Thanks to Ajay for taking the time to talk to me.
 


 
Ajay Ohri established DecisionStats in 2007 to focus on a number of areas pertinent to business an technology. These include: India, The Internet, Analytics, Company Analysis and Interviews. Ajay is also principal of SwanPLC, who are in the business of helping customers with advanced analytical solutions including recommendations of products and services.