This Chase Zander seminar, which I earlier previewed on this site, took place yesterday evening in Birmingham. There was a full house of 20 plus IT Directors, CIOs and other senior IT managers who all engaged fully in some very stimulating and lively discussions.
As I previously mentioned, our intention in this meeting was to encourage debate and sharing of experiences and best practice between the delegates. My role was to faciliate the first session, focussed on IT-Business alignment. I started by sharing a few slides with that group that explained the research we had conducted to determine the content of the forum.
Click to view the introductory presentation as a PDF
After sharing what in my opinion was a not wholly satisfactory definition of IT-Business alignment, I opened up the floor to a discussion of what IT-Business alignment actually was and why it mattered. We used some of the other slides later in the meeting, but most of the rest of the evening was devoted to interaction between the delegates. Indeed the ensuing conversations were so wide ranging that the theme was also carried over to the second session, hosted by my associate Elliot Limb.
Territory initially covered included the suggestion that IT should be an integral part of the business, rather than a separate entity aligned to it (a theme that I covered in my earlier article Business is from Mars and IT is from Venus, which interestingly I penned after a previous Chase Zander forum, this one focussed on change management). The group also made a strong connection between IT-Business alignment and trust. A count of hands in response to the question “do you feel that you have the 100% unqualified confidence of your CEO?” revealed a mixed response and we tried to learn from the experiences of those who responded positively.
The relationship between IT and change was also debated. Some felt that IT, with its experience of project-based work, was ideally placed to drive change in organisations. Others believed that change should be a business function, with IT sticking to its more traditional role. Different organisations were in different places with respect to this issue – one attendee had indeed seen his current organisation take both approaches in the recent past. It was also agreed that there were different types of change: positive change in reaction to some threat or opportunity and the less positive change for change’s sake that can sometimes affect organisations.
Suggestions for enhancing IT-Business alignment included: being very transparent about IT service level agreements and trends in them; focussing more on relationships with senior managers, the CEO and CFO in particular; better calculating the cost of IT activities (including business resource) and using this to prioritise and even directly charge for IT services; applying marketing techniques to IT; learning to better manage business expectations, taking on more realistic workloads and knowing when to say ‘no’; and paying more attention to business processes, particularly via capability maturity modelling.
It was agreed that it generally took quite some time to establish trust between a CIO and the rest of the senior management team. This might be done by initially sorting out problems on the delivery and support side and, only once confidence had been built up, would the CIO be able to focus more on strategic and high value-added activities. This process was not always aided by the not atypical 3-5 year tenure of CIOs.
Later discussions also touched on whether CIOs would generally expect (or want to) become CEOs and, if not, why was this the case. The perspective of both the delegates and the Chase Zander staff was very interesting on this point. There was a degree of consensus formed around the statement that IT people liked taking on challenging problems, sorting them out and then moving on to the next one. While there was some overlap between this perspective and the role of a CEO in both having their hand on the tiller of an organisation and challenging the management team to meet stretch goals, there was less than a perfect fit. Maybe this factor indicated something of a different mindset in many IT professionals.
In the context of forming better relationships with business managers and IT trying to be less transactional in its dealings with other areas, the question of why there were so few women in senior IT positions also came up. This is a large topic that could spawn an entire forum in its own right.
Overall the meeting was judged to be a success. From my perspective it was also interesting to meet a good cross-section of IT professionals working in different industries and to talk about both what the different challenges that we faced and what we had in common.
tactics/táktiks/ n.pl.2 a the plans and means adopted in carrying out a scheme or achieving some end. (O.E.D.)
meander/miándər/ n.1 a a curve in a winding river etc. b a crooked or winding path or passage. (O.E.D.)
I was reminded of the expression “tactical meandering”, which I used to use quite a bit, by a thread on the LinkedIn.com Business Intelligence Group forum. The title of this was Is BI recession-proof? (as always, you need to be a member of both LinkedIn.com and the group to view this).
The conversation on the thread turned to the fact that, in the current economic climate, there may be less focus on major, strategic BI initiatives and more on quick, tactical ones that address urgent business needs.
My take on this is that it is a perfectly respectable approach, indeed it is one that works pretty well in my experience regardless of the economic climate. There is however one proviso, that the short-term work is carried out with one eye on a vision of what the future BI landscape will look like. Of course this assumes that you have developed such a vision in the first place, but if you haven’t why are you talking about business intelligence when report writing is probably what you are engaged in (regardless of how fancy the tools may be that you are using to deliver these).
I talked about this specific area extensively in my earlier article, Holistic vs Incremental approaches to BI and also offered some more general thoughts in Vision vs Pragmatism. In keeping with the latter piece, and although the initial discussions referred to above related to BI, I wanted to use this article to expand the scope to some other sorts of IT projects (and maybe to some non-IT projects as well).
Some might argue (as people did on the LinkedIn.com thread) that all tactical work has to be 100% complementary to you strategic efforts. I would not be so absolute. To me you can wander quite some way from your central goals if it makes sense to do so in order to meet pressing business requirements in a timely and cost-effective manner. The issue is not so much how far you diverge from your established medium-term objectives, but that you always bear these in mind in your work. Doing something that is totally incompatible with your strategic work and even detracts from it may not be sensible (though it may sometimes still be necessary), but delivering value by being responsive to current priorities demonstrates your flexibility and business acumen; two characteristics that you probably want people to associate with you and your team.
Tactical meandering sums up the approach pretty well in my opinion. A river can wander a long way from a line drawn from its source to its mouth. Sometimes it can bend a long way back on itself in order to negotiate some obstacle. However, the ultimate destination is set and progress towards it continues, even if this is sometimes tortuous.
Oxbow Lake Formation
Expanding on the geographic analogy, sometimes meanders become so extreme that the river joins back to its main course, cutting off the loop and leaving an oxbow lake on one side. This is something that you will need to countenance in your projects. Sometimes an approach, or a technology, or a system was efficacious at a point in time but now needs to be dropped, allowing the project to move on. These eventualities are probably inevitable and the important thing is to flag up their likelihood in advance and to communicate clearly when they occur.
My experience is that, if you keep you strategic direction in mind, the sum of a number of tactical meanders can advance you quite some way towards your goals; importantly adding value at each step. The quickest path from A to B is not always a straight line.
Insurance – specifically Property Casualty Insurance – is the industry that I have worked within for the last twelve years. During this time, I managed teams spanning IT, Finance and Operations. However the successes that I am most proud of have been in the related fields of Business Intelligence and Cultural Transformation that appear in the title of this blog.
Insure/insho′or/ v.tr.1 secure the payment of a sum of money in the event of loss or damage to property, life a person etc. (O.E.D.)
Insurance is all about risk; evaluating risk, transferring risk, reducing risk. The essentials of the industry can be appreciated via a rather colourful fable provided in Success in Insurance (S.R. Diacon and R.L. Carter). This tale was originally told by someone at The Association of British Insurers:
Once upon a time there were 11 men; each of them owned a pig.
Unexpectedly one of the pigs died. The owner could not afford £90 for a new pig and so he had to leave the country and go to work in the town instead. The remaining 10 men went to see a wise man. ‘It could happen to any of us,’ they said. ‘What can we do?’
‘Could you each afford £10 for a new pig if your pig died?’ asked the wise man. They all agreed that they could manage that. ‘Very well,’ said the wise man. ‘If you each give me £10, I’ll buy you a pig if yours dies this year.’ They all agreed.
That year one pig did die. The price of pigs had gone up to £95 by now, but the wise man replaced the pig, so none of the men suffered and the wise man had £5 left for the trouble and risk he had taken.
Pricing Insurance products
Of course in the above example, there were two crucial factors for the wise man. First the outcome that only one pig actually died; if instead there had been two pig-related fatalities, the perhaps less-wise man would have been out-of-pocket by £90. Second, the related issue of him setting the price of the pig Insurance policy at £10; if it had been set at £9 he would again have suffered a loss. It is clear that it takes a wise man to make accurate predictions about future events and charge accordingly. In essence this is one thing that makes Insurance different to many other areas of business.
If you work in manufacturing, your job will of course have many challenges, but determining how much it costs to make one of your products should not be one of them. The constituent costs are mostly known and relatively easy to add up. They might include things such as: raw materials and parts; factory space and machinery; energy; staff salaries and benefits; marketing and advertising; and distribution. Knowing these amounts, it should be possible to price a product in such a way that revenue from sales normally exceeds costs of production.
In Insurance a very large part of the cost of production is, by definition, not known at the point at which prices are set. This is the amount that will eventually be paid out in claims; how many new pigs will need to be bought in the example above. If you consider areas such as asbestosis, it can immediately be seen that the cost of Insurance policies may be spread over many years or even decades. The only way to predict the eventual costs of an Insurance product with any degree of confidence, and thereby set its price, is to rely upon historical information to make informed predictions about future claims activity.
By itself, this aspect of Insurance places enormous emphasis on the availability of quality information to drive decisions, but there are other aspects of Insurance that reinforce this basic need.
Distribution strategy
In most areas of commerce the issue of how you get your product to market is a very important one. In Insurance, there are a range of questions in this area. Do you work with brokers or direct with customers? Do you partner with a third party – e.g. a bank, a supermarket or an association – to reach their customers?
Even for Insurance companies that mostly or exclusively work with brokers, which brokers? The broker community is diverse ranging from the large multinational brokers; to middle-sized organisations, that are nevertheless players in a given country or line of business; and to small independent brokers, with a given specialism or access to a niche market. Which segment should an Insurance company operate with, or should it deal with all sectors, but in different ways?
The way to determine an effective broker strategy is again through information about how these relationships have performed and in which ways they are trending. Sharing elements of this type of high-quality information with brokers (of course just about the business placed with them) is also a good way to deepen business relationships and positions the Insurer as a company that really understands the risks that it is underwriting.
Changing risks
The changing face of risk
At the beginning of this article I stated that Insurance is all about risk. As in the pig fable, it is about policy holders reducing their risk by transferring this to an Insurance company that pools these with other risks. External factors can impinge on this risk transfer. Hurricane season is is always a time of concern for Insurance companies with US property exposures, but over the last few years we have had our share of weather-related problems in Europe as well. The area of climate change is one that directly impinges upon Insurers and better understanding its potential impact is a major challenge for them.
With markets, companies, supply-chains and even labour becoming more global, Insurance programmes increasingly cover multiple countries and Insurance companies need to be present in more places (generally a policy covering risks in a country has to be written by a company – or subsidiary – based in that country). This means that Insurance professionals can depend less on first-hand experience of risks that may be on the other side of the world and instead need reliable and consistent information about trends in books of business.
The increasingly global aspect of Insurance also brings into focus different legal and regulatory regimes, which both directly impinge on Insurers and change the profile of risks faced by their customers. As we are experiencing in the current economic crisis, legal and regulatory regimes can sometimes change rapidly, altering exposures and impacting on pricing.
The present economic situation affects Insurance in the same ways that it does all companies, but there are also some specific Insurance challenges. First of all, with the value of companies declining in most markets, there is likely to be an uptick in litigation, leading to an increase in claims against Directors and Officers policies. Also falling property values mean that less Insurance is required to cover houses and factories, leading to a contraction in the market. Declining returns in equity and fixed income markets mean that one element of Insurance income – the return on premiums invested in the period between them being received and any claims being paid out – has become much less.
So shifts in climate, legal and regulatory regimes and economic conditions all present challenges in how risk is managed; further stressing the importance of excellent business intelligence in Insurnace.
The Insurance Cycle
If this litany of problems was not enough to convince the reader of the necessity of good information in Insurance, there is one further issue which makes managing all of the above issues even more complex. This is the fact that Insurance is a cyclical industry.
An example of The Insurance Cycle
The above chart (which I put together based on data from Tillinghast) shows the performance of the London Marine Insurance market as a whole between 1985 to 2002. If you picked any other market in any other location, you would get a similar sinusoidal curve, though there might well be phase differences as the cycles for different types of Insurance are not all in lock-step.
To help readers without a background in Insurance, the ratio displayed is essentially a measure of the amount of money going out of an Insurance Company (mostly its operating expenses plus claims) divided by the amount of money coming in (mostly Insurance premiums). This is called the combined ratio. A combined ratio less than 100% broadly indicates a profit and one above 100% broadly indicates a loss.
It may be seen that the London Marine market as a whole has swung from profit to loss, to profit, to loss and back to profit over these 18 years. This article won’t cover the drivers of this phenomenon in any detail, but one factor is that when profits are being made, more capital is sucked into the market, which increases capacity, drives down costs and eventually erodes profitability. As with many things in life rather than stopping at break-even, this process overshoots resulting in losses and the withdrawal of capital. Prices then rise and profitability returns, starting a new cycle.
Given this environmental background to the Insurance business, it is obvious that it is very important to an Insurance company to work out its whereabouts in the cycle at any time. It is particularly crucial to anticipate turning points because this is when corporate strategies may need to change very rapidly. There may be a great opportunity for defence to change to attack, alternatively a previously expansionary strategy may need to be reined in order to weather a more trying business climate.
In order to make predictions about the future direction of the cycle, there is no substitute for having good information and using this to make sound analyses.
Summary
I hope that the article has managed to convey some of the special challenges faced by Insurance companies and why many of these dramatically increase the value of good business intelligence.
Essentially Insurance is all about making good decisions. Should I underwrite this newly presented risk? Should I renew an existing policy or not? What price should I set for a policy? When should I walk away from business? When should I aggressively expand? All of these decisions are wholly dependent on having high-quality information and because of this business intelligence can have an even greater leverage in Insurance than in other areas of industry.
Given this it is not unreasonable to state in closing that while good information is essential to any organisation, it is the very lifeblood of an Insurance company. My experience is that Business Intelligence offers the best way to meet these pressing business needs.
You can read more about my thoughts on Business Intelligence and Insurance in:
Nigel speaks about issues that he sees related to the consolidation of BI vendors. In his opinion this has led to the big players paying more attention to integrating acquisitions and rationalising product lines instead of focusing on customer needs. In one passage, he says:
Within product development, the main theme moved from innovation to integration. So, instead of delivering previously promised product enhancements to existing customers, product releases came out late and the highlights were the new connections to other products owned by the vendor, but which were probably not used by the existing customers. In other words, product development was driven by the priorities of the vendor, not the customer.
Whilst there is undoubtedly truth in Nigel’s observations, I have a slightly different slant on them, which I offered in my comments:
It is my very strong opinion that what the users of BI need to derive value is not the BI vendors “delivering previously promised product enhancements” but using the already enormously extensive capabilities of their existing BI tools better. BI should not be a technology-driven area, the biggest benefits come from BI departments getting to know their users’ needs better and focusing on these rather than the latest snazzy tool.
If this does happen, it may mean less than brilliant news for the BI vendors’ sales in the short-term, but successful BI implementations are going to be a better advert for them than some snazzy BI n.0 feature. The former is more likely to drive revenues for them in the medium term as companies build on successes and expand the scope of their existing BI systems.
While some people see large potential downsides in the acquisition of such companies as BusinessObjects, Hyperion and Cognos by large, non-BI companies, you could argue that their new owners are the sort of organisations that will aim to use BI to drive real-world business success. Who knows whether they will be successful, but if they are and this is at the expense of technological innovation, then I think that this is a reasonable sacrifice.
As to whose vision of the future is right, I guess only time will tell.
I will be facilitating the Chase Zander IT Director Forum in Birmingham on Thursday evening and am also attending a CIO Magazine event earlier in the week, so there will be rather less blog output than is customary.
Further to my recent article which argued that the building metaphor often applied to IT projects did not work so well for business intelligence, I have dug out a brief piece that I wrote some time ago debunking even the general applicability of the building analogy.
For the avoidance of doubt, this is intended to be a humorous piece, so please do not take it too seriously.
Why IT is not like Civil Engineering
Civil Engineering and IT
“If the automobile industry had developed like the software industry, we would all be driving $25 cars that get 1,000 miles to the gallon…”
~ Bill Gates (allegedly)
“…and if cars were like software, they would crash twice a day for no reason, and when you called for service, they’d tell you to reinstall the engine”
~ Unnamed Detroit Executive (even more allegedly)
It is difficult to draw analogies between different industries as Bill Gates found out (at least apocryphally – he did indeed talk at length about comparisons between the PC and automobile industries at the launch of Windows 98, but probably never made the above quote that is often ascribed to him).
If IT was really like Civil Engineering then, in the spirit of Mr Gates and his Detroit counterpart: –
The concrete, steel and glass used in a office would have be replaced every five years because Lafarge, Mittal and Pilkington no longer support their old products
A year after construction is complete, there would be a requirement to double the size of the 5th, 18th and 34th floors of a skyscraper and to swap the positions of the 1st and 50th floors
The building that had been erected in London, would also now need to be situated simultaneously in Frankfurt and Taipei
It would also often become necessary to have a bridge between the Sydney and Cleveland offices
The factory that was constructed to house an assembly line for dishwashers would need to be adapted to also provide a skateboard park, horse-riding facility and hi-tech laboratory
Occupants of buildings would be unable to use the doors or lifts or look out of the windows without calling the Help Desk or referring to the user guide
IT people are familiar with a number of metaphors for their projects. The most typical relates to building; IT projects are compared to erecting a skyscraper. The IT literature is suffused with language derived from this metaphor. We build systems. We develop blueprints for them. We design architectures (two-for-one there). This analogy has some strength and there are indeed superficial similarities between the two areas. However, as with most metaphors, if over-extended their applicability often breaks down. I recall one CEO in particular who was obsessed by the “building team” moving on to the next “site”; regardless of the current one requiring further work and dedicated maintenance. One of his predecessors often referred to wanting a “diesel submarine” built, as opposed to a “nuclear one”. Before I fall into the same trap of over-exploiting the metaphor, let’s move hurriedly on.
As I mention above, aside from the occasional misapplication, the building analogy works reasonably well for many IT projects; does it also work for business intelligence? I think that there are some problems in applying the metaphor. Building tends to follow a waterfall project plan (as do many IT projects). Of course there may be some iterations, even many of them, but the idea is that the project is made up of discrete base-level tasks whose duration can be estimated with a degree of accuracy. Examples of such a task might include writing a functional specification, developing a specific code module, or performing integration testing between two sub-systems. Adding up all the base-level tasks and the rates of the people involved gets you a cost estimate. Working out the dependencies between the base-level tasks gets you an overall duration estimate.
The problem with BI projects is that some of the base-level tasks are a bit different. An example might be: develop an understanding of a legacy data table, how it relates to other legacy data sets and to more modern systems (this sits under area two of my model of BI development – see BI implementations are like icebergs). This is not an exercise that is very easy to estimate in advance. Indeed it may not be possible to produce an adequate estimate until a substantial amount of work has been done. Even at a late stage in the task, something may be discovered which expands the work required dramatically; surprises may lurk round every corner.
Why is this? Well with legacy data, the people who developed the system may have done so many years ago. Since then, they may have left the company or moved on to other areas, taking their knowledge with them. Their place may have been taken by successive tranches of new staff. Perhaps poor initial documentation meant that later workers did not fully understand the full nature of the system, but nevertheless did their best to build upon it. Perhaps the documentation was good at first, but has not been kept up-to-date and now describes a system that no longer exists.
By definition, legacy systems will have been around for some time and layers of changes will have accumulated on top of each other. Maybe, as a company has expanded, new data has been interfaced to the system from different business units and territories; perhaps each of these cases has its own dedicated interface code, each subtly different from those of other systems. Even where people exist in an organisation who preserve an “oral tradition” about the system, handed down to them over generations; these people may not appreciate how their data interacts with other data – even if the person who looks after another legacy system sits in the adjacent cubicle.
Although these challenges can also occur when trying to understand the data in more modern systems, they are particularly acute with older ones. For a start, the people who designed these systems are more likely to be around. Also legacy systems often sit at the centre of a Byzantine web of inter-connections, batch-processes, over-night jobs and the occasional more modern service. It can be a real mess and this is a situation with which any data analyst with a reasonable amount of experience will be very familiar.
The difficulty of estimating the duration of tasks such as properly analysing legacy data makes overall estimation of BI projects more of an art than a science. Of course techniques such as time-boxing tasks can be applied, but these are not always 100% appropriate. A 75% analysed data source (even assuming that the estimate that only 25% work is left is accurate) is not an analysed data source. Leaving dark corners of knowledge is likely to be reflected in BI cubes and reports that do not reconcile back to their sources. Probably the best way to deal with this problem is to be extremely open about the challenges up-front with executive sponsors and when submitting estimates. It helps to also stress the level of uncertainty in progress reports. The more honest you are initially, the better you will be able to explain any overruns and the more likely it is that you will be believed.
These types of issues mean that the – hopefully more orderly – process of constructing a building is not a fully accurate way to describe a BI project. That is unless the metaphor is extended to include an occurance that is all too common during construction in The City of London. Given the age of Londinium, whenever ground is broken on a new project, it is more likely than not that a mediaeval, Anglo-Saxon or Roman site is unearthed (often all three). These finds, while of enormous interest to academics, can result in projects being put on hold (sometimes for years) while the dig is fully assessed, artefacts are carefully removed and catalogued by experts and so on. Sometimes the remains are of such importance that a structure preserving and protecting them (and even allowing public viewing) has to be made part of the design of the foundations of new building. Many office blocks in The City have such viewing galleries in their basements. Such eventualities can create massive and unexpected overruns in central London building projects.
So this leads me to suggest a different metaphor for BI projects. Major elements of them are much more like archaeological digs than traditional building. The extent and importance of a dig is very difficult to ascertain before work starts and both may change during the course of a project. It is not atypical that an older site is discovered underneath an initial dig, doubling the amount of work required.
So, my belief is that BI professionals should not be likened to architects or structural engineers. Instead the epithet of archaeologist is much more appropriate. And if the fedora fits, wear it!
Fortune and glory in BI?
Apologies for the initial typo’ in the article heading, which persists in the perma-link. Of course I have the odd error scattered around the place, but in a heading! Maybe I need to employ a proof-reader.
A very brief post, just to acknowledge that sometimes you come across a gem of an article in the blogosphere. On this occasion, I would also like to thank the author for pointing his work out to me on a LinkedIn.com group!
Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya specializes in building better IT organizations and can be reached at ibogorad@bizvortex.com or on (905) 278 4753.
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).
The Top Business Issues faced by CIOs / IT Directors
Back then, I promised to share some of the findings from this study. These are summarised in the above diagram. The input was based on public comments made by a selection of senior people on the CIO group of LinkedIn.com, plus e-mails sent to me on the topic and feedback received by Chase Zander.
A textual version of the data appeas below (sample size ~60):
Issue
% of Votes
IT / Business Alignment
27%
Cost-saving
13%
Managing change
8%
Status of the IT Director
8%
Legacy Systems
5%
Customer focus
5%
Enterprise Architecture
5%
Business Intelligence
5%
Avoiding the latest and greatest
3%
Cloud Computing
3%
Only one response
17%
Total
100%
I would like to thank all of the IT professionals who contributed to this survey.
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.
Peter James Thomas 