Inside the Biz with Jill Dyche

Could Data Governance Help the War on Terror?

In which Jill wags her finger at the silos—ours, theirs, and yours.

“Our intelligence community failed to connect those dots, which would have placed the suspect on the no-fly list."
-- President Barack Obama

President Obama addressed the Christmas day terror attempt in his White House briefing this afternoon. He acknowledged that the U.S. government had botched terrorist tracking and that the system had failed. He admitted that each agency took responsibility for its own stuff. He also confessed that there was a lack of information sharing, that various government agencies had failed to pull it together. The subtext was that current practices and the best of intentions aren’t enough when it comes to the war on terror.

Obama sounds like a lot of corporate executives I’ve met. They admit that the individual departments are working hard and may be meeting their individual goals. But then something stupid happens. The company loses its largest account or a competitor beats them to the punch on a new product. The hard fact emerges that the company could have used its information better. And that siloed organizations beget siloed data.

The alleged terrorist, Umar Farouk Abdul Mutallab, had been in Nigeria, Yemen, the United Kingdom, and The Netherlands before flying to the U.S. Each of these governments had a slice of information about him. The UK had enough information to put him on a watch list. But the information was never integrated into a rich enough profile of Abdul Mutallab for the FBI to mark him as a person of interest. As Informatica marketing vice president Chris Boorman wrote in his excellent blog post, this would have been an apt use of identity resolution software. Various government agencies could have matched partial information to form a holistic view of Abdul Mutallab, one that could have been shared, thus pinpointing him as a suspect. With the right collaboration, this could happen at both federal and international levels.

There are over a million names on the U.S. terrorist watch list, and in fact the intelligence community had information that an attack on the U.S. might be imminent. White House Press Secretary Robert Gibbs insisted that since apprehending Abdul Mutallab, they had gleaned “usable, actionable intelligence” from him. Given their track record, you can’t help but wonder how American intelligence agencies will use this information. 

“It is increasingly clear that intelligence was not fully analyzed or fully leveraged,” Obama conceded. “That’s not acceptable, and I will not tolerate it.” As much as you believe him, you’ve got to wonder what he intends to do. Sure, he inherited a bunch of crap, but it’s crap we hired, er, elected him to fix.

The conversation in the press has been the same conversation that occurs in corporate conference rooms across the world after a major screw-up: “Who did the oversight?” and “Who should get fired?” “Growing questions about if and when heads will roll!” trumpeted CNN’s Wolf Blitzer. In a crisis, attention seems to shift to the people issues.

Instead, the government should be addressing process issues. Indeed, the real conversation should be how to move forward. These questions should be asked now: “How should we bring identifying data together? What are the key sources? How should integration, access, and usage policies be formulated? What would a sustainable process look like?” Those questions aren’t “who” questions, they’re “how” questions, and they should be front-and-center in the national security conversation.

Maybe they should also be part of your next conversation with executives or business users? The Christmas day terror attempt is one of many, many examples that the opportunity cost of not having data governance could be high, and the consequences nothing short of catastrophic.

Are You Really Ready for Data Governance?

In which Jill makes excuses for people who make excuses.

Fall conference season has (mercifully) come to an end, and I can finally reflect on what I learned on my most recent tour of industry and vendor events.

(Editorial aside: I don’t know about you but I like Vegas, I love New Orleans, and if I see Orlando again it’ll be too soon. Note to conference organizers as you finalize your 2010 event planning: The Big Easy still needs our cash!  Let’s go back. The jambalaya’s on me!)

Anyway, I’ve been speaking and writing a lot about data governance, and presentations at TDWI, SAS, Teradata, and various clients have placed me squarely in the crosshairs of people aiming for effective data governance programs. It’s interesting to hear their questions, particularly as they voice concerns about data governance adoption in their organizations. One question I get in almost every session is a variation of this one:

Alright Miss Fancy Pants, why is it that every time a so-called expert talks about a major business initiative they bring up change management? Why can’t we just launch data governance without all the change management fanfare? Why can’t we just ‘get ‘er done?’

