Contact Us
Partner Portal
Help Desk

12 Reasons for Failure In Analytics And Business Intelligence

12 Reasons for Failure In Analytics And Business Intelligence

Number 9 may surprise you

 

In analytics and business intelligence, there are a lot of things that can go wrong.  We are, after all, looking for the single version of the truth.  Whether it’s a report or a project – for the data and results to come out consistent, verifiable, accurate and, most important of all, accepted by the end user – there are a lot of links to the chain that have to be right.  The practice of Continuous Integration, invented by software developers and borrowed by the analytics and business intelligence community, is an attempt to catch mistakes or errors early.  

 

Still, mistakes creep into the final product.  Why is it wrong?  Here are some excuses reasons why the dashboard is wrong, or the project failed.

 

  1. It will be faster.  Yes, this is probably true.  It’s a matter of tradeoffs.  Which do you prefer?  Do you want it fast or do you want it done right? King of the HIll  To be honest, sometimes we’re put in that position.  I need it by Friday. I need it today.  No, I needed it yesterday.  The boss didn’t ask how long it would take.  He told us how long we had to do it.  Because that’s when Sales needs it.  Because that’s when the customer wants it.    
  2. It will be good enough.  Perfection is impossible and besides perfection is the enemy of good.  The inventor of the air raid early warning radar proposed a “cult of the imperfect”.  His philosophy was “Always strive to give the military the third best because the best is impossible and second best is always too late.”  We’ll leave the cult of the imperfect for the military.  I think the point of agile, incremental progress toward the end result is missed here.  In the Agile methodology, there is the concept of a Minimum Viable Product (MVP).  The key word here is viable.  It’s not dead on arrival and it’s not done.  What you have is a waypoint on the journey to a successful destination.
  3. It will be cheaper.  Not really.  Not in the long run.  It always costs more to fix it later.  It’s cheaper to do it right the first time. Good Fast Cheap Venn Diagram For every step removed from the initial coding, the cost is an order of magnitude higher.  This reason is related to the first one, speed of delivery.  The three sides of the project management triangle are scope, cost, and duration.  You can’t change one without affecting the others.  The same principle applies here: pick two.  Good. Fast. Cheap.  https://www.pyragraph.com/2013/05/good-fast-cheap-you-can-only-pick-two/
  4. It’s only a POC.  It’s not like we’re going to put this Proof of Concept into production, right?  This one is about setting expectations appropriately.   A POC is typically time-bound with a specific set of objectives or use cases to evaluate the application or environment.  Those use cases represent critical must-haves or common patterns.  So, the POC evaluation, by definition, is a slice of the larger pie on which we can base further decisions.  It is rarely never a good idea to put a POC into production, whether it’s software or hardware.    
  5. It’s only temporary. If the results are wrong, it performs poorly, or it’s just plain ugly, it should not have escaped to production.  Even if this is an interim output, it needs to be presentable.  End users and stakeholders will not accept this.  The caveat is, though, it may be acceptable if these are the expectations that have been set as part of the process.  “The numbers are right, but we’d like your feedback on the colors in the dashboard.”  Still, this should not be in production; it should be in a lower environment.  Too often, “it’s only temporary” becomes the good intentions of a permanent problem.
  6. This is the only way I know.  Sometimes there is more than one right answer.  And, sometimes there is more than one path to get to a destination.  Sometimes we bring our old habits with us.  They die hard.  Use this as a learning moment.  Learn the right way. Take the time.  Ask for help.  
  7. This is the way we’ve always done it.  This one is hard to fix and it’s hard to argue with.  It takes real organizational change management to change processes and the people who perform them.  Often, a new project, new software, an upgrade or a migration, will expose long hidden issues.  It’s time to change.  
  8. Oops, I did it again. Measure Twice, Cut Once I’m a woodworker and we have a motto because so many mistakes are made: measure twice and cut once. I know this aphorism. I repeat it to myself.  But, I am embarrassed to say, there are still times when my board comes up too short.  Is this carelessness?  Perhaps.  More often than not, though, it’s just something quick and easy.  I don’t really need a plan.  But, you know what?  If I had taken the time to draw it out on a plan, chances are good that the numbers would have been worked out.  The piece too short might have been on paper and an eraser would have fixed it.  The same is true of analytics and business intelligence, a plan – even for something quick and easy – can reduce these kinds of mistakes.     
  9. Distractions.   Looking but not seeing.  Inattentional Blindness.  You might have seen the video where you are given a task to do, like count the number of basketball passes for one team.  While you are distracted performing that simple task, [SPOILER ALERT] you fail to notice the moon-walking gorilla.  I knew what was going to happen and I still would have made a terrible witness if a crime had been committed.  The same thing happens in developing reports.  The requirements call for a pixel-perfect alignment, the logo has to be up to date, the legal disclaimer must be included.  Don’t let that distract you from making sure the calculations validate.   
  10. You intended to. Or, expected to.  At the very least, it was always an option.   Thomas Edison famously said “I have not failed. I’ve just found ten thousand ways that won’t work.”   His philosophy was that with every failure, he was one step closer to success.  In a sense, he planned to fail.  He was ruling out possibilities.  He only resorted to trial and error when he ran out of theories.  I don’t have over a thousand patents to my name like Edison, but I think we may have better approaches for developing analytics or reports.  (Thomas Edison Patent Application for Incandescent Electric Lamp 1882.)
  11. Stupidity.  Don’t deny it.  This exists.  Stupidity lies somewhere between “You intended to” and “Oops”.  This type of epic failure is the watch-this-hold-my-beer, Darwin Award variety. So, maybe, sometimes alcohol is involved.  Fortunately, in our profession, as far as I know, a drunken dashboard never killed anyone.  But, if it’s all the same to you, if you work in a nuclear power plant, please do your analytics sober.
  12. Success doesn’t matter. Evil Knievel Legendary stuntman Evil Knievel got paid for performing death-defying stunts.  Success or failure – whether he stuck the landing, or not – he got a check.  His goal was to survive.  Unless you get compensated for broken bones – Knievel had the Guiness World Record for most broken bones in a lifetime – success does matter.

 

 

Ready to streamline and automate your BI & analytics platforms?
Get A Demo
Solutions
Products
About Us
Resources
Contact
  • Tel:1 (972) 447-9595
  • Toll Free:1 (833) 855-3073
Follow Us
Youtube Linkedin Twitter
© 2024 Motio. All rights reserved
Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.