In This Topic:
Getting comfortable with an iterative approach
Securing executive-level sponsorship
Analyzing your current environment
Creating an implementation plan
Picking the right people for the implementation team
Fostering an inclusive environment
Establishing a culture of communication and collaboration
Beginning with the right goals
Minimizing risk
Keeping the big picture in mind
There are many paths to the top of the mountain, but the view is always the same.
—Chinese Proverb
Some strategies for implementing Microsoft Business Intelligence are already coming to the fore, even though the field is relatively new. Try the following ten keys to success and see which ones unlock the potential of your BI implementation. (My bet is that they'll all help. I'll also bet you saw that one coming.)
1. Reiterating an Iterative Approach
Yep, this is a theme I harp on elsewhere in the book, but only because (a) it can bring heavenly business results but (b) it may take some getting used to at first. The iterative approach to BI implementation breaks up the project into specific BI components and introduces them in small, iterative cycles, each one following a complete set of stages before circling back to the beginning, incorporating what's been learned, and sallying forth again (as shown in Figure 1).
Note that each cycle goes full circle before moving on to additional cycles. That's a departure from the more traditional waterfall approach that slams the books shut on one stage of a project before moving on to the next stage. The first iteration is always the hardest. The first iteration is a complete end-to-end cycle, just like every other iteration. The first iteration is a time to work out all the kinks and find any major problems up-front so adjustments can be made. The first iterative cycle forges the initial trail through the organizational landscape; by the time your BI implementation starts to involve a vast swath of your organization, it's had lots of opportunities to get better and better at doing its job.
Because each iterative cycle incorporates feedback from users into future cycles, you're far likelier to end up with a solution that your people find usable and valuable — because they've grown familiar with how its parts work and they've seen it produce usable information.
Now, any business veteran steeped in the lore of the marketplace will tell you time is money. And it's uncanny how quickly both can end up in short supply — especially when you're trying to get a new technology up and running. No wonder overruns are such a common headache. If you are using the waterfall approach and have been cruising along from one phase of a project to the next, checking them off with a decisive flourish moving on — nary an iteration in sight — you may get to the end of your allocated budget and time blissfully unaware of lurking flaws. Then . . . surprise! A review at the end of the project turns up something you have to fix. Do you extend the budget and stretch the timeline or abandon the project in an incomplete (unusable) state. Devil or deep blue sea? (No, thanks.)
Of course, if you've been faithfully working through iterations of your BI components, you've been generating some useful information and gaining insights into your implementation all along, from the get-go. The budget has barely been scratched; but the implementation is improving, the information is starting to accumulate, and folks are starting to get the hang of this newfangled BI stuff. And behold: Increasing value reverberates through the project and out into the organization. As each iterative cycle progresses, the team gets better and better at the development process. Practice makes perfect, and with each iteration, the team is practicing. Just remember: You don't have to go overboard and try to conquer the world (where would you put it, anyway?). Although your BI system will always need to run iterative cycles to stay at peak performance (just as a sports car needs tuning up from time to time), they'll become a natural part of doing business.
2. Obtaining Executive-Level Sponsorship
Many BI projects begin life at the middle management level. Makes sense. Middle managers have familiarity with two distinct levels of the organization: the employees on the front lines and the executive decision-makers. And though I've found that a grassroots-up approach is a natural for implementing Microsoft BI, gaining executive-level sponsorship for such a project is crucial.
A BI project by its very nature touches many parts of the organization. That means both the rank-and-file and executive levels have indispensable roles to play: The rank and file keep the system supplied with practical feedback and solid data captured from the business processes; the execs make strategic use of the information flowing out of the data warehouse. Working in tandem, they're formidable. But folks at both levels have to have a stake in the system's success.
 |