Answer: I don’t know, why can’t you? Or, more aptly, why haven’t you?  Not trying to be argumentative here, but 1) my pants are just black wool crepe, trouser-cut, which I think is more understated than fancy, and 2) it’s just that the most effective data governance programs are often also the most disruptive. And, simply put, disruption makes people nervous.

Professor Robert E. Quinn at the University of Michigan Ross School of Business writes about taking people out of their “normal states” (aka, their comfort zones) and painting a picture of what they need to do. In a seminal Harvard Business Review article in 2005 called “Moments of Greatness: Entering the Fundamental State of Leadership,” Quinn described true leaders as ready to “venture beyond familiar territory to pursue ambitious new outcomes.” If that’s not data governance, I don’t know what is.

After all, the “normal state” in most companies often means contradictory policies, multiple versions of the truth, absence of true data ownership, selective collaboration, and decision-making in a vacuum. Data governance is the opposite of all that.

“We couldn’t afford to experiment with data governance,” says Kevin Davis, Director of Research Initiatives at a major southeast retailer. “We retained a consulting firm to teach us the foundational stuff and we followed their advice. That included a lot of deliberate structure, education, evangelizing, and expectations management.” Davis and his team faced the additional challenge of coupling their company’s new data governance strategy with a major MDM technology acquisition. “We knew we only had one shot at getting it right,” he says.

True, it’s easier to avoid sticking your neck out. And in some cultures (particularly in high-tech companies, but that’s another blog post altogether) wholesale changes to policies and processes can actually begin from the bottom-up. It’s not only less disruptive, it demonstrates value to incent widespread adoption. Bottom-up data governance is a legitimate and proven approach. But at the end of the day, your strategy needs to include a plan to broaden governance beyond the initial domain. After all if you’re not sharing data across organizations and business processes you don’t need data governance.

According to Professor Quinn, change happens when someone is “jolted out of his comfort zone…driven to clarify the result he wanted to create, to act courageously from his core values, to surrender his self-interest to the collective good, and to open himself up to learning in real-time.”

Are you ready to get out of your comfort zone? Then maybe you are ready for data governance!

(P.S.: I’m discussing data governance yet again with Initiate Systems CTO Marty Moseley in a December 3rd webcast. Register here!)

Photo by p_x_g via Flickr (Creative Commons License)

Le Plus Ca Change: Business Intelligence Evolves

In which Jill explains a certain je ne sais quoi when it comes to BI.

I’ve been in and around Paris and consider myself pretty Paris-savvy. But Paris has changed. For instance, there was a used bookstore in the 8th arrondissement that would provide a cool haven and a thick black coffee on Saturday afternoon. It’s gone now. And my old apartment, owned by the ex-ambassador to Liberia, has been recently renovated, no longer one of the Seine’s grande dames but more like a sterile government building. Then there was my favorite brasserie, Le Verneuil, tucked deep in the heart of the 16th, its surly waiters insisting that the salad arrive après the oysters. Le Verneuil was a respite for French women doing their daily shopping, expatriate hipsters, and urbane professionals, all seeking a hearty prix-fixe lunch and a chilled Sancerre. It’s gone now, but it was there. I have the ashtray to prove it.

I’ve been in and around business intelligence, and consider myself pretty BI-savvy. But BI has changed. For instance, there are new dashboard tools now that are more user-friendly and efficient than ever. Open source has dramatically reduced the cost-of-entry, and applications can be just as complex and differentiating. Columnar databases have also delivered cost savings and increased processing speed. New development methods are emerging. And BI is in the cloud, offering targeted solutions for companies short on resources or thin on development chops.

Back to Paris for a minute. While the city has endured changes, many of them ill-advised, certain stalwarts persist. My Passy metro station is exactly as I left it (minus a few cigarette butts). The M6 train still deposits me at the Saturday market at Corvisart, itself a decades-old presence, right down to the goat heads suspended from the butcher’s stall and the white asparagus abundant in spring. The Hotel de Ville, the Arc de Triomphe, the Tour Montparnasse—itself a controversial and unwelcome symbol of change in the 1970s—and the venerable Eiffel Tower endure. Indeed, they are part of the permanent Parisian landscape.

