Things to Avoid in Your Data Analytics Projects

Analytics is part of doing business—knowing what your data has to say about your customers, your brand, and your workforce is the key to making informed decisions across your organization. And although there are a lot of resources available to help navigate the best way to run analytics projects, companies still experience pitfalls before, during, and after.

“How to” guides are important in any analytics project—whether your data resides in spreadsheets or in a data warehouse, or if you’re working with big data or only a few sources. But equally important are those valuable lessons learned of things not to do. Over the years I’ve mentally compiled a list of what I consider worst practices when working on an analytics project, and in this blog, I’ll go over the six most critical things to avoid.

6 Things to Avoid During Your Analytics Projects

1.) Don’t refer to your Excel spreadsheet as your “database” and stop using Excel for reporting.

Excel is a valuable tool and has had staying power for a reason. But Excel also is a spreadsheet program prone to user error, minimal collaboration, and is a staggeringly bad choice in which to build your reporting ecosystem. Excel creates massive redundancies, encourages a proliferation of bad data that’s difficult or impossible to track, and should never be used as an enterprise reporting tool. There are a multitude of affordably priced, modern analytics tools out there that should make Excel completely irrelevant or obsolete in a reporting capacity.

Tip: If you’re an Excel heavy company looking to pilot a business intelligence (BI) tool, use Power BI. Because it’s a Microsoft product, the learning curve won’t be as steep. You may even have Power BI licensing available to you internally if you have Office 365 E3 licenses provisioned as an organization.

2.) Taking shortcuts out of the gate leads to severe issues scaling.

Getting immediate value versus doing things right is a tricky balance. Far too often I see the desire for immediate value take precedence over building something right in the form of hacky short cuts and hardcoded transformation logic to simply rush something out the door. What often ends up happening is an analytics solution that falls flat on its face in terms of adoption. An even worse situation is when that tool is widely adopted but is ultimately built on a foundation of technical debt. Constant iterations are built on-top of bad business logic, poor data modeling, and non-existent best practices in the name of getting something out the door. At this point you’re caught in a Catch-22: Users want what you’re building, but don’t have the patience or time for you to pump the brakes, course correct, and build something to scale. User adoption is king, but do not forget that you’re building something to scale and have staying power. An app or apps built on fundamentally unsound practices only creates more work in maintenance and trying to stay one step ahead of melting down. Your developers will thank you.

Tip: When building an analytics solution, collaborate with the business users to make them feel invested in the process but establish early on that it’s a partnership with accountability on both sides. When expediency is being pushed at the sake of best practices, you must clearly document and articulate the ramifications of that decision.

3.) Seeing the forest for the trees.

I had a project where a solid week was spent in “scroll-mageddon” hell. To be short: the loudest voice in the room didn’t like the thickness or coloring of the scrollbars I had built on the front end. And so, an entire week in development was spent adjusting scrollbar thickness and color hues. Meanwhile all the substantial updates to the data model in queue for development were put on the back burner, predictably causing a massive backlog and some sleepless nights for me. There will be times where aesthetics truly matter but know when to prioritize them versus core critical development items. While scrollbars may catch the eye, what is unseen and equally important is the heavy lifting and data engineering work being done in the background by your development team.

Tip: Having strong project management in place to balance one-off requests like this is key. While aesthetics matter, having a strong PM function to balance key development items versus less functional requirements can help to prioritize one-off project requests.

4.) Procedural hurdles create development hurdles.

In order to access database X, you have to submit a ticket which goes through an approval queue, is routed to an offshore team that misinterprets the request, tells you that you don’t have appropriate permissions (even though you do), gives you an additional form to fill out, and then denies your request. The nightmare that can be IT bureaucracy is an impediment to development in all forms. There is a balance to respecting procedure, security, and protocols and needlessly making it difficult for developers to gain access to the data they need to build. Data-driven cultures need to lower barriers of access, not create them.

Tip: If IT processes are becoming an impediment to development, be sure to highlight their impact to the business. As a developer you likely have little control over governed processes like this. The best you can do is highlight their inefficiencies to the power users (and presumably decision makers) using your analytics solutions in an effort to influence change.

5.) You get what you pay for.

Offshore teams aren’t generally all bad, but there are a multitude of vendors that offer reduced rates for poor quality work. The hot phrase of the day is “treating data like an asset”, yet there are so many organizations that entrust this asset to what are effectively body shops. You may save some money in the short term, but I can guarantee at some point you’ll be paying that back in full when a competent vendor will need to be brought in to untangle the mess that your offshore team built.

Tip: Prioritize value over cost. This isn’t always easy, but you should go into the process knowing that do-over work does not come free. Be clear on your vendor’s credentials, case studies, and intended approach to your business problem. Asking the questions up front will help to disqualify vendors that simply approach the problem from a cost versus value standpoint.

6.) Data analytics projects will only work with a strong willingness to make them work.

From a consulting perspective, our job is to bring to bear expert-level guidance and skills in driving your data analytics project work. But a project will only go as far as the time, investment, and importance business stakeholders place on it. I’ve been a part of projects that were a directive from senior leadership passed down to a less-than-willing or enthused stakeholder to manage. Those projects did not go nearly as far as I hoped they would. To be successful, an analytics initiative or project can’t be a pet project, but rather a coordinated and willing effort by business and technical stakeholders.

Tip: There is no easy tip other than you must have a clear willingness to undertake this type of project work as an organization. If you’re unsure of the merits or value proposition, then take the time to re-evaluate until you’re ready. A project with halfhearted requirements and willingness is destined to be incomplete.

Remember, data and analytics are critical for the success of every organization—but knowing how to run analytics projects is equally as important.