I've seen a number of BI projects begin life with a single executive sponsor and then slowly die off because the rest of the executives weren't brought on board. Gaining cohesive executive-level sponsorship is critical; two ways I've seen middle managers handle that mission are as follows:
|
|
A formal steering committee that is made up of executives and stakeholders (including power users) from across the organization.
An open forum where middle managers meet, discuss, and stay connected to the business users in order to relay to executives exactly what is happening in the organization. This concept all hinges on the company culture however. If the culture of the organization follows the lines of the workers telling the managers what they want to hear instead of what is really happening and then the managers telling the executives what they want to hear instead of what is really happening, then the executives have a false sense of stability. The culture of finding out what is really happening needs to come down from the top. Managers should not be afraid to tell their executives exactly what is happening, and the workers should not be afraid to tell their managers exactly what is happening. A culture that embraces truth, accepts critical feedback, and searches out faults in its systems and processes in order to fix them is well on the way to a successful BI implementation.
3. Assessing Your Current Environment
To get your BI implementation off the ground, you have to do first things first: Take a look at where you're taking off from. That means getting an accurate picture of how your current business environment really works.
If you're going to give your BI project a solid foundation for its characteristic activities — capturing data from business processes, addressing (and accurately conveying) the change that your BI implementation will bring, embracing power users, and providing an inclusive and interactive business environment through communication and collaboration (whew!) — pay attention to these elements of your current business environment:
Business processes themselves.
Data that your business processes generate.
Your operational systems.
Your software licenses.
The technical skills that your people already have.
The best tools for understanding your current environment include building process flows and process mapsthat paint a big picture about what is really happening. When building these process flows and maps, make sure you're only after the real stuff — not the idealized picture that folks paint when they're trying to tell management what it wants to hear. Interview frontline employees and include them in the assessment process at the end of each iterative cycle. The results may surprise (or disillusion) the supervisors and managers, but be discreet and stay focused: If you provide the straight goods on what's really happening, it helps your implementation — and eventually the whole organization when your system comes online.
4. Developing an Implementation Plan
The Western world loves plans for the future. The business world loves plans for becoming more efficient, profitable, timely, whatever. And whether or not you love plans, you need them for doing just about anything. A BI implementation is one of those undertakings that really needs a good plan — after all, it requires a vast array of resources and affects a wide swath of the organization — including (yep) the organization's plans. You don't want it to just go blundering around aimlessly, even if it could.
A Microsoft BI implementation plan should include
Business and technology goals.
Project milestones.
Internal and external resources.
Communication and collaboration.
Training.
To keep your BI implementation on track and human-scale, break up the overall plan into units — discrete tasks that can be accomplished during each iterative cycle of the implementation. Begin the iterative cycles with low-risk, high-value tasks — the low-hanging fruit so well loved by people who want to do things fast. For example, if one of your business goals is to gain a window into your sales figures, then begin with a single store or product. At the conclusion of the first iterative cycle, you'll have
Some accurate, timely, usable BI information about a real part of the business (while demonstrating that it can be done).
A model for later iterative cycles.
An end-to-end path through the implementation process.
Not bad for a first time out. As the iterative cycles continue, the breadth of the window into your business expands, and user feedback helps improve the process. Future iterations are able to build on the previous iterations in a solution that continues to gain functionality and usefulness.
5. Choosing the Right People for the Implementation Team
Having the right people on the implementation team is very important in achieving a successful BI implementation. It's a big, complex job, and a range of roles comes with it; your team needs people with BI-friendly skills.
5.1. Your in-house team members
The general roles that your BI project team has to fill include these:
Experts in your business processes.
Experts in the hardware and software essential to BI.
Project managers.
Fixers who know your organizational politics.
5.2. Calling in consultants
Given that business intelligence is still a relatively new set of tools, it's no accident that consultants often play a big part in a BI implementation. Before you start combing the Web for Microsoft BI hired guns, however, here are some principles to keep in mind:
Hire the right consulting firm. What "right" means will vary from one organization to the next, but in general, look for a partner for the long haul. You want to build a relationship with your consulting firm and know that you can trust it to do the right thing. I recommend looking for a firm with a strong local presence with a proven track record. It also doesn't hurt to ask them about their BI experience and methodology.
Decide consciously how to integrate consultants into your project. In what areas of BI implementation are you likeliest to need help?
Do your homework. If you take some time to study up on what Microsoft Business Intelligence does, enough to get a good working sense of what it's for, how it works, and what you can realistically expect from it, then you'll be less easily dazzled by demos — and in a better position to make the most of what consultants have to offer.
NOTE
Just like attorneys, real estate brokers, and stock brokers, consultants get paid when they're doing something for you. If you've got a handle on BI capabilities, your implementation plan, and the role you expect consultants to play, you're ahead of the game.