And so it is with BI. Whatever evolution occurs, there are certain principles—best practices, if you like—that live on. Creating a sustained development pipeline based on business requirements is a BI staple. So is managing diverse BI development efforts under one program umbrella. Acquiring and retaining BI-specific skills, and enhancing them over time, is a proven best practice. And delivering data that is truly integrated—not just co-located—to support evolving analytic capabilities is critical, as is the ability to manage and support ever-growing data volumes.

The fundamentals that have shaped BI are consistent, no matter what side of the firewall you’re on, no matter what tools you use, no matter what neighborhood you live in, no matter how you eat your oysters. There may be changes, or even wholesale replacements. Consider them carefully and adopt them when the time is right. But just in case, be sure to steal the ashtray.

photo by pedrosimoes7 via Flickr

It Doesn’t Work Like That: BI Development Myths

In which Jill debunks some BI myths and kills your buzz.

When I was a little kid I would travel by air to visit my grandparents. In those days, PSA was the popular airline, flight attendants were called “stewardesses,” and we all romanticized air travel. When I grew up, I wanted to be a stewardess so I could wear go-go boots to work every day. And I was convinced that the luggage conveyors were part of a vast, subterranean network of moving beltways that transported my luggage as I flew to my destination, where it would rise from the earth and reunite with me on the other side.

“It doesn’t work like that,” said my father.

I hadn’t learned the word “buzzkill” yet, but if I had, I would have used it often with my father. And sometimes my clients should use it with me. This is because we often find managers in both IT and the business who have misinterpreted rules or learned fraught practices for BI development, formulating ineffective processes based on a set of mistaken assumptions or extrapolations. And they’re crestfallen when things don’t work out as planned.

Take the concept of the “single version of the truth.” When the phrase is mentioned, many imagine a huge, centralized database with single, enterprise-sanctioned data definitions that have been blessed by everyone via widespread consensus and executive sign-off. The database rests in the middle of a complex set of business applications, which consume its pristine and static data forevermore.

It doesn’t work like that. In reality, BI users need to see the data differently depending on where they work, what they do, how they interpret and use it. A product hierarchy in the Finance organization may be defined differently than a product hierarchy in Marketing. The company may be able to define a term at the enterprise level but that doesn’t mean there’s a single, sanctioned definition for each data element. When it comes to data, context matters. This means that as that data changes along with the business, data dimensions and definitions can likewise change, rendering the data warehouse less of a centralized behemoth, and more of a dynamic platform—or set of platforms—for the provisioning and processing of dynamic data. (See Evan Levy’s TDWI article, “SVT No More” and Peter J. Thomas’ blog post on the topic for some more myth-busting.)

Another example is business requirements gathering. Many people think it’s a matter of interviewing a few subject matter experts, poring over existing reports, and perhaps having a facilitated workshop (formerly known as a JAD session) to collect and document user input.

It doesn’t work like that. Gathering requirements for BI has changed. It’s more structured and time-boxed, it’s increasingly driven by subject matter experts on the business side, and delineating business, data, and functional requirements is a best practice. Business requirements gathering has also become more automated as new tools provide persistent documentation and definitions that can be used to inform and refine subsequent development efforts. When done correctly, business requirements gathering not only ensures that BI conforms to business needs, it can drive a rigorous development pipeline.

Many managers and executives, new to BI but already sold on its strategic and operational promise, believe that if they start with a good plan success is in the bag. They’ll retain a consulting firm to build a BI roadmap and make some organizational suggestions to ensure that BI-specific functions exist. Then they’ll scout the organization for “who’s available,” to put on the BI project, with little or no regard for previous BI experience. (We call this “warm body syndrome.”)

You saw this one coming: it doesn’t work like that. The most successful BI efforts are ones in which at least a few key delivery personnel are seasoned, having done the work on past projects, and are able to mentor those who haven’t. Even a detailed roadmap reflecting a BI-centric methodology and prioritizing specific tasks won’t guarantee success if the skills and experience are missing.

The best BI development projects involve rigorous processes, experienced staff, an understanding of the development pipeline, and adherence to guiding principles for success. But too many BI teams rely on hope and imagination to get the job done. It doesn’t work like that.

Buzzkill.

