Keys to BI Acceptance

This is not meant to be an inclusive list, but rather three of the keys that I found to be interesting from the TDWI courses I have attended so far.

A Good Data Steward - this person exists to makes sure the definition of a product, unit, dollar, and every other attribute of data is consistent across the enterprise. The definition of data is key to quality data at the other end of the project. It is up to the Data Steward to achieve this consensus without imposing it. When you consider projects that span across a legacy source and a source from a business merger or acquisition, this can be very difficult to accomplish. As I sat and ate lunch today, I spoke with a gentleman who was complaining about this very thing. Someone had not defined the data correctly, and produced reports with this inconsistency. "It was about 96% accurate," he said. Well, is 96% accurate good enough? Will it give the people who used that information the ability to make informed decisions? Maybe, but consider that it is not. Consider that nobody realizes its wrong until it is too late. You probably will not get kudos for providing a system that works as intended or better. You will surely hear about it if it doesn't work. It doesn't matter if you fix it either. The perception is there. It will become that "system that always produces wrong data."

Good Usage Data - Not as straight forward as a data steward, good usage data can provide the means to a well accepted BI Program. The natural progression of a good BI Program is to evolve into something different. After so many iterations of change, without good usage data, you may never know x number of reports, tables, or facts are no longer being used because the department that needed them is no longer in the company. Your job of fighting for batch time becomes easier if you can lessen the load by getting rid of those unused items. Again, it may only take one time for the BI system will gain the reputation of the "system that is always late" or "using too many resources". Usage data can also help gain the ability to effectively market the BI Program to its users. Imagine, "Any BI Program: over 1 billion queries served," or "Any BI Program: 15 minutes could save you 15% on the bottom line." Well, even though that is not a stretch, at the very least usage data can provide you with data to help budget IT resources including capital. "At the current rate of increase in network traffic we are going to have to...." This lets you avoid the bad system reputation.

*Warning* Unabashed schmooze alert *Warning*

Good Program/Project Manager(s) - These guys have it tough give 'em a break! :)
If a project or program does not meet its intent, is late to start, or can not be maintained then it does not matter how well it is documented, how accurate it is, or how nice it looks. Managing the timing and dependencies of projects or tasks, resource planning (availability, capability, roles), effective time estimation, budgeting, adhering to schedule (overcoming roadblocks, personnel issues, under estimation), risk assessment and management are some of the critical roles they play that directly influence BI Acceptance.

BI and the Tools of Diplomacy: Summits and Treaties

In my last post I explored the importance of language & communication in diplomacy and, by extension, the BI practice. In this post I'd like to consider two more tools of diplomacy and how they can be applied to the BI practice.

The Summit

A Summit provides a forum where all sides have the opportunity to speak directly with each other in a highly focused and most importantly, face-to-face format. In today's business environment it is too easy to fall victim to the limitations of email, telephone or even video communications. Even with the best video conference, few mediums of communication replace the extraordinarily "high bandwidth" of physical presence. (As an example within BI Consulting Group's experience, read my colleague Ed Martin's recent post reporting on our company-wide Summit held last week in Minneapolis.)

