In the late 90s, I helped build a data warehouse of click-stream information. We used cutting-edge technology to collect, transform and load data into the warehouse. We built a sophisticated Web-based interface for end users to access the information, and we spent a lot of time and money making sure the system was available whenever business users needed it. The problem we faced, however, was that business users didnt actually need what we had developed. At one point, the data warehouse crashed and someone on my team said, Lets see when they notice. It took nearly 30 days for someone to realize that the high availability business intelligence solution wasnt available.
Why didnt they notice? When did the mission critical application become not-so-critical? The system ultimately failed because it was designed to do so. Because the focus was on the technology rather than on the business, irrelevancy as an unintended but inherent design flaw was there from the beginning.
After the demise of the project, I spent a lot of time considering how things could have gone differently. One day I had a sort of epiphany when a member of the team described our failed solution by saying, We gave them exactly what they asked for, but not what they wanted. This team member unwittingly summed up the problem in a single sentence. We had involved end users in the design, but we werent speaking the same language. They said customer and we heard session. They said impressions and we heard page views. In some cases we got it right, but in many we didnt. Still, we could look at the signatures on the design document and say, We gave them exactly what they asked for (but not what they wanted).
Here are four ways to break down the barriers between business users and technologists:
- Focus on the solution, not the technology. It is more important to develop an actionable, accessible business intelligence solution than it is to use cutting edge technology. Spend less on technology and more on business understanding. This not only reduces your overall risk, but it helps you leverage your IT investment.
- Break the project into manageable waves. It is easier to align technology and business in a business intelligence solution when projects adopt short development and implementation cycles. If a project takes nine months to deliver value, it is most likely solving a problem that is nine months old. More importantly, it may not be solving the problem at all. Quick implementations and response times mean that course corrections can be made more frequently. At Sharp Analytics, it typically takes us four weeks to roll out the first wave of a BI implementation. Subsequent waves are usually shorter and one-off requests are handled almost immediately. Users see immediate results and immediate value.
- Require business expertise. Technology is critical, but it cant stand on its own. Somebody needs to be able to translate business requirements into technical specifications. Write business rules so that they are specific enough to avoid term confusion across teams.
- Make information accessible and meaningful. Analysis for the sake of analysis never did anyone any good. Run every report or key performance indicator through the What will this change? filter. If the answer is nothing, then dont waste your time collecting, organizing and reporting the information. Making data accessible requires understanding your audience and the issues they face.
A focus on the business requirements will lead to solutions that incorporate business intelligence, location intelligence, market intelligence and competitive intelligence in the overall solution. Most importantly, a focus on the business need will result in a solution that business users care about - a solution that will impact the business, as better decisions are made based on better information.