Reducing the Risks of an Analytics Implementation

Here are a few concepts to help you avoid some risks when building an analytics solution.

BI Tools Don’t Live Up to Expectations—Or the Hype

Analytics and BI tools do work.  They are built and designed to move/transform data and display information. But the marketing hype about these tools often ignores how to properly implement the best ways to access the data. Each tool is built with a purpose in mind: retrieve data from a source, transform the data, and then present it using data visualization techniques that are pleasing to the user.  For the tool to live up to its hype, Enterprise Data Warehouse (EDW) data modeling best practices now come into play.  For example, do you want to use the analytic tools against a relational database or an OLAP engine?  Are these designed correctly?  Experienced architects and team members now become critical.  The architects need to know both EDW modeling and be experienced developers in the analytic tools to ensure proper utilization.  The team needs to be skilled in building the right user interface (UI) for a good user experience

Internal Resistance to Change

Getting full adoption of a new analytics tool takes some time, effort and patience.  Departments still use spreadsheets and standard reports to make business decisions.  Users want easy access to data without learning a new process.  However, people don’t like change—especially one that requires learning new ways to retrieve data.  Resistance to change is often due to lack of proper education and training with the new systems.  Senior management needs to mandate, and give a vision of, the strategy of using state-of-the-art analytics and BI systems.  If you allow the users several options to perform business analysis, including the legacy reporting system, they will most likely choose the path of least resistance and with the tool they are experienced or most comfortable.  This is not the best decision for the company and hampers the adoption rate of the analytics platform.

Poor Data Quality

Launch the new analytics system and data quality issues often show up.  Two things have occurred, either the data architects designed the system incorrectly or the source system has data quality issues.  Creating more visibility often shows data errors in the source system.  The good news—fixing a data transformation process is manageable by the IT team.  Once the users begin seeing the data issues, they typically go to the source of the new reports and metrics—your analytics and BI team.  This is where two new processes begin to get attention—master data management and data cleansing. Teams will start to use these processes to improve data quality.  For an error-free analytics system, the source system needs to have the data cleansed and updated properly and regularly, which then improves both the data warehouse and the analytics system overall.  Don’t skimp on this step or risk of failure increases.

Scope Creep and Loss of Momentum

When dealing with an analytics platform, scope creep seems to rear its ugly head.  This is not an issue with the analytics tool itself—this is a project management challenge. The project manager needs to have a clear approach to which data will be introduced into the analytics system and how that data is presented in the user interface and reporting environments.  Managers might get the idea to import all the data possible into the system, no matter if it is used or not.  This is a poor approach because it impacts the data modeling and lengthens the building process as and more items are introduced than actually needed.  An audit of the required metrics and records is vital in reducing data warehouse size and complexity—and minimizing scope creep.

Assembling the Wrong People for the Team

The analytics team must be assembled correctly.  Seasoned veterans that have built analytics systems can work as a team to architect, build and deploy a system efficiently.  But be careful when you get multiple people from different software or data modeling backgrounds.  The team might have a hard time agreeing on the right path for the data warehouse foundation.  Start at the top.  The manager needs to have been around these types of projects before and understand how it all works.  The manager doesn’t need to know everything, but must grasp the idea of databases and data movement. The rest of the team is built around a data modeler/architect, the ETL designers and the UI team.  The architect needs to have a clear understanding of where the data is coming from and how the user interface is going to use the data.  The architect needs to quickly decide on the data platform.  The UI team needs to be skilled in both data visualization and querying/retrieving data.  The team needs to build the UI so that the users can understand the data and navigate easily through the system.  A skilled UI team knows the best approach for querying for data when building this user experience.

Justin Taylor, a StatSlice Manager Consultant, (www.statslice.com), has been architecting, building and managing business intelligence projects since 1999, including solutions for Fortune 500 companies.  When Justin joined StatSlice, he was looking for an opportunity to make a major contribution to the company and utilize his technology experience to help clients solve their business problems.  He enjoys opportunities to speak at technology events, conferences and training.  He holds several Microsoft certifications include MCT (trainer), MCTS and MCITP certifications in SQL Server BI, and Certified Scrum Master through ScrumAlliance.org