The challenge(s)
There can be few organisations that have yet to wake up to the inherent value of having strong market and business intelligence (BI) at its fingertips. On the face of it, therefore, obtaining buy-in from your senior management team should be a walk in the park.
It is frequently the case, however, that where the greatest gains can be made, through leveraging a solid data warehouse exposing well-designed models, you run into the issue of obtaining the resource required to best exploit the platform you have available. On top of this, the way in which an improved reporting and business intelligence environment often gets introduced can be tricky to manage. All too frequently it is product driven (I saw this reporting software at a conference; it looked great, let’s buy it!), rather than value or needs driven and a lack of clear business value/benefit will quickly derail a good technical implementation. Especially if it is in need of additional resource for scale-out to the wider institution post-pilot.
At the other end of the spectrum it can sometimes be difficult to convince senior management that much can be improved on, after all no one likes the idea that the current reporting environment is deficient in some way, the implication being that there might have been some not so great decisions made on the basis of it.
However, you will mostly encounter those who just will never be excited by the idea of data warehouses, semantic models, or in fact any of the IT implementation side of a BI environment and yet it is important to get their buy-in for the resource required.
My experience, predominantly from the IT side, in implementing a new BI environment has met with characters across the gamut of this spectrum (I’m sure there are some cast-members I’ve missed out here as well) and it’s on that basis that I’ve written this article with the hope that it might provide others with a strategy for getting to that all-important ‘go live’ point, where ‘new’ becomes ‘standard’.
Running a concrete pilot
The most effective way of engaging the cross-section of stakeholders you want on board is by carrying out a bit of ‘show and tell’. The strength of well-constructed and well-visualised BI reports is the immediacy of the data being represented, and in the context of any demo you give the reports being displayed should always be ‘here and now’ and entirely relevant to your audience.
As such, you will want to consider your stakeholder group, consult with the part of the business driving the BI agenda forwards in your organisation and pick, at the very least, a dashboard construction that contains an area of interest for each of the areas you will be ‘pitching’ to, as well as at a minimum one drill-down report to expand on the data you are presenting at the high level.
This achieves two things; firstly it demonstrates that you understand that they are a key consumer of the BI platform you are looking to implement and you recognise their importance. Secondly you are putting their real data in front of them. They should recognise it (hopefully!) and moreover they should be able to immediately spot the improvements in understanding that data by having it presented outside of the usual Excel spreadsheet environment. In other words, you’re showing them how their data can be accessed and represented more effectively.
Who to engage early
If you have a planning department or similar then they should be your first port of call, in fact it is they that should be driving this project from the business side of things and if you can’t get them interested, well, you may be fighting an uphill battle, no matter how good the software you’re looking to implement. They will already know what the key measures are for predicting your institution’s success and will be able to help craft any data sources needed to represent them accurately across the domains you’re interested in demonstrating.
If you don’t have a dedicated ‘numbers and stats’ department, then it will be a process of going back to the source material, examining KPI specifications and rooting out the data. It is certainly more laborious and a more difficult context within which to validate your data; this is something to bear in mind when the inevitable hand goes up with the “that data is wrong” type of ‘question’.
Who to engage in a pilot
Assuming that your planning group are committed to the project it is they who should be able to identify a few data customers most suited to helping you design, build and test (most important this one!) your pilot BI environment. They should be sympathetic to the idea of the project, but some critical engagement is vital, you need your first presentation to have already dealt with the standard “but do we really need *this* data” type questions.
What to include in a pilot
In my institution we piloted department and faculty level dashboards that represented a cross-section of financial and student numbers related information, a total of 6 information panels each clicking through to a drill-down report matched against the University’s Key Performance Indicators.
This suited us well because it was easy to communicate the value to the institution of allowing heads of department easy access to data that had formerly been communicated via Excel spreadsheets and somewhat clunky distribution mechanisms. Being able to construct a single environment that allowed quick and easy access to all department and faculty level KPI data fitted neatly, both with the data needs of departments and faculties, as well as the Senior Management Team’s interest in driving the University forward based on strategic KPIs.
Oh, and of course, pretty pictures.
How to communicate
Initially a presentation was made to the senior management team’s regular meeting. This was definitely a ‘hands on’ demonstration, showing clearly that (a) the system worked and (b) it was already functioning from live data and as such was ‘ready to go’ to a full pilot. There is a definite advantage to presenting at a point where you are only asking for a nod to go ahead and pursue further, as opposed to asking for more resource to be able expand out into wider engagement. Avoid test data – it breeds suspicion regarding the accuracy of the new environment. Also, ensure that you really can just ‘flick the switch’ and let them use it, give them access immediately afterwards and ensure that the communication giving them the access details includes your plan for a wider pilot or initial limited roll out.
Department heads were then introduced to the dashboard environment at their regular meeting and the planning office regularly had update slots in these meetings as changes were made and enhancements introduced in response to queries and suggestions. Frequent drip-feed of information, occasionally with technical expertise on hand to answer any difficult infrastructure and data source questions build familiarity and confidence and across a wider audience who will themselves build the new infrastructure into their day to day reporting. We found that very little encouragement was needed for department heads to start bringing the dashboard content into their internal meetings, but importantly this was because the report content was exportable and viewable across a variety of devices.
How to maintain engagement
It is important to maintain follow up activities both upward and across, especially if you foresee a need for further resource to improve or scale-out your pilot infrastructure. As such, having a fixed horizon for your pilot activity and defining completely the level and scope of roll-out post-pilot will afford you the opportunity of re-presenting the environment to the Senior Management Team in such a way that, on completion of the pilot phase, you can provide data (ideally in the BI environment again, re-emphasising its usefulness) that demonstrates take-up and use of the infrastructure.
Project this into the future, remembering that you will likely already be receiving requests from other areas across the institution, each looking for their own presence (normally from within the sections and areas that the senior team are responsible for) and pitch any resource requirements accordingly.
Provided you are delivering a reporting environment that is delivering good, accurate and accessible content, it should make its own business case, but providing statistics on the differences between heads of department being able to self-serve this kind of BI, versus generated ad hoc reports that must be requested in advance and tailored to each department will demonstrate efficiency gains that will push the point home.
Building on success
Once you have a completed pilot the next steps should be clear: roll-out to all user groups and a defined plan for future expansion. Our future plans focused initially more on rationalising look and feel with the corporate brand (still an on-going project) and providing more of the detailed numbers reports in an easier to access and self-serve format. The dashboard environment is in the process of being combined into a single point of access for both faculty and department level information (it began as two separate dashboard views) and KPIs are being re-worked to provide a more useful indication element to the dashboards. We also planned for training of more power users to produce reports and for the replacement of Crystal Reports infrastructure within the Academic Section more generally, building a self-service centre for operational reports frequently used across the University.
Our context
We have an active and highly engaged Planning and Strategic Change office that has driven the project from the business side. They not only pushed the important points in front of key stakeholders at demonstrations and follow up activities, but they also got their hands dirty, were first-hand adopters of the new system and therefore could speak with the voice of experience when talking to others about the value the new environment was providing.
Our institution also has a very adaptive and flexible approach to new IT initiatives, primarily because we have a strong heritage in providing new systems based upon internal resource; self-building and self-sourcing infrastructure and driving forward implementation internally. Institutions that need to go outside to find the skills and expertise required to drive the technical side of a project like this will probably have a harder task acquiring initial resource to produce the pilot stage. The fundamentals of any approach should be similar, but with an eye to on-going resource implications that may not affect institutions where skills already exist, or can readily be trained, in-house.
Our infrastructure
At my organisation we use the Microsoft Business Intelligence stack, comprising SQL Server, Reporting Services (SSRS) and Analysis Services (SSAS). We expose the results through a corporate SharePoint infrastructure. We’ve been able to drive this all with a relatively tight level of technical resource and with significant input from our Planning and Strategic Change section, which has driven the project forward and up-skilled Crystal Reports knowledge into full-blown SSRS report construction abilities.
Guest Post: Author
Rob Mossop
Development Manager & Business Analyst
MIS, University of Essex
E: rwmoss@essex.ac.uk