photo by ToastyKen via Flickr

Rebranding and the Customer Experience

In which Jill argues that rebranding is in the eye of the beholder.

 “Watch your elbows! Coming through!” The outward briskness of the flight attendants is a physical manifestation of their collective intention, which is: “Let’s hurry up and feed these trapped masses so we can retreat to our jumpseats and read ‘OK!’.”

 “We have no implements,” a flight attendant replied when I asked for a spoon. I was 5 rows behind first class, where the tinkling of utensils was drowned out only by the clatter of the liquor cart rolling on its well-worn casters. The twitch at the corner of what was otherwise the straight line of her mouth betrayed her. We were both in on the ruse.

In an act of sheer passive-aggression, I stuffed all my dirty napkins into the seatback pocket, along with a dozen reply cards from various magazines—seven of them from a single issue of Vanity Fair—used the first-class restroom, and contemplated breaking the ultimate rule and texting some friends. I was in a bad mood, suggesting that the Stockholm syndrome is indeed alive and well at 35,000 feet.

Interestingly, this same airline recently rebranded. But rebranding is a hollow exercise if it’s not accompanied by changes in the customer experience. A revamped logo and a signature cocktail in business class hardly count when the flight attendants continue to patrol the cabin like martinets. In the world of customer loyalty what counts is the way your behaviors change. And no, you may not have the entire can.

photo by Aaron Escobar (via Flickr)

Rigor? We Don’t Need No Stinkin’ Rigor! The Importance of Process

In which Jill urges BI teams to roll up their sleeves and put process into practice.

Most of Baseline’s clients already have a general sense of their desired outcomes before they retain us. They need to launch a new project or begin a design or development effort, and they want the benefit of experience to start the right way.

The savviest clients welcome the knowledge transfer that accompanies working hand-in-hand with a consulting firm. They often take a “learn it, watch it, practice it, entrench it” approach. This lets them embrace change in an incremental way, incorporating new processes into their BI, MDM, data integration, or data warehouse development initiatives gradually, after putting them into practice.

But believe it or not, I’ve seen diagrams like this one scare the pants off of people:

Figure 1. Sample Requirement Process

We built this framework—simplified here—to instill a process for what didn’t currently exist: business-driven BI projects. Recognizing that true business-IT alignment was lacking, we worked together with the client’s key BI business sponsors to bang out a more formal process in which both business and IT would be accountable for ensuring that requirements drove BI projects.

When IT grumbled we weren’t surprised. Change invites discomfort. But we were amazed by the rationalizations for clinging to old ways. IT staff had been accustomed to throwing work over to some contractors who’d become fixtures onsite, filling in generic project requisition forms and write the odd SQL query. Indeed most of IT’s BI work was reactive. Most tasks were delegated, and most took more time than they should have. The fact that each of the steps in the new process required inputs, outputs, ownership, and delivery made some people in IT downright angry.

Consider manufacturing as a metaphor for IT development. As twentieth-century manufacturers embraced Henry Ford’s assembly line concept, they were ensuring:

• Predictable outcomes. By instituting repeatable processes, everyone knew what the end-state looked like.
• Easier detection of anomalies and defects. As processes make outcomes more predictable, outliers come into sharper focus.
• Enhanced productivity, since roles, work tasks, and handoff points are established and well-understood.
• The ability to track and measure productivity, quality, and desired outcomes, thereby driving further process refinements and product improvements.
• More accurate time and resource estimation, since initial scoping efforts can be informed by established process times.

As ironic as it seems, in BI—as in manufacturing—rigor actually invites flexibility. When everyone follows a sustainable development process, ownership, decision rights, and completion milestones are baked-in. Early error detection mitigates the need for reinvention and rework, allowing IT and business constituents to be clear about their commitments, and deliver them more quickly. BI teams can spend more on creative improvements, like enlisting new users, developing on-line tool and data training, and using social media tools for closer team collaboration.

Most of my new clients tend to want to talk about new technologies to acquire and organizational changes to make. What they don’t understand is that by embracing best-practice approaches to development and getting the process piece out of the way, they’re making room to have more substantive conversations about people and tools.

BI in Health Care—and Everywhere Else

