I am not sure whether it is the economic crisis focusing minds, or if there has been a turning point in the maturity of BI, but there seem to have been quite a few common-sense articles about the area recently. One I have just read is by Fei Luo at Information Management. The article may be read here.
Much of what Fei has to say chimes with my own experience of successfully driving change using BI in organisations. In particular, the observations about business involvement, having a strategy, regular business communication and the importance of training are all well-made. I would go even further saying that good BI projects must have a proper business / IT partnership at their centre; one that goes beyond business involvement and becomes business commitment.
My further thoughts about some of the themes raised by Fei Luo’s article can be viewed in the following blog posts:
I was pleased to see these areas being drawn together in a single, cogent article.
Fei Luo is vice president of information services at City National Bank, a public bank headquartered in California. Fei Luo can be reached at Fei.Luo@cnb.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.
The current economic climate seems to be providing ammunition for both those who favour outsourcing elements of IT and those who abjure it. I’m not going to jump into the middle of these discussions today (though I am working on an article about the pros and cons of outsourcing BI which will appear here at some future point). Instead I want to talk about another type of outsourcing, one that ended up being a major success in a BI project that I recently led. The area I want to focus on is outsourcing analysis to the business.
The project was at an Insurance company and in these types of organisations one hub for business analysis is the actuarial department. These are the highly qualified and numerate people who often spend a lot of their time in simple number crunching with the aim of ensuring that underwriters have the data they need to review books of business and to take decisions about particular accounts. As with many such people, they have both the ability and desire to operate at a more strategic level. They are sometimes prevented from doing do by the burden of work.
As I have explained elsewhere, an explicit aim of this project was cultural transformation. We wanted to place reliance on credible, easy-to-use, pertinent information at the heart of all business decisions; to make it part of the corporate DNA. One approach to achieving this was making training programmes very business focussed. One exercise that the trainers (both actuarial and indeed me) took delegates through was estimating the future profitability of a book of business based on performance in previous years (using loss triangulation if you are interested). This is a standard piece of actuarial work, but the new BI system was so intuitive that underwriters could do this for themselves. Indeed they embraced doing so, realising that they could get a better and more frequently updated insight into their books of business in this way.
This meant two things. First the number-crunching workload of actuarial was reduced. Second when underwriters and actuarial engaged in discussions, for example around insurance estimates to be included in year-end results, the process was more of an informed dialogue than the previous, sometimes adversarial, approach. Actuarial time is freed-up to focus on more complex analysis, underwriters become more empowered to manage their own portfolios and the whole organisation moves up the value chain.
This is what I mean by the idea of outsourcing analysis to the business. In some ways it is the same phenomenon as companies outsourcing internal administrative tasks to customers via web applications. However, it is more powerful than this. Instead of simply transferring costs, knowledge and expertise is spread more widely and the whole organisation begins to talk about the business in a different and more consistent manner.
It’s nice to be able to report a success story for at least one type of outsourcing.
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.
Back in September of this year, Obis Omni were kind enough to invite me to speak at their Forum 2008, which took place on the outskirts of London and had the theme of “Realising Business Intelligence & Corporate Performance Management Success”.
The strap-line of my presentation was “EMIR – A case study in cultural change”. I have written about some of the themes that I discussed at this seminar elsewhere on this blog (e.g. about the importance of promoting your project in Marketing Change and the strong role to be played by extended business teams in Scaling-up Performance Management). In this article I am going to talk about some aspects of the pivotal area of education.
Background on The EMIR Project can be found elsewhere on this site. Briefly it was a business intelligence / data-warehousing project aimed at improving the profitability of the European operations of a multinational insurance organisation.
More importantly, EMIR was always seen as primarily a cultural transformation initiative. The explicit aim of the system was to transform the culture of the organisation into one in which the use of credible, timely and easy-to-use information became as much second nature as picking up the telephone. Of course one initial learning here is that if you are in the business of cultural transformation, it helps an awful lot to tell people that this is the case. Having this element as a public goal was of great assistance.
Making a good first impression
Having already established a strong extended business team (see the links in the first paragraph above) the project team also realised that there was another important group to win over; our first set of 20 or so training delegates. We felt that if they went back to their offices singing the praises of EMIR then this, supported by the voices of the extended team would give us the necessary momentum to carry us through the first training phase and make a great start to our cultural change work.
It is often said (perhaps sometimes glibly) that as much attention should be paid to the deployment of IT systems as to their development. Many IT managers may not truly believe this in their heart-of-hearts, perhaps an “if I build it, they will come” attitude is sometimes more prevalent. However, with the EMIR project we took the educational aspect extremely seriously.
To start with this we made EMIR training a 3-day event, something that was unprecedented in IT training in the organisation. Second, we insisted that all delegates (the senior managers of the European organisation) travel to London to attend the course*. One reason for the duration was that we wanted to cover a lot of ground, but also we wanted to send a message that this was an important event and merited the devotion of an appropriate amount of time.
A lot of effort and thought went into the presentations that would be made, the different styles of training (some lecture style, more hands-on), the quality of the supporting training materials, the arrangement of the rooms and so on. I assigned one of my senior managers to oversee the training and we also employed an external training consultant to help us design the courses and user guides and achieve the professional look that we were going for.
The importance of real-life examples
Sometimes training simply explains how to use the technical features of a system, but, again, we were in the business of cultural transformation and so this shifted opur emphasis. Because of this, and also because the system was pretty intuitive and easy to use, in training we focussed on using the system to address real-life business problems. One example of this would be estimating the future profitability of a book of business based on historical trends.
This approach meant that the business value inherent in the system was clearly demonstrated. This was not an IT system, it was a business system. A key first step in changing the behaviour of managers was establishing that there was something in it for them; namely that they could get at information that was previously unavailable, that access to information was quick and easy and that their decision-making would be enhanced. Ticking these boxes through our real-life exercises helped to engage the enthusiasm of delegates and made them more receptive to our other proposals for how to build use of the system into their day-to-day lives.
This business-focussed training was initially carried out by our actuaries, however as demand for training soared in later weeks, I also ran many of these workshops. It was potentially a major challenge for an IT person to be telling insurance underwriters how to run their business, but something that I actually enjoyed very much. While discussing training personnel, we always had at least two people present in the classes as well as the lead trainer. The role of these other people was to check that delegates were keeping up and help anyone who was struggling with an exercise. We did not want anyone to fall so far behind that they became disengaged from the programme.
Breaking the back of cultural change
Our approach worked and our first twenty delegates became converts to the EMIR cause. Before the first training session, delegates has (understandably) been somewhat reluctant to commit so significant a period of time to the training process. After it an example of the type of message that attendees took back with them to their offices was: –
“This is the best management information I have seen, it represents a big leap forward”
It was not all down-hill from this point and a further article will deal with how we sustained cultural change over the latter stages of this project. However, after this initial success, some things became easier and we had safely negotiated what was probably the largest hurdle in the project.
Given this, I was quite happy to release some project funds for champagne at the end of our first three days, but should stress that the project was brought in under budget nevertheless.
* In latter training phases – having succeeded in making our point – training was often carried out in each European country, something I will cover in the future.
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.
There is a strong link here to my Vision vs Pragmatism article. In this I argued that Vision and Pragmatism are both essential for the success of any project, be that related to change, to IT, and certainly when using IT to drive change. Unsurprisingly, similar comments apply to whether a holistic or incremental approach to BI is the superior route. However, in this case, I will come down more firmly on the side of one of the options.
The benefits of an incremental approach
Of course the secret of the success of many projects is their incremental nature. Incremental deliveries, particularly those early on in a project, enable you to do a number of things, including: –
Proving that business value can be added the work that you are doing
Showing tangible evidence of progress
Demonstrating that the project team is responsive to business priorities
Chopping up funding into more digestible parts
Providing early exposure to change management issues; allowing time to learn from mistakes when still operating at on a smaller scale
Overall incremental work can enhance the credibility of a project team and thereby made it easier to secure senior management support. Such work is indispensable to any project.
How does the sum of the parts measure up?
However there is a point to be made here in favour of a holistic approach which goes beyond my previous preference for always having an overarching vision. This is something that is specific to business intelligence and relates to the nature of information delivery. In a nutshell the sum of several incremental BI developments may be considerably less than the whole if each is not part of an overall strategy.
BI is about having the information necessary to run the business. However, it is also about how that information is delivered and how internally consistent it is. Often BI projects aim to address a fragmentation of existing reporting systems that leads to confusion amongst users and even a general distrust of figures. It is entirely possible to perpetuate this situation, simply replacing older reporting technology with shiny new ones. Each of these new systems may be easier to use that its predecessor and offer significantly greater access to information, but the fragmented nature of information provision will not have been addressed; it may even have been made worse.
A single platform
The ideal for a BI solution is to have a single platform which supports all pertinent reporting needs. There will undoubtedly be different segments of this, tailored to different groups of users, but these should use subsets of the same dimensions and measures and the same reporting and analysis tools should be used. Adhering to these precepts means that when users of one part of the system need to employ another part, they are not taking a step into terra incognita, but instead are familiar with their surroundings and get the sense that the same logic pervades all of the system.
On a practical level, this approach minimises costs due to software licenses and simplifies your technical architecture, again keeping a lid on expenditure. Fewer people are also needed to both build and maintain a single, central system than many divergent ones. Just as importantly, a single-platform approach means that training becomes focussed on business issues rather than the functionality of a different reporting suites. My experience suggests that, after an initial investment in thorough training for users, introduction of new reporting capabilities can be very smooth and efficient in such a set-up.
Of course developing good BI takes time and effort. Getting to the eventual ideal state that I have described above will undoubtedly take some time (in my most recent BI project it took five years to fully realise). This means that there is no real alternative to the incremental approach that I described at the beginning. However, taking a more holistic approach ensures that your incremental deliveries are aligned with both each other and overall business needs. It also means that with each incremental release there is a related reduction in fragmentation. This is the difference between slowly unveiling a large, coherent edifice and revealing several separate sculptures one at a time.
The link with cultural transformation
In particular if an aim of your BI project is to transform how users behave (of course this should be a central aim of any BI project, what else is BI for?), then this is going to be most easily achieved with a holistic approach where each phase builds on the success of the previous ones. In this scenario, each incremental delivery can be seen more as extending the remit of your BI system to a new area, rather than adding on a new module. Phase N+1 always reinforces the messages from Phases 1 to N. Each step reduces fragmentation, increases consistency and further improves decision-making. This is the best way to make sure that your BI efforts exceed the sum of their parts, rather than falling short of them. Such a rigorous approach is also the best way to ensure that you meet your cultural transformation objectives.
This was the title of a presentation that I made at the Butler Group BI Symposium in London during October. In this article I wanted to focus on just one theme that I discussed; namely meeting the management information needs of a variety of business units, each of which spanned a number of different countries across Europe.
This seems like a very obvious thing to say, but if you goal is to meet the management information needs of a wide range of business units across multiple countries, then it helps to work with quite a few of them to figure out what they want, where this overlaps with your project objectives and how to get everything aligned.
In my experience things have always worked best when the project team have recognised this early on. In a recent European-based project, my team initially spent nine months working with a group of 30 business people from ten different departments and eight different countries (of course this process lasted a total of nine months, we did not lock them up in a room for the duration). We called this group our Extended Team. Part of our work with them was gathering requirements – we started with a blank sheet of paper and asked them what metrics they wanted to run their company. We then went through the painstaking work of better defining these ideas, distilling them down into different themes, making mock-up reports and eventually iterative prototypes. At each stage, we met again with the Extended Team and got their further input.
Now while this is a great way of gathering requirements and ensuring that your product will answer real business questions, it is and even better way to create a core group of business people who feel strong ownership of the product and are proud of their association with it. In turn, this helps amazingly with driving cultural change. On returning to their day jobs after a typical two-day meeting, the members of the Extended Team would be very positive about what they were involved in doing and share their enthusiasm with their colleagues. Momentum starts to gather and you begin to create a buzz about the project.
As well as being the people who helped us to make the eventual business intelligence system user-friendly and business-focussed the Extended Team were also our marketing representatives in the regions and helped to build up positive expectations about the system.
We put a lot of thought into the type of person that we wanted on this Extended Team. We wanted people who were leaders, who were open to doing things in new ways, who were comfortable with technology and who took an analytic approach to their work. This group made a major contribution to the success of the project. It would not have been possible to scale-up our solution without their assistance.
This time last year, I was a member of a panel on a webinar hosted by Computing and Accountancy Age magazines. This post is not specifically about this webinar, but rather about positions that I regularly found myself taking in response to questions. The questions were along the lines of “Do you think that X or Y is more important in trying to achieve Z?”, my frequent reply was “both”. In fact at one point I recall deprecating my own fence-sitting.
Fence-sitting is not normally seen as the most noble of human activities, it tends to suggest a lack of decisiveness, even timidity. However, when faced with a question as basic as “What is more important for survival, food or water?”, then “both” seems to be the only intellectually credible stance to take. Allowing for the nit-picking point that you will die of thirst quicker than you will starve, over the medium term food and water are equally important. I feel the same about vision and pragmatism in business projects and in business people.
There is nothing that homo sapiens likes more than to pigeonhole his or her fellows. We tend to take a binary approach to people’s skills. Fred is a visionary, but you wouldn’t want him to run a project. Jane is brilliant at the details, but she doesn’t see the big picture. Perhaps we are more comfortable with the idea that the strength of any colleague is automatically balanced by a weakness; it brings them back down to a reasonable level – what the Australians call tall poppy syndrome. Maybe the way that we think about visionary people is also influenced by the connotations of the word, bringing to mind soothsayers, prophets and oracles. All of these historical figures had an other-worldly persona (often literally). They were not like “normal” people. Culturally, those who have visions are seen as a race apart. As Fitzgerald might have said “Let me tell you about the visionary. They are different from you and me.”
Setting aside any psychological angle, there are two points to be made here. First, of course people are all different and are endowed with varying abilities. This means that any successful team needs to have a balance of personalities and skill-sets. If you have some one who is purely a visionary on a team, then that is a great strength (most of the time), but orthodoxy suggests that this needs to be balanced by people who have less ethereal skills. So far, so hum-drum.
The second point is a potentially more interesting one. Maybe, contrary to what I have written above, visionaries are not so different from the rest of us. Instead of being skin-clad augurs with wild hair, maybe visionaries are people who can embrace a certain way of thinking when necessary. Maybe vision is something that you can turn on and off. This certainly chimes with most theory about personality types. Something that is often forgotten is that extrovert / introvert is not a binary choice, but a continuum. Also where some one places on this scale on average, may be quite different to where they place at a particular moment. Some one who is 75% introvert on average may be exceptionally extrovert in certain circumstances. Applying the same logic, some one who is not normally visionary, may be so sometimes and vice versa. So instead of the orthodoxy of having a team made up of discrete personality types, maybe we should realise that the behaviour of team members and what they can contribute may change over time.
There is clearly a lot that could be discussed here, I am going to restrict myself to talking about vision and what is often seen as it alter-ego, pragmatism. The question I will consider is “What is more important for a project, vision or pragmatism?”. This is where I return to fence-sitting, my answer is a resounding “both”. Vision is necessary to work out what to do, pragmatism is necessary to do it; a food and water situation. In fact I would argue that the optimum way to run a project is to initially develop a vision of the ideal outcome, ignoring any constraints. Such an approach is often seen as unrealistic and is tagged with unfavourable epithets such as “ivory tower” or “blue sky thinking”. However it is a necessary step. I much prefer the idea of thinking of what could be achieved and then applying constraints of time, funding and appetite for change, than the opposite where any potential progress is immediately ham-strung by such considerations. If vision is used to define a desirable, but potentially unattainable, Utopia and then pragmatism is used to pare this down to what is achievable, then the resulting strategy will retain some of the shape of the original ideas. It is likely to result in an approach that has a central theme, that is coherent and which will offer a platform for further progress. Applying pragmatism first is likely to yield a fragmented programme that is uncertain what issues it is meant to be addressing and, by seeking to do only what is incremental, will inevitably fall short of what could be possible (even given constraints).
Looking at this issue the other way round. If there is not the second-pass of applying pragmatism to the initial vision (even sometimes to the degree that the vision is rejected as unworkable), then failure is all but guaranteed. Pragmatism is the structural engineer finding solutions to the challenges posed by the architect’s design. It is figuring out the “how” after vision has established the “what” and “why”. It is also one of the main attributes that is necessary for governing execution, suggesting as it does a flexible approach and the maxim that “what counts most is what works best”. It is difficult to envisage how anything other than pragmatism would lead to success in these phases of a project. There is however something else to consider here. Something that sustains projects through execution is often the initial vision. This gives the team a sense of what they are doing and why they are doing it. This can be crucial when the inevitable setbacks are faced. Vision may also need to be switched back on when a major obstacle needs to be overcome or a change in direction is required. Rather than thinking of vision and pragmatism being sequential phases, perhaps they are alternating mind-sets that continue to vie for pre-eminence during a project. On average vision has the upper hand early on and pragmatism in the middle and later stages, but at any given point, it maybe desirable for the positions to be reversed.
This is another echo of the earlier comments about personality types and it is to this area that I will return in closing. Certainly projects need both visionaries and pragmatists; however these can often be the same people. I would argue strongly that a number of people are capable of both developing visions and aggressively pruning these to make them realisable, or chopping them into phases with phase B predicated on the success of phase A. Further I think that a make-up that embodies both vision and pragmatism, together with having the ability to flip between them as dictated by circumstances, tends to be the ideal one for managing projects. Certainly having one person who can encompass “what”, “why” and “how” seems efficient, but this holistic view of the process tends to go hand-in-hand with a passion to deliver. This passion is a product part of vision (believing in your own ideas) and part of pragmatism (owning the delivery of these ideas) and a very powerful factor behind successful projects.
Peter James Thomas 