Inside the Biz with Jill Dyche

Six Telltale Signs of IT Failure

In which Jill puts her ear to the ground—and hears that giant sucking sound.

We see high-functioning IT organizations that manage their pipelines according to weighted prioritization frameworks that account for business value, available data, and consensus of need. They manage their assets proactively and apply the right skills. They know how to talk to business people.

All this sounds like standard operating procedure, right? Not so fast. There are IT organizations that wait for the business to engage, assign resources haphazardly and without forethought, fail to scope work, and use jargon so thick it would clog your arteries if you drank it.  The well-worn adage is that if you look up and you see that you’re in a hole, stop digging. If there are tools of the trade for IT mediocrity, these six are the shovels:

1. The CIO is all about keeping the lights on. There have been some high-profile decisions in the last several years—News Corp and Harrah’s come to mind—of companies deciding not to replace their former CIOs. The implication is that these guys simply keep the machines humming, right? Show me a company that measures its IT leadership by system uptime and I’ll show you a bunch of unhappy IT employees. Or a company that’s increasingly offshoring core skills.


2. IT is viewed—and run—as a resource pool. One client recently tried to explain to me how its BI team members were also responsible for delivering on non-BI projects. Uh oh. Spreading resources too thin risks blurring the lines between projects, rendering completion vague and inchoate.


3. IT management tries to squelch information or suppress feedback. A data warehouse manager recently sidled up to me after an executive readout and said, “Thanks for not throwing us under the bus.” We wouldn’t have—the data warehouse while immature wasn’t a showstopper—but he thought it might be. The point is that he attended the readout anyway. Many IT managers instead choose to circle the wagons, not participating in open forums that might result in reprioritized work tasks or suggested improvements. Worse, they’ll actively spread negative buzz about a new project or the group that’s leading it. That giant sucking sound? It’s the competition hiring your best people away and leaving you with the paranoid jerks.


4. Lack of business-IT alignment. More specifically, the business won’t consult IT before commissioning outside vendors. It’s an erosion of confidence and trust. Despite our nudging, a media company’s marketing department refused to engage IT before building a CRM solution. Finally ceding to our pressure, marketing agreed to put the internal IT organization its vendor list. IT had to respond to the RFP on equal footing with the CRM vendors vying for the work.


5. No closed-loop success measurement. Perfunctory costing worksheets hastily completed and subsequently forgotten are far more pervasive in IT organizations than aligning IT projects with business priorities. So what is success, anyway, and how do we measure it? We wrote ten thousand lines of code. Our data warehouse has 700 tables, and 450 of them contain over 10 million rows. We’re up to twelve terabytes. And yes, we’re ignoring you.


6. No repeatable rules-of-engagement. You simply cannot gather sustained business requirements by leaning in someone’s cubicle doorway dizzily scribbling into your Moleskine pad. Nor can you represent clear business needs by asking someone what data elements they want, or replicating their Excel spreadsheets in the BI tool-du-jour.

Here’s another indicator we’re seeing more often: if someone who works in your company won the lottery, would losing them put you in deep doo? If so, get a shovel and start digging.

photo by lanchongzi 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

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.

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.

My Blog is a Weapon. (Not Really. But Hey, Then Again...)

Okay, I have a blog, and I’m not afraid to use it. Welcome to my new Inside the Biz blog on baseline-consulting.com. In this blog, I’ll be focusing on the business value of data and why we’ve only skimmed the surface of its potential. I’ll discuss why the question, “Would you like fries with that?” is NOT customer relationship management, and why information can mean the end of business as usual.

And hey! This blog is on Baseline’s own website, along with some other very insightful blogs, so guess what? We can dangle our participles, we can break the rules, dis the establishment, and get naked! Alright, maybe not get naked, but you get the point.

You see we—or rather the technologies we use—are data hoarders. Our accumulated contacts, e-mails, stock trades, bills paid, purchase records, expense receipts and hundreds if not thousands of other transactions are stored on our hard disks, online accounts, iPods, company databases, ERP systems, and other gadgets. Sometimes these are deliberate decisions, and sometimes they’re not.

Maybe you’re the kind of person that grew up thinking that all this data can be wrangled and corralled into a single capacious database. Maybe I grew up thinking that way too, and maybe, for a time, we were right. But the market is moving in a different direction, and it might be time for us to change our minds. To expand our thinking. To look beyond the comfort zone of technologies and toward developing new processes, indeed new cultures, that support managing our data irrespective of the platforms where it lives. Yes, as a corporate asset. (Sorry, I had pull that one out, but I promise from now on, I’ll use the phrase sparingly.) Because if we’re hoping to manage all our data from a central source, odds are we’re thinking in the past. And the problem of “infoglut” as it’s affectionately known is a problem that affects our collective future.

In this blog, I’ll be musing on new ways to access, manage, deploy, and use information for the betterment of our businesses. I’ll take on some sacred cows and challenge some of the established paradigms. I’ll make some suggestions for how to help our colleagues and, more aptly, our management, to approach corporate information the right way.

After all, no snowflake in an avalanche ever feels responsible. My mission for the Inside the Biz blog is not to prevent the snowfall, but to harness the snow for good, use the right tools to make great snowmen, and prevent the disasters before they befall us.