In which Jill observes that the maxim, “Physician, heal thyself” can have several meanings.

Several years ago, Baseline Consulting received a blind Request for Proposal from an HMO. The RFP was for help building a BI strategy. Right up our alley. Trouble was we didn’t have many references in the healthcare sector. At that time our largest competitor had a practice dedicated to healthcare. While Baseline routinely won competitive bids in retail, financial services, gaming, insurance, communications, and other verticals, our competitor had healthcare locked up.

Moreover, like many consultants and vendors, we tend to be suspicious of blind RFPs. Being asked to answer a lot of complicated questions, and even divulge some IP, by a prospect where there is no pre-existing relationship, no referral, and no attempt at personal outreach can be a dicey proposition. One BI vendor of note refuses to even entertain blind RFPs. “When you get something out of the blue like that, it usually means you’re column-fodder,” their sales executive said recently. Blind RFPs are like the guy on the Times Square side street who wants to show you some nice Rolexes. You want to check them out, but you’re dubious.

The combination of these two factors led us to send the HMO’s contact a polite “thanks anyway” note, congratulating them for realizing the promise of BI in an information-rich industry, and wishing them luck on their BI journey.

Surprisingly our V.P. of Client Services received a call from the HMO contact right after she received our no-bid notice. Danielle was the HMO’s BI Program Director, and she was insistent. “We really want a proposal from Baseline,” Danielle said.

Our V.P. thanked her and explained that we were pretty sure who the competition was, and that we didn’t have their healthcare industry chops and thus had decided to forego the proposal process. But Danielle was unrelenting. She made her case, firmly explaining that the HMO’s evaluation process was multi-dimensional and involved more than just healthcare expertise. We would be given a fair shot at the business.

So we bid it, proposing our BI Portfolio service and roadmap, and waited for the inevitable “thanks anyway” e-mail. Instead, we received an e-mail from the HMO’s procurement manager informing us that we’d won.

In a meeting with the HMO’s CIO a few weeks later, still dazed by our unexpected success, we asked about their consulting evaluation process. We’d been honest about our lack of healthcare experience, and wondered why they’d picked us in spite of it.

The CIO replied, “You guys don’t get it, do you? You won because you DON’T know healthcare.”

My team and I could only look at one another.

 “What impressed us was your experience with customer intelligence,” the CIO continued. “You guys showed examples of the value of the 360-degree view of customer, customer profiling, and tracking a customer across his or her relationship with a retailer. That’s exactly what we need to do with our patients. We want your knowledge of retail. Honestly, that’s where healthcare’s headed.”

The CIO didn’t know how prescient he was. In the subsequent engagement and several more after that, we learned that applying customer intelligence principles from the retailers, banks, gaming companies, and other industries we’d worked with was nothing less than innovative in healthcare. After all, the idea of a  customer relationship lifecycle, with its myriad channels and touchpoints, mirrors the continuum-of-care goal of most of today’s healthcare providers . And all the user adoption challenges we’d seen in other industries paled in comparison to those in healthcare where physicians—notoriously set in their ways—now use BI to make smart decisions about patient care—not in an office or a cubicle, but at the bedside.

In an increasingly competitive industry where disruptive new entrants are taking healthcare administrators by surprise and the question of wholesale reform is not an “if” but a “when,” the patient-centric view is nothing less than strategic.  “We don’t need experience in healthcare,” the CIO concluded. “As it is, we already have more than enough ourselves.”

Photo by carlsonimkeller (via Flickr)

A Letter to Our Users, From Your BI Team

In which Jill writes a rebuttal letter to a rebuttal letter, this time from IT.

 

Two posts ago, I penned a fictitious (albeit observation-based) letter from a group of BI business users to their IT comrades. The post got lots of hits and tweets, many of them gently requesting equal time. (Okay, demanding it.) So I’m putting my IT cap back on and diving headfirst into the fray once again, this time with a rebuttal from the BI team.

Dear BI Users:

Thanks for your letter and for taking the time to write it. Sometimes we’re not sure you even know we’re here. In fact we’re working hard, and we’re grateful for any type of feedback.