But common focus is also important. Well-organized summits often have a stated purpose agreed upon by all participants before or immediately at commencement. Sometimes ground rules even require that participants not leave until specified goals are met (think the Catholic Church's "White Smoke" summit -- or Conclave -- of Cardinals that elects a new Pope).

Of course a typical run-of-the-mill business meeting is a similar exercise... But when signficant, concrete progress must be made between parties of disparate backgrounds, framing the discussion in the specific terms of a Summit can be an effective way of setting the stage for the quality of interactions that will ensue.

The Treaty

The ultimate formal goal of any diplomatic effort is the execution of an agreement between all parties that sets specific parameters for behavior. The most obvious parallels in the BI practice are requirements documents, functional specs and service level agreements. In each case, the agreement clearly specifies the "rules" under which the signatories are required to behave.

In BI of course, one of the actors is the technology itself. In a Treaty, individual countries are held accountable for the performance of their borders, regulations and tarriff; in a Service Level Agreement, the IT support staff is accountable for the timely and stable operations of servers and applications. Well-written Treaties, SLAs and really any legal contract are useful to all signatories because they clearly define the expected performance of each participant and actions to be taken when that performance is breached. But the key concept is "well-written" -- a good agreement is clear and specific but not so obtuse that a lawyer is needed to interpret it.

An important component of an effective BI "Treaty" is the data validation report. A good BI implementation will include data audit reports -- confirmed as authoritative by all parties -- that compare warehoused data against source transactional data. These audit reports serve as the arbiters of performance that determine objectively and decisively whether the warehouse (in the "Tech Nation") is holding up its end of the Treaty by correctly reflecting source data (coming from the "Business Nation").

I plan to explore more tools of diplomacy in posts to come (trying to work "the Spy" into this discussion!), but as usual, in the meantime I'd love to hear your feedback and especially any other examples of Treaties and Summits in the BI practice.

The United Nations of Business Intelligence

I find many aspects of my work very fulfilling and many ways I am proud of my job. However, one of the least pleasant is the industry-standard title ascribed to the role I typically play in a BI implementation: "Business Analyst." It's probably one of the most understated job titles of all time and worse, the ultimate cocktail party conversation non-starter. Who invented the term anyway? It's stupid and I'm tired of it.

Of course the natural response would be: "You may have a point but what else would you call it?" Indeed, how else would you name this role, which by its nature has no traditional "profession" of its own but instead straddles a kind of no-man's-land between professions -- that of clients (who need the assistance of technologists to achieve business objectives) and of technologists (who perform the work required by the client)? And how to come up with something sexy to boot?

Meeting with an old college friend years ago, I tried laboriously to explain the nature of my work in the glow of a second glass of Zinfandel (or was it a third?). My friend asked me an intriguing question: Did my professional endeavor in IT have any relationship to my undergraduate experience? At the time I was over ten years out of college and a bachelor's degree in Foreign Service (aka International Relations) -- and 9/11 was still raw in my mind, so I was bemoaning the fact that I chose to pursue opportunities in software development rather than diplomacy. But, perhaps thanks to that same glow from the wine, I took a look at my job from a different angle and saw something very interesting: The IT roles that I had performed often involved a certain degree of, shall we say, mediation. Thinking it through, I realized something more fundamental: while performing various IT roles, I often perceived an acute need for mediation between the "suits" and "geeks" and I found myself drawn into fulfilling that need, partly because I liked doing it but largely because my skills were well-suited to that role.

From that point on I began to see more clearly the importance of the mediator in successful IT endeavors. Over time I have also come to believe that this role has much in common with the practice of diplomacy -- particularly within the specific discipline of Business Intelligence, where interactions between clients and technologists become uniquely more intense than in a typical IT project.

What I'd like to do first is explain the parallels I see between diplomacy and the role of the classic IT Business Analyst. Then I will take the next logical step: to explore what lessons from traditional diplomacy we can apply to the practice of Business Intelligence in particular. Hopefully I'll shine a fresh light on this important role and perhaps even inspire somoene to devise a job title that's far more sexy than "Business Analyst."

Traditional Diplomacy and the Traditional Business Analyst

In traditional diplomacy, the diplomat mediates between what I'll call "physical" nations: the US and China, for instance. A BA does essentially the same thing - but between "metaphorical" nations: the client (aka "The Business") and the technologists (aka "IT" or "Tech"). Let's consider some hypothetical characteristics of physical nations and their parallel among metaphorical nations: [Please understand that my examples are sometimes oversimplified generalities intended purely to illustrate the point and not pass value judgements on any country or group of people]

	Physical	Metaphorical
Goals / interests / agenda	US: Increase industrial production; decrease cost of healthcare; decrease energy demand; promoting the global spread of democracy China: Increase industrial production; increase citizen wealth; increase energy supply; promoting the harmony of Chinese society	Tech: Work with cutting-edge technology and phase out old technology; build resumes Business: Increase [revenue / profit], decrease costs, build resumes
Language	US: English China: Mandarin	Tech: SQL, Java, HTTP, SOA, "geek speak" Business: Quarterly financial statements, Balance sheet accounting, "corporate speak"
Natural resources	US: Wheat, coal, consumers, Hollywood China: Cheap and abundant labor, cash	Tech: CPUs, RAM, computational thinking, technical skills, hard work, creativity Business: Money, market-oriented thinking, business skills, hard work, creativity
Cultural values	US: Individualism China: Collectivism	Tech: Collaboration Business: Competition
Currency	US: Dollar China: Yuan	Tech: Game rooms, private office space, logo wear, money Business: Titles, adminstrative assistants, corner offices, money
Fashion	US: T-shirt & jeans, Little Black Dress China: Mao suit, qipao	Tech: Logowear, boardshorts, Tevas Business: Business casual, suits

Despite the oversimplifications, the parallels are compelling.

Given this common concept of a "nation," let's consider the professional challenge of the traditional diplomat:

How to foster a trusting and productive relationship between his employer's nation and other nations (at least, those that his employer considers important)...
So that his employer's nation can effectively apply its unique natural resources to pursue & fulfill its own agenda...
And the citizens of his employer's nation can be happy and prosperous.

In comparison, the challenge of the Business Analyst is basically the same but with notable differences:

How to foster a trusting and productive relationship between ALL nations...
So that ALL nations can effectively apply their unique natural resources to pursue & fulfill their agendas...
And the citizens of ALL nations can be happy and prosperous

The Business Analyst is in the unique position of being required to ensure that the interests of all nations are being satisfied. This mission is more akin to that of the United Nations Secretary General -- which is also not an easy job but I'm sure Ban Ki-Moon has an easier time at cocktail parties. And the chauffeur would be nice too.

In my experience this perspective has proven to be a useful way to understand and manage the dynamics of interactions between IT and "The Business." For my next post I will consider some specific tools and techniques of traditional diplomacy and how to apply them to a Business Intelligence practice.