Bogorad on the basics of Change Management – TechRepublic

TechRepublic linkedin

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

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

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

Metamorphosis II - Maurits Cornelis Escher (1898 - 1972)

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

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

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

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

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

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

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

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

Other TechRepublic-related articles on this site inlcude: “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic and Ilya Bogorad on Talking Business.
Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya specializes in building better IT organizations and can be reached at or (905) 278 4753. Follow him on Twitter at

Maureen Clarry stresses the need for change skills in business intelligence on BeyeNetwork

The article


Maureen Clarry begins her latest BeyeNETWORK article, Leading Change in Business Intelligence, by stating:

If there was a standard list of core competencies for leaders of business intelligence (BI) initiatives, the ability to manage complex change should be near the top of the list.

I strongly concur with Maureen’s observation and indeed the confluence of BI and change management is a major theme of this blog; as well as the title of one of my articles on the subject. Maureen clearly makes the case that “business intelligence is central to supporting […] organizational changes” and then spends some time on Prosci’s ADKAR model for leading change; bringing this deftly back into the BI sphere. Her closing thoughts are that such a framework can help a lot in driving the success of a BI project.
My reflections

I find it immensely encouraging that an increasing number of BI professionals and consultants are acknowledging the major role that change plays in our industry and in the success of our projects. In fact it is hard to find some one who has run a truly successful BI project without paying a lot of attention to how better information will drive different behaviour – if it fails to do this, then “why bother?” as Maureen succinctly puts it.

Without describing it as anything so grand as a framework, I have put together a trilogy of articles on the subject of driving cultural transformation via BI. These are as follows:

Marketing Change
Education and cultural transformation
Sustaining Cultural Change

However the good news about many BI professionals and consultants embracing change management as a necessary discipline does not seem to have filtered through to all quarters of the IT world. Many people in senior roles still seem to see BI as just another technology area. This observation is born out of the multitude of BI management roles that request an intimate knowledge of specific technology stacks. These tend to make only a passing reference to experience of the industry in question and only very infrequently mention the change management aspects of BI at all.

Of course there are counterexamples, but the main exceptions to this trend seem to be where BI is part of a more business focused area, maybe Strategic Change, or the Change Management Office. Here it would be surprising if change management skills were not stressed. When BI is part of IT it seems that the list of requirements tends to be very technology focussed.

In an earlier article, BI implementations are like icebergs I argued that, in BI projects, the technology – at least in the shape of front-end slice-and-dice tools – is not nearly as important as understanding the key business questions that need to be answered and the data available to answer them with. In “All that glisters is not gold” – some thoughts on dashboards, I made similar points about this aspect of BI technology.

I am not alone in holding these opinions, many of the BI consultants and experienced BI managers that I speak to feel the same way. Given this, why is there the disconnect that I refer to above? It is a reasonable assumption that when a company is looking to set up a new BI department within IT, it is the CIO who sets the tone. Does this lead us inescapably to the the conclusion that many CIOs just don’t get BI?

I hope that this is not the case, but I see increasing evidence that there may be a problem. I suppose the sliver lining to this cloud is that, while such attitudes exist, they will lead to opportunities for more enlightened outfits, such as the one fronted by Maureen Clarry. However it would be even better to see the ideas that Maureen espouses moving into the mainstream thinking of corporate IT.

Maureen Clarry is the Founder and President/CEO of CONNECT: The Knowledge Network, a consulting firm that specializes in helping IT people and organizations to achieve their strategic potential in business. CONNECT was recognized as the 2000 South Metro Denver Small Business of the Year and has been listed in the Top 25 Women-Owned Businesses and the Top 150 Privately Owned Businesses in Colorado. Maureen also participates on the Data Warehousing Advisory Board for The Daniels College of Business at the University of Denver and was recognized by the Denver Business Journal as one of Denver’s Top Women Business Leaders in 2004. She has been on the faculty of The Data Warehousing Institute since 1997, has spoken at numerous other seminars, and has published several articles and white papers. Maureen regularly consults and teaches on organizational and leadership issues related to information technology, business intelligence and business.

Recipes for success?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Charles Darwin

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

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

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

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

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

Continue reading about this area in: Synthesis.

The Dictatorship of the Analysts

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

CIO Magazine

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

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

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

  1. Data Warehouse (DW)—companies need a place for data to reside and rules on how the data should be structured.
  2. Business Intelligence—companies need a way to slice and dice the data and generate reports.
  3. Analytics—companies need to extract the data, analyze trends, uncover opportunities, find new customer segments, and so forth.

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

He goes on to say:

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

Current Mindset: DW + BI = Data

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Click to view the introductory presentation
Click to view the introductory presentation as a PDF

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

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

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

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

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

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

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

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

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

The Top Business Issues facing CIOs / IT Directors – Results

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

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

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

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

  Issue % of Votes  

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

  Total 100%  

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

Some reasons why IT projects fail

© Alex Messenger -
© Alex Messenger -

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

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

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

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