I spend a lot of time working with BI teams assessing how they’re doing and what they should do next. We often use a BI maturity model as a framework for these assessments. They’re great accelerators and help the teams to understand where they fall between “getting started” and “guru”, but they’re not great (by themselves) at helping development manager figure out what specific things they need to address next.
Development managers are (nearly) always faced with limited resources and must aggressively prioritize how to spend those resources – on people (FTEs and consulting/contract), on tools, and on “soft” expenses such as training and conferences. They also are faced with determining how to allocate new projects vs. maintenance work and refactoring.
Making BI maturity useful to development management requires bringing sweeping generalizations down to earth in terms of what task and tools are next. What’s going to bring the biggest bang for the buck?
In building out this answer – we call it the strategic roadmap – the unique situation of each team comes into play more than anywhere else:
1. What business or development processes are blockers, preventing any technical efforts from being successful?
These issues range from complex and slow to change (strategic direction, steering committees, funding models, etc.) to localized issues (project management methodology, development best practices, etc.). Either way, at least planning for and starting change is step 1. The BI maturity model will highlight both where these issues are and what the goal state should be.
2. What’s the organization’s capacity for change?
Implementing new tech or radically changing the way existing tools are deployed requires excess capacity in the development team. Excess capacity includes both time and skill – a team that is operating at the edge of their abilities will struggle with technical change. Again, maturity points out where and how much in comparison to the prescribed process change. Readiness here may mean training, re-prioritization of existing projects, adding staff, or hiring consulting expertise.
Organizational or process change impacts a much wider audience and is a topic unto itself. Relevant topics here include initiative sponsorship, mandate vs. consensus building in the culture, and driven change vs. at-your-convenience change. Often we recommend an internal marketing campaign and the designation of “BI evangelists” as components of an organizational change strategy (e.g. implementing data governance or chartering a BI steering committee).
In both areas, the addition of expert staff to the team can play an important role, and this possibility should be explored early in the planning process as it will greatly impact the roadmap. Waiting until the end to discuss this possibility simply leads to a unrealistic roadmap.
3. How quickly does change need to happen and are there identified goals already in place?
Does the organization expect long, traditional development cycles with clear SDLC phases and phase gates? Or does it expect value delivery early and often? Delivering early value can come from a functional POC, from a purchased accelerator (e.g. SAP RapidMarts, IBM’s prepackaged industry offerings, Perficient’s HealthBI solution, etc.), or by adopting an Agile or any iterative development methodology. Each of these possibilities have significant pre-requisites in terms of process and technology, so see #2 in evaluating the capacity to adopt these.
4. Characterize initiatives as incremental or monolithic.
Some change happens over time and can only mature at a limited pace. Some happens all at once (e.g. implementing a tool). Size the boxes on your roadmap according to the length of change process and then layer them according to each of the above.
When complete, the strategic roadmap must be a pragmatic plan for implementation of the BI program over the next quarters and few years. Too often roadmaps are developed without a good feel for what the organization will accept financially (internal and consulting labor costs and technology costs) or in length of implementation. A “let’s see what you come up with” mentality inevitably leads to a rework of the plan, not as a result of business change – that is to be expected, but simply as a result of already set financial or temporal restrictions that weren’t explored up front.
So, take the maturity model, glean from it the process blockers, assess the capacity of the organization to change and/or acquire expert help, apply business culture and priorities, and layer in the initiative according to their nature, all the time ensuring that you are within the realistic appetite of the organization to support the cost and time frame of the roadmap.
