In this blog series, I’ve outlined my method of evaluating and implementing analytics projects; providing tips, lessons learned and helpful advice for readers looking for analytics solutions and are in need of a BI vendor. By now, following Part 1 and 2, you will have evaluated qualified BI vendors, moved through the Proof of Concept trials, and made your vendor selection. In Part 3, I’ll provide insight into vendor contracts and, finally, best practices for initial project implementation.

Vendor Contracts

There is a lesson to be learned from a major mistake I made in my first implementation project — I got the legal and finance teams involved way too late. We had already conducted the POC and had picked the vendor that we thought would be best for our product. We had even settled on the pricing both for the product and implementation services. I thought we were done and ready to sign on the dotted line. Wrong. It’s details time.

As soon as the legal and finance teams became involved in the project, a couple of things became clear. First, I would need to spend significant time reviewing the project with them, explaining the business purpose, explaining our selection process, discussing security, and more. We even had extensive discussions about why we were buying a solution instead of building our own (hint: building is always more expensive and time-consuming). This took a significant amount of time. My advice, get these teams involved from day one so they can understand your decisions as you make them.

The second thing that became very obvious very quickly was how many little details I missed. Following is a list of some of the many finance and legal issues that demand early resolution:

  • Contracts with existing customers: You’ll need to change the terms so that they understand that data will be handled/processed by a third party (the BI vendor).
  • Right to audit security: Do your customers have the right to view security audit documents provided by your BI vendor?
  • Service-Level Agreements: Does the BI vendor’s contractually obligated uptime match what you are promising to your users today?
  • Professional service budget: What happens if you don’t use all the money? Can it be used for other projects?
  • How do you define a “project”? Is the BI tool only to be used for a single application or can it be used to power another effort such as your internal metrics?
  • What happens if the vendor decides not to review the contract after the term expires? How much time do you have to implement a new solution?
  • When does the meter start running on pricing? Do you pay for the BI system while it’s still in development or only after sign-off is complete?
  • Intellectual property: Where does the vendor’s application end and yours begin?

Getting Started: Implementation

Vendor chosen, contract signed — it’s time to get going! At this point, all the aforementioned “tools” you’ve created during your vendor evaluation will be beneficial to beginning your implementation and knowing what exactly you want to show your users. Having the user experience persona as well as a complete “dictionary” of the charts, metrics, and dimensions you need, will help guide you.

During my initial implementation experience, we burned through a significant part of our services budget just trying to get a handle on what kinds of questions we needed to answer, what data those answers required, and where that data was located. For the second project, we got a little smarter. Based on my lessons learned, I recommend providing your vendor’s project team with a spreadsheet that includes the following information for each analytic to be displayed:

  • A sample of the chart you want to show (e.g. a bar chart with dual axes);
  • A list of the metrics required by the chart (e.g. net revenue, customer count);
  • A definition of each calculation required (e.g. uplift = current month performance – baseline performance, baseline performance = rolling 12-month mean);
  • The dimensions required (e.g. by year, quarter, month, day, region, product, team, etc.); and
  • The next level of drill-down (e.g. click the bar for the month to see the specific items that make up that month’s performance).

Providing a simple dictionary of charts, matrices, definitions, and dimensions will accelerate the initial phases of implementation and save money along the way.

Quality Assurance is Key

Following my first BI implementation, I’ll never forget sitting at a meeting with our CEO where we revealed the results of our hard work from the past month. One of his first comments was, “Why does this chart say the cost of this type of repair was $27 million? Our whole budget is less than $20 million. This can’t be right.”

He was, of course, correct. Why? We hadn’t performed quality assurance (QA) to the level we should have in that first project. Although we spent hours reviewing charts, testing performance, and tweaking colors and layout — we had missed an issue with the data we were providing the vendor. We had built a process to convert all expenses from local currency to U.S. dollars, and then forgot to change the loading process so that it used the new converted data. Rubles mixed with Yen mixed with Pesos. We never noticed it, but the CEO sure did.

For the second project, I took steps to ensure this wouldn’t happen again. At the start of the project I formed a small team of people with expertise in various parts of the business to review each and every chart and make sure it made sense. We provided the team with a copy of the same data we provided the vendor for the POC and had them run the same calculations manually. No silly calculation errors this time around. Another lesson learned the hard way, but hopefully a lesson you can learn from as well.

Additional Tips

We made it through our first implementation successfully and in less than six months. The second, third and fourth implementations took less time and were equally successful. However, some tasks took far longer than others and I recommend you start on the following items early on in your project:

  • Product tiers: Do you have levels of BI such as basic, plus, and pro? What are the differences? How are these priced?
  • Sales training: You need to get the Sales team up to speed so that they can sell your new BI functionality. How will you perform both initial and on-going training?
  • Support processes: How does a problem get initiated, triaged, and handed to the right party for resolution? How do you define what gets handled by the BI team versus what is handled by your team?
  • Customization: If a customer wants a completely customized dashboard, are you willing to do it? How will you price it? How will you handle support for that unique instance?
  • Marketing: Do you need new or revised logos, sales collateral, press releases, etc.?

Pulling it All Together

Analytics are hot, they are addictive, and they sell products. Implementing a business intelligence solution is a different experience for everyone and you’ll learn tips and tricks as you go, but it’s easier if you know where the trouble spots may lie and how to avoid them. Hopefully my recommendations and tips provided in this blog series will help guide you on your journey (hopefully toward Birst!).

If you select the right vendor for your needs, understand your users, and start on the little details early, you’ll get your project successfully implemented and look like a rock star. Best of luck getting started on your BI adventure!