Speaking of which, we invited you all to a Lunch & Learn session last Thursday where we presented a prototype of the Customer Event Management solution you’ve all been asking for. We’re one step closer to predicting the churn of high-value customers, but we need your input. Most of you accepted the meeting invitation, but only four of you showed up. What happened?

Okay, we don’t want to seem defensive but if you don’t feel listened to, well, neither do we. We understand that you’re not wild about those architecture and infrastructure conversations, and we try to shield you from that stuff whenever we can. But sometimes we need your approval for investments in foundational technologies. If IT indeed supports the business, both sides need to know what’s being supported.

But since you asked, we’ll tell you where we’ve been. We’ve been trying to explain to you that we can’t develop the custom software you’ve requested for a packaged price. It seems you all want Microsoft Office-quality tools, but we have a nine-person BI team here! And, not to burst your bubble or anything, but here it is:  there’s really no such thing as BI-in-a-box. All BI work is custom development. So, to answer your question for the 99th time: No, we can’t just “plug and play.”

We’ve also been delivering the 24x7 support you’ve wanted—or haven’t you looked at the SLAs we created? This stings a little, since we’re on call day and night. You don’t know this because you’re fast asleep while we’re loading your data and upgrading systems to support your requirements. After all, there are nine of us on the team, yet you want operational-class support. How many people staff members are involved in building our operational systems? (Answer: More than nine.) But we can’t get you guys to come look at the stuff we’re building for you. At lunchtime. With sandwiches.

Our conundrum is this: the business funds IT, so we’re beholden to you for money. Yet when we want to make sure your money is used well, we can’t get you to share where you’re going, let alone evaluate the solutions you’ve asked us to build!

And believe us, we’d like to fix the data as much as you would. But we don’t own the data, the operational systems developers do. And they say no one ever complains about it. Seriously, we are only as effective as the data we get from those systems and our understanding of the rules needed to fix it. We could put you guys in touch with our Accounts Payable/Accounts Receivable system developers and you can get them to write your reports. No? We didn’t think so.

Look, we’re happy to rethink the way we work together, to define new rules of engagement. We’re even happy to fund a resource to shadow you while you do your jobs so we don’t have to keep on asking you what’s next. But we need you to meet us halfway. Shoot, we need you to meet us, period. How about lunch?

You know where to find us,


Your BI Team

Photo by footage (via Flickr)

Dear IT: A Letter from Your Business Users

In which Jill writes a rebuttal letter on behalf of her business clients.

photo by aflcio2008

In my last blog post I told a story of a client who, in an effort to explain the value of business intelligence, wrote a letter to his CEO explaining the business value delivered by BI and the ROI projections for newly-integrated data. The letter worked. The BI team got the funding it needed to propel itself from project to program.

But at many companies it would take more than a letter and a value proposition to convince business users of the value of BI. Knowing some of the harsh realities at other companies, I’ve penned a sort of rebuttal letter from the BI user community back to IT.

Dear BI Team:

Long time no see. And by that, we mean where the hell have you been? We know you’re around. Seems you’ve been complaining to our execs about the lack of user adoption. And that we never engage you. And now you’re mad that we’ve hired consultants to come in to help us build a roadmap.

Well guess what? We had no choice. While you’re letting that big database vendor buy you lunch and having dashboard bake-offs and devising new IT standards—again—we have work to do. This may have slipped your mind, but the company has just downsized. Despite this rough patch, our responsibilities haven’t changed. Remember the CEO’s company-wide webcast in January? The one where he promised that in the coming year the company would cut costs while increasing customer acquisition and driving innovation? Well, that’s our job. And we’re trying to get it done.

Frankly we’re not sure whether to feel resentment or resignation. After all, we know what you guys have been spending and, frankly, all that funding should align with our needs. You’ve been loading data warehouse tables for as long as we can remember. But no one’s asked us if we wanted any of that data. And if we hear the question, “What keeps you up at night?” from one of your business analysts one more time we’re going to throw the poor bugger down the elevator shaft. Odds are he’ll bounce off one of those big servers in your data center.

We read someplace that IT is supposed to act as a supplier to the business. We deal with suppliers all the time. But none of them expects us to understand their internal processes—they just help us solve our problems. You guys insist on us working within your framework. Whatever it is.

