Tips for Business Intelligence

There was a short set of slides posted on BaselineMag.com outlining 6 Tips for Business Intelligence Success. Make sure you check it out. The tips are:

1. Understand your enterprise
2. Involve key users
3. Make sure components of a BI system work together
4. Be mindful that different employee groups will want different interfaces
5. Consider making applications broadly available
6. Create a competency center

Some of these tips are applicable to normal business analyst engagements as well.

Knowing when it's good enough

A business uses cost-benefit analysis as one of its evaluation criteria when deciding whether to pursue an opportunity or not. One concept central to this is the assessment of potential risks. To me there are a few components to risk assessment:

1. Likelihood of the risk materializing. What's the probability of the risk becoming a problem?
2. Potential cost (monetary, compliance or reputation) to mitigate the risk. How much is it going to cost you? This also includes implementing any mitigation strategies.
   

Combined, these factors provide a value to each risk. Risk assessment can be applied in many different areas:

• Managing the risks encountered in a project.
• Understanding the importance of a defect or bug in a system.
• Managing financial assets.
  

For the purposes of this post I'm only going to write about the second item.

What do you do if you find a defect or bug in a system? You evaluate it to determine whether it's a show stopper or whether you can proceed despite it. Creating bug-free software is the ultimate goal but it has cost and time implications. Here's a quote from an article, They Write The Right Stuff, from Fast Company about a specific software system.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

The piece of software in question runs the NASA space shuttle. The consequences of failure could result in the deaths of the astronauts, the loss of a multi-billion dollar piece of hardware and many years of setbacks to the space program. Many of the systems we deal with in the business world do not have this level of criticality. In my past jobs I have worked with time sensitive trading systems where 1/2 second delays mean losses in the $10,000's of dollars. On other projects, variances in marketing and market research data were explainable ("Yes, someone did purchase 50 rolls of toilet paper and it skewed the numbers.") We need to understand when something is good enough as it is instead of always trying to be perfect.

How "bad" requirements can stifle innovation

A great way to curb innovation and creativity is to impose improper limitations.

Limits by themselves are not bad. Clearly a project needs to operate within a set budget, resource allotment and delivery schedule. These types of constraints can actually spur creativity and novel solutions.

But let's think about business requirements and how improper requirements can hinder the process of innovation. More specifically let's examine how requirements that are not design independent can unfairly constrain a solution to a business opportunity (or problem.)
Many times during my requirements gathering and elicitation engagements I have heard subject matter experts and clients tell me their requirements based on existing applications and functions. They assumed that the products delivering the new capabilities they desired would actually be enhancements to the existing applications. In truth, the eventual solution may be based on an existing one (particularly with software products), but this is not always the case.

Suppose our company designs cars. The newest set of requirements for the upcoming model year state the driver has the ability to:

1. Determine where he / she is (e.g., location) at all times.
   
2. Receive driving directions to a user specified address.
3. Interact with the system through the car's dashboard.
   

By themselves, these requirements seem fairly benign. Suppose our project advanced to the stage where we are developing a solution to meet these needs. Our team decides that a global positioning system (GPS) is required. Based on the third requirement, it is decided that an on-board system similar to Onstar is appropriate. Implementing this solution requires our company to purchase units of the GPS product and integrate it into our assembly (line) process.

Nothing appears terribly wrong with the proposed solution, but what if the car model in question is marketed to first time car buyers and students (people who want to be sporty but on a budget.) Large scale changes to an assembly line are costly. Acquiring GPS units and integrating them into a car's electronics are expensive. The cost of the new model will increase as a result.

Because of the third requirement we have ignored other solutions that may have been more optimal. Perhaps we could have offered portable GPS systems (e.g., Tomtom's) to people who purchased our vehicles. Our needs would be met in a more cost-effective manner.
The third requirement constrained our innovation and creativity to the point where a more optimal solution was missed. This is how a requirement that is not design independent can stifle innovation and creativity.

Understanding the goal

When gathering requirements, one of the most important things to understand is the answer to the question, "Why?"

The answer to this simple question will provide clarity and guidance to your requirements gathering efforts. This is because you will be able to evaluate whether the requirements you are gathering will solve your problem (or capitalize on the opportunity.) Thus, a business analyst should always seek to understand the underlying business objective.

Suppose a client receives five sets of different reports. The client is concerned because it takes him a long time to get the necessary reporting. His request is for his five reports to run faster so he can perform his analytics. The business analyst (doesn't probe any deeper and) works with the IT developers to optimize the SQL used in the reports, create database views to reduce the number of multiple-table queries and revamps the reports so they are more efficient. Finally, the business analyst presents five optimized reports. The client promptly looks at each report, takes two pieces of information from each and then creates a dashboard sales report for one of his customers.

If the business analyst knew that the goal was to prepare a dashboard sales report, could a more optimal outcome have been achieved?

Here are a few comments about what happened:

1. The requirements were not design-independent. It was pretty much determined to rework the existing reports and make them more efficient.
2. Ultimately, a useful result was obtained however, it may not have been the most optimal one. The business analyst also ran the risk of not achieving the goal at all because the business analyst did not probe deeply enough to uncover the underlying objective.

If the business analyst had used active-listening techniques and probed the client, both of these issues could have been avoided.

How does your project contribute?

I recently attended a training session called Business Acumen. A good amount of the course's material was dedicated to understanding financial statements (the company providing the training was affiliated with the National Association of State Boards of Accountancy.) The rest of the course's material was based on the book, What the CEO wants you to know: Using business acumen to understand how your company really works, written by Ram Charan.
The main point of the book was that all businesses, regardless of their industry have the same underlying principles.

• Cash - Money and near-money equivalents used to fund a company's operations.
  
• Margin - The amount of money left over after paying off expenses (for a product.)
  
• Growth - The rate at which a company's business expands.
  
• Velocity - The rate at which a company's assets can be used to make money. For example, inventory turnover is a measure of velocity in some industries.
  
• Customer - Consumers or potential consumers of your products and services.
  

The interesting part of the training session was trying to understand how your activities (or project) contributed to the well-being of your company. Basically, a project should be contributing to one of more of these elements. For example, a company setting up an e-commerce website would be trying to:

1. Increase the market for its products (especially if it did not have a web presence.)
   
2. Increase the growth rate for the business by increasing the potential sales opportunities.
   

If you or your project is not contributing to one or more of these principles, then you should reevaluate what you are doing.

Getting past the fog

There was an interesting article on Yahoo! recently titled, A Guide to the Latest Batch of Corporate Buzzwords. It's a short piece and examines the usage of corporate jargon and lingo.

A new crop of buzzwords usually sprouts every three to five years, or about the same length of time many top executives have to prove themselves. Some can be useful in swiftly communicating, and spreading, new business concepts. Others are less useful, even devious.

Delayering, rightsizing, unsiloing ... What do these terms mean? Step back and think about how much terminology you use each day that an outsider would not be able to understand.

Using inappropriate language will only further confuse and obfuscate your message. Simplicity and clarity should be valued above all else.