Please click on the image to view the full-sized invitation
Some time ago I posted about about the IT Director Forum that I was helping Chase Zander to set up. This is happening on the evening of March 26th in Birmingham, England.
Seminar topics:
People who should attend:
How Business and IT be better aligned?
How IT can add more value while being more cost effective?
IT Directors
Managing Directors
Senior Business-Facing IT Professionals
A summary of the research that led to developing these topics may be viewed here.
Rather than just making presentations, the objective is to have round-table discussions with delegates sharing their experiences. I will be facilitating the IT / Business Alignment session and Elliott Limb will be handling the Adding value with IT session. Elliott is an IT and Business Leader and Author of forthcoming book Credibility – Bridging the IT / business divide.
At present, there are a few places still available. Any UK-based IT managers who are interested in attending can contact Emily White (emily.white@chasezander.com or 0870 997 9014) to make a reservation.
Having yesterday been somewhat disparaging about the efforts of others to delineate the reasons for BI projects failing, I realised that I had recently put together just such a list myself. By way of context, this was in response to being asked for some feedback in a subject area where I had little expertise and experience. Instead of bailing out of answering, I put together a more general response, a lightly edited and mildly expanded version of which appears below.
Please note that there is no claim on my part that this list is exhaustive; in common with all humans, us IT types can be very creative in finding new ways to fail, I am sure there are some out there that I have not come across yet.
The objectives of the project not being clear. By this I mean the business objectives. There are two layers of problems, the actual business issues may not be understood well enough to form an effective response and, if the business knows what it needs to do in general terms, IT may not fully appreciate this for a number of reasons (mostly down to lack of communication) or may be unable to translate this into a suitable programme of work (possibly because of a lack of knowledge of how the business operates). Where IT is not part of the senior management team, or sees itself as a department apart, this issue is more likely to occur.
Strategy formation being skipped. If you don’t understand what a project is meant to be about, it is difficult (to say the least) to form a strategy. However, if the test in point 1. is passed, then it may be tempting (or there may be pressure applied) to get to the end game as soon as possible without either forming a strategy for the project, or fitting this into both over-arching business and IT strategies (which one fervently hopes are complementary). As I know all too well, the strategy formation step can be tough one and people may sometimes be keen to skip it. The current economic climate may lead to this happening more frequently and my opinion is that this will be storing up trouble for the future.
Fragmented systems’ landscapes. Related to the above, it is often very difficult to make progress when there is a patchwork of different systems and approaches throughout an organisation and little desire to address this short-coming. Often some sort of revolution (albeit sometimes a quiet one sustained over many years) is required to move forward. Sometimes this requires some crisis, internal or external, as virtually every organisation is inherently conservative; no matter what their marketing spiel may claim to the contrary.
Lack of Change Management. Projects often also have an organisational change aspect (what else are they for?) and the problems here are: a) people do not like change and resist it; and b) many otherwise able managers are not experienced in change – indeed we tend to educate most managers to be efficient in a steady-state environment. Even when this aspect is recognised, it is often underestimated and work does not start until too late in the game.
People. Aside from these, the main other problem is people. Projects, even small ones, are difficult and not everyone is up to running them. Simple errors in execution can derail projects that otherwise tick all of the boxes.
Of course any passing Gartner analyst is more than welcome to rip this to shreds if they see fit.
In order to understand the flow of information, CIOs need to be intimately familiar with the direction of the business. This way, they can automate pieces of that business where it will do the most good. That can’t be done without a good understanding of how information moves through an organization, and the movement of information can’t be fully understood without understanding the business units.
It will come as no surprise to anyone who has read my earlier article about spurious distinctions between business and IT (Business is from Mars and IT is from Venus) that I strongly endorse this sentiment. Maybe the fact that mainstream commentators are talking about IT in business terms is indicative of IT beginning to come of age.
Ed Sperling is editor in chief of System-Level Design; and a contributing writer at Forbes.com.
I am again indebted to a question raised on the LinkedIn.comBusiness Intelligence Professionals group for this article. The specific thread may be viewed here and the question was the beguilingly simple “How to understand BI requirements in an organisation?”
[A note here, in common with many US-based companies, “international” means all non-US markets; in my case: Asia Pacific, Europe, Canada and Latin America. By way of contrast “global” means international plus the US domestic market, i.e. all operations.]
By way of providing some context, in previous years I had successfully built and deployed an Information Architecture for the European operations of a multinational Insurance organisation and extended components of this to our Latin American subsidiaries. I had also deployed the same corporation’s financial system to its Asia Pacific business. My track-record in adding value through BI and my exposure to two major projects in the international arena led to me being asked to build on the European technology assets to develop a management information strategy for the four international regions. This article is about how I succeeded in doing this.
Consistent with the general approach that I laid out in an earlier article, my two first objectives were to understand the needs of the various business groups across the four international regions and to form a high-level picture of the IT architecture in these areas. Although I pursued these twin goals in tandem, it was the business piece that I placed most emphasis on initially. It is this area that I will have most to say about here.
Understanding the business
The way that I approached my goal of learning about the international business was not novel in any aspect except possibly its scale. As you would expect, I did it by speaking to business managers from different countries and business units in each of Asia Pacific, Canada, Europe (I revisited the European requirements to make sure I was not neglecting these), Latin America and people with international or global responsibilities.
The countries whose MI requirements I had to establish
Some of these interviews were face-to-face, but – given the geographic spread of my correspondents – the bulk of them were over the ‘phone. The many time-zones involved provided another challenge. I am based in the UK and it was not atypical to be on the ‘phone talking to Australia or Singapore at 6am my time; pick up on some European meetings during the morning; talk to Canada, Latin America and the US parent during the afternoon and evening; and be back on the ‘phone to Australia at midnight. There were a lot of these 14-hour plus days!
One thing that I was surprised by in the process was how well it worked being on the ‘phone. Although I sometimes find it a lot easier to be speaking in person, being able to pick up on visual cues and so one, using the telephone both allowed me to listen vary carefully to what was being said and to take detailed notes; it is tough taking detailed notes while maintaining eye-contact of course. I structured the interviews to explore the following areas:
An overview of the manager’s markets, products, structure, strategy, growth areas and any pressing business challenges
Their thoughts on the general IT infrastructure available to them; looking beyond what some people might view as the world of management information
The extent and quality of their current MI, including local and corporate reporting systems and even any Access databases and spread-sheets; here I placed particular emphasis on any major gaps
What their vision was for improved MI facilities; an ideal state for MI if you will
This proved to be a successful approach and I learnt a remarkable amount about the differences between countries and markets. I normally allowed 30 minutes for these calls, suggesting in my introductory e-mail that if people were pressed for time, 15 might suffice. No call was ever less than half-an-hour long, most of them expanded to be an hour or more, such was the interest generated by my line of questioning.
The scale of the work
I had initially targeted speaking to around 40-50 managers, but quickly came to realise that – given the diversity of the organisation’s operations – I would need to talk to more people to get an accurate picture. As things worked out, I ended up interviewing precisely 100 managers. I started to try to describe the range of people that I talked to and quickly came to the conclusion that a picture paints a thousand words. The following exhibit provides a breakdown by geographic span of responsibility and area of the business:
The distribution of managers that I interviewed
The paper covering their detailed feedback from this exercise expanded to over 400 pages; each line of which was reviewed, sometimes amended, and signed-off by the people interviewed. Such a sign-off process certainly increases the duration of the work, but it is indispensable in my opinion. If you are inaccurate or incomplete in your understanding of the business, then you are building on foundations of sand. Of course, as well as using this exhaustive process to document business requirements, it was also a great opportunity to begin to establish relationships and also to gently start the process of marketing some of my ideas about MI.
It is clearly inappropriate for me to share my detailed findings about the business issues that the organisation was dealing with, however I will make one observation, which I think is probably replicated in many companies. When I spoke to managers at different levels within the organisation, they all cited similar strategies, challenges and priorities. This fact was testament to good communication between different tiers, however widely separated by geography, and also to a shared sense of purpose. What was however notable was that people at different levels gave varying emphasis to the issues. If a global leader prioritised areas as 1-2-3-4, it was not unusual that a manager at the country level instead ranked the same areas as 1-4-3-2. Perhaps this is not so surprising.
Understanding the systems
In parallel I also worked with the CIOs of each region and with members of their departments to understand the systems that different business units used and how they were interrelated. In doing this, it was helpful to already have the business perspective on these systems and I was able to provide general feedback about IT in each territory which was valuable to my colleagues. In this type of work (as indeed can be the case when thinking about different markets and products from the business perspective) it is sometimes easy to be overwhelmed by the differences. Instead, I made myself focus on teasing out the similarities. There ended up being many more of these that I had anticipated. In this work I relied to a great extent on my experience of consolidating data from three different underwriting systems (plus many other back-end systems) as part of my previous work in Europe.
Forming and validating a strategy
With this substantial background in both the business needs and the IT landscape, I was able to develop a management information strategy that focused on what was held in common across business units and departments, whilst still recognising the need to meet certain market-specific requirements. The lengthy hours of research that I had put in proved to be worthwhile when I presented my ideas back to many of the same group that I had interviewed and received their backing and approval.
Some final thoughts
While it was undeniably interesting and even fun to learn so much about the diverse operations of a large international organisation, the process was undeniably lengthy sometimes even arduous. It took six months from conception of the project to delivering detailed findings, recommendations and plans to the international senior management team (of course I also presented interim findings and draft recommendations several times over this period).
It remains my firm belief that this type of exercise is mandatory if you are really serious about adding value with BI. I can see no way to short-cut the process without substantially compromising on your deliverables and the value that they are intended to unlock. If you do not understand the business and its needs, it is nigh on impossible to deliver the information that they require to take decisions. In some areas of life, you just have to put in the hard work. Establishing the requirements for BI in a large international organisation is certainly one of these areas.
I am collaborating with Chase Zander to set up an IT Directors’ Forum for later in the year. Rather than focussing on technology issues, our idea is to focus on the nexus between IT and business, something that I am obviously interested in given my background.
In the IT and change projects I have led, I always prided myself on going an extra mile to understand user requirements. One way in which the group of us organising the seminar is trying to get such user feedback is from LinkedIn.com and specifically the CIO Magazine group (you will need to be a member of LinkedIn.com and the group to view this).
The question that I posed there is as follows: –
I’m looking for business-focussed topics for a CIO / IT Director forum that I am helping to arrange. I would be very interested in what areas are at the top of people’s priority lists.
The forum is for senior IT people, but it is not going to be focussed on technology (there are enough SOA seminars out there already). Instead possible areas would include:
Managing the ever increasing pace of business change
IT / Business alignment; IT Governance / prioritisation
Managing IT in the current economic climate
The interplay between IT strategy and shorter-term tactics
Increasing the influence of IT at the board level.
Of course some of these overlap. The seminar is meant to be a forum for discussion between delegates, not just presentations. If you were to go to such an event, what topics would you like to discuss? Thank you in advance for your help.
Peter
There has been a lot of very interesting feedback to this question, showing once more how helpful the on-line community can be in addressing issues.
UPDATE: The results of this survey are now available and may be viewed here.
This article is the second of two focused on problems arising from the IT cycle. The first piece, which may be viewed here, talked about what can sometimes be the unfortunate aftermath of a successful IT project; the team seeking new work rather than the allocation of resources to the most pressing business needs. As previously explored, the problem is basically one of human nature and therefore addressing it is not straightforward. However here I make some suggestions that could possibly help.
It is not possible to totally “solve” the problem of the IT cycle; however there are some steps which can be taken which can reduce its impact. Happily, several of these are also positive for the organisation in their own right.
The Basic Problem
1. Communicate better about projects
A prerequisite to not building up monolithic, inflexible IT departments is awareness of opportunities elsewhere in the organisation. Where people have some perspective of other current and future projects, they may see opportunities for advancing themselves which, in turn, can provide opportunities to mitigate the IT Cycle problem.
2. Use similar technologies / development methodologies
The more similar the approach taken in different teams, the easier it will be for people to migrate between them. Obviously using similar development tools is one area; however it is perhaps even more important that teams adopt similar development methodologies. People can adapt much more quickly to doing the same sort of thing in a different development environment than they can adapt to doing something quite different in the same development environment. Having said this, the best case would clearly be to work in a new team in a similar way and with the same tools.
Different tools will always be needed when, for example, development of reporting and transaction processing systems. Even here, it will be helpful to enhancing flexibility if the same databases are used and if the same terminology is adopted for business objects.
3. Cross train staff
This is pertinent to development environments where these differ between teams. However, even if all teams share a common development tool-set, cross training can give people an appreciation of systems which they did not develop, both their technical architecture and business purpose. This will stand them in good stead should they be required to work on these systems.
Cross training does not have to be extremely time-consuming and extensive in scope. Much could be learnt by 30 – 60 minute seminars held at lunch time. Such work not only prepares staff for changing teams, finding out more about other systems and projects it may also encourage them to consider other roles within IT.
4. Cross train managers
At least of equal importance is making managers aware of what is happening in other teams and how. With the right attitude, such information can be the genesis of a more flexible attitude to staff deployment and career development.
5. Make use of temporary secondment
The nature of IT work (or most other kinds of work if it comes to that) is that what was a priority last year may not be one this year, but may become important again in six or twelve months. This volatility argues for some flexibility in resourcing. If department X has a trough in workload which is anticipated to last six months and department Y has a peak which is also anticipated to last six months, then seconding some of department X’s people to department Y may be an answer (this of course assumes that people’s skills are transportable – see the last two points). Of course the peaks and troughs will not always coincide so conveniently. Nevertheless, secondment can be a tool in both increasing the breadth of knowledge of IT staff and in managing fluctuations in demand for people between different departments.
6. Make appropriate use of contractors
Particularly when there is a focus on expense, contractors are often seen as a bad thing. They cost a lot, they have little commitment to the company, any intellectual capital which they accumulate during an assignment is not retained by the company when they leave, and so on. However some of these criticisms could also be applied to at least a substantial section of permanent staff. Contractors are expensive because they offer specific skills at short notice and do not require much commitment from the company. Replacing contractors with permanent staff reduces our ability to cope with the IT Cycle (though clearly when managers retain contractors beyond their useful life, this contributes to the IT Cycle problem).
The Budget Problem
7. Build IT budgets from the ground up
Rather than starting with the existing IT staff in their existing departments, a potential approach might be to assess the priorities for each year and then allocate resources accordingly. This might introduce a note of instability to IT, but this could be managed and the process would also better reflect business realities.
8. Rank projects by business benefit
If the above is not practicable, it would still be beneficial to rank the business benefits of projects undertaken by different departments. The difference here is that the assessment comes after budget submission, rather than before. However the results might be somewhat similar. If one department’s new projects all ranked lowly, then thought should be given to reallocating some of their staff to higher priorities.
9. Have departmental IT budgets vetted in detail by other IT managers
It is difficult and time-consuming for non-IT people to assess the intricacies of projects. However IT professionals are familiar with these. A review of an IT department’s budget by an IT manager who is not part of that department can improve the likelihood of the budget being closely aligned with business value. This need not be an adversarial process if seen as a method by which to enhance the quality of the budget.
The “Latest and Greatest” Problem
10. Identify what new technologies are most applicable to the organisation
As well as exciting IT professionals, the “latest and greatest” technologies may often have solid business benefits. However the state of the art in IT moves forward so fast and in so many simultaneous directions that it would be nigh on impossible to keep apprised of all of them. A better starting point might be to assess what capabilities are the basis of an organisation (e.g. an organisation might decide that the expertise of its staff and the quality of the relationships with its customers are fundamental) and then investigate what technologies best support this. This can lead to a good alignment between employing newer technologies (happy IT people) and focused business benefit (happy profit centre managers).
11. Be prepared to let some people go
Ultimately, if people want to be into the latest cool thing then sometimes we will have to let them go a do that elsewhere. It is better to try to build a culture where success rather than use of “cool stuff” is important. IT staff with a strong appreciation of the organisations business and how to support it will ultimately be a more valuable resource than a group of talented technicians.
A General Suggestion
The above problems are all essentially managerial in nature. The final strategy addresses this head on and is perhaps a prerequisite for progress on the other ideas.
12. Provide incentives to IT Managers who effectively manage staff numbers
People are after all human and nothing helps quite so much in aligning the goals of the corporation and the individual as targeted incentives. Such incentives can be direct (e.g. bonuses for re-deploying staff) or indirect (e.g. annual objectives including one pertinent to this area or the manager’s attitude to effective use of resource being a criteria for advancement).
If an organisation is suffering from the problems inherent in the IT cycle, then I would recommend this final step as the first one to take.
This article examines an area that is often one of some debate in both IT and business circles; namely issues pertaining to the size of IT teams, the length of IT projects and the ongoing expense associated with both. Here I will attempt to analyse problems associated with the nature of IT work and IT management and to identify the underlying reasons for these. In a forthcoming article I will offer some ideas about how a more flexible approach could lead to more efficient deployment of IT resources and thereby enhanced business value.
The IT cycle
Figure 1 - The IT Cycle
Systems’ development is inherently a cyclical activity. An example of a typical cycle appears in the above diagram. The solid line, bordering the blue area, shows how resource is built up over time in order to develop an application meeting a business need and then requirements for resource fall as the system stabilises and moves into maintenance mode. There are a number of distinct stages: –
The above may be seen as a somewhat idealised – and certainly simplified – view of a project. For example, a project may have more than one phase, the first could roll out basic functionality, the second enhance this with less time-critical (but none-the-less important) functionality, the third could extend use of the system to other business areas or locations. In these cases, the point at which the project first goes live is not the beginning of reducing staff numbers. Instead at this point two teams are needed, the first to support the live, phase one system, the second to continue to build phase two. This would frequently lead to a resource increase at this stage.
Also by the time that the system is deployed, business focus may have changed, leading to substantial requirements for modification or enhancement. This is essentially the same model as phased delivery of fixed requirements, it is just that the planning of the overall project is more fluid.
Nevertheless, such refinements of the model do not change the basic message. At some point (possibly extended by planned or unplanned phased deliveries), the system will meet the majority of the business requirements and new development activity will offer diminishing returns. At this point, the system needs to be put into maintenance mode and less staff will be required. This is the essence of the IT cycle.
I will now consider some problems that the IT cycle can lead to.
The Basic Problem
Having reviewed some aspects of the IT cycle and explained how this applies to all systems development, regardless of how extended this might be, we can now focus on the basic problem that this model presents.
This basic problem can be seen as one of inertia – the tendency of things to persist in their current state unless impacted by some external force.
Over the first three stages of the IT cycle, focus has been on developing a strategy, building a team to execute it and then realising the vision. Anyone who has been involved in this process will attest to the collective pride and comradeship that develops with the team. A feeling of “us against the world” can take hold, followed by an immense sense of joint achievement when a system is successful. People often also grow through such a process, junior analyst/programmers become senior analyst/programmers. Designers become more experienced. Project managers become battle-hardened. As a result of this, at the beginning of what would be the maintenance phase, the IT organisation is left with a group of people who are creative, successful, focussed on development rather than support and have the mindset of wanting more challenges. Such people have a high value in the market and are more than aware of this.
Therefore, the IT organisation has both a challenge and an opportunity. The successful project has resulted in more experienced and able people being available, but where will their next challenge come from? This situation can be addressed in two ways. The former is harder to achieve and less often practiced, the latter is the path of least resistance and more prevalent than many IT managers would like to admit.
Option A – Assess what the current, pressing business priorities for IT are and devote the best people from the completed project to these.
It is likely that there is more than one area to which they could contribute. Maybe they will be able to take on a more senior position in their next project. This option is not as easy to achieve as it might seem. Consider two projects, X and Y. The former has been very successful but is going into maintenance mode and requires less staff. The latter represents a current business priority. Assuming the goodwill of the managers of both projects, potential obstacles to behaving this was would still include: –
•
people in Project X have different technical skills to those in Project Y and so cannot simply transfer and start work immediately
•
people in project X may have a different way of working from those in project Y – this may present cultural difficulties which are disruptive to both new starters and existing staff in Project Y
However, because it is a very positive outcome, I will devote some time to how the obstacles to this option can be negotiated in a later article.
Option B – Try to find more work for the existing project team to do in the same area.
It is a lot simpler to take this approach. People often appreciate continuity more than new challenges. It is generally the case that there will be more work which can be done, the question is rather the value of this work compared to what the same resource could be doing in other areas.
There are some very human factors that can reinforce this approach: –
•
managerial prestige (or, less kindly, empire building)
•
rewards and progression being seen as tied to managing bigger and bigger teams
•
job security of the management of the project moving into maintenance mode
•
lack of appropriate positions for staff elsewhere in the organisation
•
the effort involved in building the project team being seen as wasted if it is “broken-up”
•
the desire not to fire staff, particularly those who have served the company well and just completed a major project successfully
•
business sponsors wanting to retain “their staff” anticipating further work at some future stage
•
“rewarding” past work with more work
The combination of these factors can modify our resource graph to look more like Figure 2 below.
Figure 2 - The problem with the IT Cycle
Here, when the project has notionally reached the maintenance stage, resource does not reduce and may indeed continue to grow. The red area demonstrates the difference between actual staff numbers and what the IT cycle model would predict. This may be seen as excess resource, or perhaps as a loss in productivity in IT. If, instead, this excess resource can be re-deployed, we have an opportunity to increase the overall effectiveness of the IT organisation.
The Budget Problem
The normal budget process can exacerbate this phenomenon. Often the manager of an IT department will start with their existing budget plus wage inflation as a base line. Anticipating future cuts, they may increase this by say 20%. What then follows is a turf war with each IT manager trying to hold on to their budget. While there is no incentive for any given manager to take a more flexible approach, such behaviour is rational and will continue. Of course it should be stressed that IT is not the only area to suffer from this type of problem.
The “Latest and Greatest” Problem
On top of this we can add some attributes of IT staff which, although generally desirable, can have a downside as well. Many IT people want to be involved in the latest and greatest technology – this is not always what is going to add most value to the business. Sometimes, in order to retain the best people, IT management can give in to this trait. At the positive end of the potential results, this can lead to happy staff and greatly enhanced systems. At the negative end are projects to re-write systems in new technology for little reason other than the staff would like to do this and may leave if they do not get the opportunity.
There is no right answer here, what might be seen as indulging IT staff’s whims may actually be the hard-headed, practical thing to do in some circumstances. What is most important is to achieve an appropriate balance between the need to retrain and motivate the best staff and the need to align work to business priorities.
So there are a number of problems facing IT in this area. However I believe that they are all tractable and I will offer some ideas for addressing each problem in a future article.
This article was prompted to some extent by a discussion posted in the Enterprise Performance Management group on LinkedIn.com (the thread may be viewed here, but you will need to be both logged on to LinkedIn.com and a member of the group to view it).
The economic turmoil encompassing much of the world is certainly being felt in IT. As one of the largest areas of expenditure in an organisation, IT is always somewhere where it is tempting for those looking to make cuts to start. In many organisations, IT expenditure has been under pressure for many years as rising software costs have taken a larger chunk of overall expenditure. Replacement of obsolete hardware and software is also something that cannot be put off indefinitely and such work often further reduces the CIO’s room for manoeuvre. These factors tend to lead to either stagnant or reducing IT budgets. In some organisations, cuts are “democratically” spread across all areas of IT, but the more sophisticated operators will look to be selective. In this second type of organisation, it has been suggested that business intelligence (BI) may be one of the winners. This article explores this idea.
It is first of all important to realise that sometimes investment in BI is driven by a crisis. When things are going wrong, or have already gone wrong, then the instinctive reflex of CEOs is to want to know both what is happening and why. Often they will find that they do not have the tools in place to answer either of these questions and BI is the best way of addressing this need. In relation to the credit crunch, this type of BI investment can be thought of in the same way that greater focus was placed on control systems and internal auditing in the aftermath of the Enron and WorldCom debacles (they now seem a lifetime away don’t they?).
However, there are some things to be said against this. First, the current crisis is not within a single company, but across virtually all companies. Second, the factors behind the crisis are already apparent: a drying-up of commercial credit as banks do a 180° in their appetite for risk and seek to rebuild devastated balance sheets; and, proceeding from the first factor, a plunge in consumer and business confidence as individuals and companies face – at best – straitened financial circumstances and – at worst – insolvency. Of course the combination of these issues leads to a vicious circle. Good BI is not necessary to qualify these already crystal-clear problems.
Despite the systemic nature of the challenges, companies that have already made investments in BI will have tools at their disposal that are pertinent to navigating some aspects of the current financial difficulties. This should place them at a competitive advantage to organisations that have not been so foresighted. As ever corporate discomfort will not be spread evenly across the board. Whilst all companies will suffer, the strongest ones will suffer least. These organisations may even be able to take advantage of their competitors’ travails to expand market share and attract disaffected customers. One thing that will undoubtedly be a feature of the strongest companies is good BI. These observations may be enough to drive continued support of BI in organisations that already value it, they may even lead to a mild expansion in facilities. But what can we say about those companies that have not already invested in BI?
It is undeniable that creating good BI from scratch is both a lengthy and costly process. I would argue that – in normal circumstances – the payback is extremely positive; indeed BI is one of the highest-yielding types of IT projects. The challenge is that the financial crisis is biting deeply now and BI’s benefits are in the future; at least a year away for most organisations (though it is feasible that some interim solutions to the most pressing questions could be produced more rapidly). Is this a time at which senior management is likely to be receptive to an investment with a medium-to-long term payback, no matter how large that payback might be? The answer to this question probably lies in the degree to which the external crisis has been reflected in an internal crisis. If a company is fighting for its survival day-to-day, then existing BI will be invaluable, but BI with a delivery date in 12 months time is not likely to get very far up the priority list; paying suppliers and staff in the next few days is a more pressing issue.
So my opinion is that there is scope for expanded BI expenditure in those companies that have already made investments, this may be related to specific tools to help take advantage of customers deserting distressed competitors. There is also scope for BI projects to be initiated in companies that are suffering, but whose business is essentially sound. In these types of businesses decisions can still be taken with an eye on the medium term. However a balancing factor is that companies whose future is in the balance are very unlikely to see BI as a major contributor to any short-term turn-around strategy. In these organisations, slashing all IT expenditure is more likely to be the prevailing wisdom.
In aggregate it is difficult to work out the impact of these different trends on the BI market. This will depend sensitively on the triage of companies into the groups identified above. My unscientific sense is that BI may fare marginally better than many other elements of IT, but the overall outlook is negative in the short-term. However, for those companies that survive the down-turn and have not already put a BI strategy in place, it may well be that the area will see renewed interest once the economy reaches calmer waters. This realisation may well arise from noticing how much better those companies with good BI have fared in difficult market conditions.
Since writing this article, I have penned some others in the same area and also found a number of interesting pieces elsewhere on the web. In response to this I have created a WordPress category “BI and the Economic Crisis“, which will hopefully provide a hub for this important area.
Chase Zander were kind enough to invite me to their recent Change Director Forum, which took place on 11th November 2008 in London. As per their web-site: –
The event focused on IT-Enabled Change and sparked an interesting debate from the floor into the issues facing change programmes and projects which often rely heavily on the introduction of new information technology.
Some related items began to spark ideas in my mind: –
First, one of the speakers, Dr. Sharm Manwani from Henley Business School, referred to a survey of senior IT managers which asked them about areas in which they felt a lack of skill might be reducing their effectiveness. The area that came out as most important was “interpersonal skills”. Many people also said that they lacked in-depth knowledge of their organisation’s business, but this was not seen as a major problem by respondents.
Second, during what proved to be a lively debate, many attendees made reference to “IT” and “the business” in the way that one might juxtapose Muhammad Ali and Joe Frazier. This is a common refrain whenever IT managers are gathered together. Often a key issue is whether IT or the business (again that juxtaposition) should own projects, or strategy development, or technology budgets.
Third, Dr Manwani, in what was an illuminating talk, presented a chart which featured “in between” roles such as “business solutions manager” or “programme manager” which are intended to form a bridge between IT and the business. He also questioned whether there might be better ways to bring business and IT together.
To my way of thinking, if you need to form a bridge between IT and the business, then you are already facing a major problem. Even in today’s web-enabled, always-connected world, it appears to be acceptable for IT and business to be viewed as something separate: Business is from Mars and IT is from Venus. It is OK for business leaders to express a lack of knowledge about IT and for IT leaders to express a lack of knowledge about business; in some organisations it may even be a badge of honour for both “sides”. The word “sides” appears in inverted commas intentionally; this world view is a major part of the problem in my opinion.
Maybe I was just lucky enough to spend the formative years of my career in an organisation where IT was the business, but I would argue for a reassessment of the spurious dividing line between IT and business. I believe that IT is a business discipline and that the best IT managers are business managers. They are people who have a particular skill-set that they can bring to business challenges; in this respect they are no different to sales managers, or finance managers or any other manager with a specific hinterland of expertise and experience.
In many ways, it seems that IT managers are happy with the perception that that are somehow different. They may even revel in the mystique of the “dark arts” that they and their department practise. Perhaps being seen as different helps self-esteem. Less positively, in disavowing their full business role, perhaps many IT managers are content to retreat into their speciality. It is maybe comforting to have the middle-men, such as business solutions managers to act as insulation and to take the blame when things go wrong. How often have we all heard IT managers cite poorly defined or shifting business requirements for systems’ failures? How often is the lack of a clearly defined business strategy offered as an excuse for the lack of a clearly defined IT strategy?
I believe that these types of complaints are indicative of a pernicious problem in IT management. It is human to look for others to blame when things go badly, but if IT managers do not properly understand business issues, if they do not become part of the overall business management team and if they allow themselves and their departments to become semi-detached, then they really only have themselves to blame.
So, rather than ending on a negative note, let me repeat my call for IT managers to start to view themselves more as business managers. In embracing the ever increasing tempo of modern business and better understanding the dynamics that drive this, IT managers can both be more effective in their roles and also enjoy themselves much more at the same time. Surely those outcomes merit what is probably not an enormous investment of time and energy.
You must be logged in to post a comment.