Here’s what we’d like. We’d like to track the results of our marketing campaigns by the hour and make continuous adjustments. We’d like to monitor and respond to the buzz about the company through social media. We’d like the account reps to know about support and payment issues when they’re writing customer bids. We’d like management to understand the true profitability of our products, not just their revenues. We’d like our numbers to reconcile between finance and sales.

So while you’re mounting your campaign against our consultants and lamenting our shoddy technical skills, why don’t you calendar a face-to-face meeting with us and ask us about this list? No, this isn’t another requirements gathering session. Instead, it’s us offering you an opportunity to participate. We’re hopeful that maybe you can help us solve some of these problems? Or maybe it’ll just be business as usual.

In characteristic anticipation of something new,

Your Users

Dear CEO: A Letter from Your BI Team

In which one of Jill’s clients puts his team’s success in writing.

 

photo by spitecho

Baseline Consulting was recently engaged by a large pharmaceutical company’s business intelligence team to give BI a shot in the arm. Paul, the Director of BI, had been frustrated with the general lack of support he was getting from business stakeholders. Our goal was to help Paul and his team to formalize their BI program, lay out an 18-month roadmap, and build a pitch to solicit additional funding from lines of business.

“They’re taking us for granted,” Paul explained when we asked about his users. “They don’t understand the complexity of their requests. They think everything should be cheap and easy and take four weeks.” Indeed, the business users saw the BI team as just another IT development organization. Rather than engaging them in sustained requirements conversations and discussing business outcomes, they had marginalized the group as nothing more than reporting order-takers. There were no rules of engagement. There was no collaboration.

Ironically, the BI team had a pretty good delivery record. Their analytical applications were comprehensive. Despite widespread disaffection, user adoption had increased, and data quality had improved over time. In fact after reviewing the team’s progress we recommended that Paul stop focusing on battling the various line of business managers and go straight to the top: he should go talk to the CEO.

Paul demurred. A meeting with the CEO was outside his comfort zone. He wasn’t even sure he could convince his boss, the CIO, to support the idea. He didn’t know what points to bring up, and he feared he might even flub his lines. “This could turn out to be career-limiting,” he said nervously.

We suggested that before he scheduled the dreaded meeting, he write the CEO a letter. The letter would outline the BI team’s contributions to date, discuss the potential of BI to solve additional business problems and drive competitive differentiation, and explain the opportunity cost of cutting BI investments. We agreed that if, after writing the letter, Paul was still nervous about meeting with the CEO, we would find another way to tell the story of BI to the business and get buy-in.

Writing the letter brought up some difficult issues. Paul had to be honest about his team’s ability to speak the business’ language. He also admitted that the BI development process was squishy and roles within the team weren’t circumscribed. This left the business users guessing about the team’s delivery process, resulting in incessant questioning about timelines, functionality, and value.

We worked together with Paul to write a letter to the CEO that was well-crafted, clear, and made a compelling case for renewed BI investment. It explained why the firm’s physician management program would flounder without the team’s data expertise; outlined how much money the company could save by pushing out accurate physician spend figures; made the case for integrating R&D data; and outlined the strategic initiatives that would be BI-enabled. It was also specific about new resource needs, technology upgrade costs, and why they were part of a larger vision for an information-driven enterprise.

Our bet was that the letter would energize Paul, giving him the confidence—and the ammunition—he needed to schedule that in-person meeting with the CEO. Instead, with the CIO’s enthusiastic approval and a little relief, Paul decided to e-mail the letter to the CEO.

We weren’t surprised when, upon receiving the letter, the CEO called Paul to request an in-person meeting. But Paul was.

Nevertheless, he bit the bullet and led a meeting with the CEO, the CIO, the V.P. of Sales and Marketing for the U.S., and several other business leaders, leaning heavily on our letter, but explaining historical challenges and additional opportunities for BI and integrated data. At lunch afterwards, we celebrated the fact that the CEO had a new appreciation for the overall value of BI, and a new level of commitment. And that Paul, flush with his own success and looking forward to a new way of working, had increased his team’s budget by 30 percent.