Signs Your Analytics Project Is Going to Fail

By December 12, 2014For Developers
Without the right resources, software projects fail

Does your current analytics project smell like impending doom? Do you think you still have time to turn things around, or is it heading into Bataan Death March territory? What are the signs that happen before the point of no return that we can use to see that a project is in jeopardy? Here are a few to look for, if you are concerned your project is about to go belly up.

Just What Are We Trying to Do Here?

A major sign of trouble is when you sit down with your team and project sponsor to discuss goals – and nobody can agree on where it is headed. Have the project stakeholders explain to you where they see the project ending up. If you get multiple or conflicting answers, it might be time to sit down and check the project charter to see where you got off course.

“Our team’s dev lead was determined to stay on the periphery of the project as much as possible, making it so the project had no real leader – a few of us developers tried to coordinate as much as possible, but ultimately didn’t do a great job.”

“Our team’s dev lead was determined to stay on the periphery of the project as much as possible, making it so the project had no real leader – a few of us developers tried to coordinate as much as possible, but ultimately didn’t do a great job.”

If some of the team members are dead set on using another BI tool, they won’t be committed to working on this project. They also may insist on using another programming language or framework to work on the project because it’s what they know, is their favorite or is the newest technology. But none of those might fit this project and the existing application for which the company needs an analytics solution.

Smaller companies have the added problem of a shortage of resources to solve development issues, particularly when they relate to an outside specialty such as analytics.

And it’s not just a shortage of resources devoted to the project that causes problems. Software product teams need to put the right resources on it. Developers not familiar with the technology used on the project create as many problems, our own team has found. If they lack familiarity with their data or application, at the least the project will be delayed as they learn what they need to know.

Our team members have worked with potential customers who wanted to build a report but couldn’t answer any questions about their own data in their application’s database. They failed to include a DBA or business analyst familiar with the data – a clear sign that they failed to put the right resources on the project. Any BI project needs to include someone on the team that understands data.

In today’s world of data breaches, malware and ransomware, security can’t be an afterthought. Whether working entirely in-house or with a third-party vendor for analytics, the software product team needs a thorough understanding of the security system. One person on the team needs to take ownership of making sure the security meets compliance and privacy standards. How does a third-party vendor’s analytics solution integrate with the application’s security? Does it inherit user roles and permissions? Does it require its own security system? How does that impact on securing data?

Replacing an In-House or Legacy Tool Meets Pushback

The software product team may feel invested in a BI tool they created even though it lacks features available from a third-party analytics specialist. Replacing their handiwork may feel threatening to them as they envision being replaced or “downsized” for failure to create the analytics solution their organization needs.

But keeping that in-house solution drags out shortcomings in delivering analytics to customers. Bug fixes on an in-house solution may not be as robust since the software product team doesn’t specialize in business intelligence software.

Being wedded to either a solution built in-house or a legacy solution that’s on its last legs tends to perpetuate problems with analytics. The existing team isn’t thinking outside the box and even stumbles on basic development issues well known by a BI specialist vendor. Our own software team has encounters organizations that built their own solution, but it doesn’t allow users to share reports. Many in-house solutions lack user friendliness, curtailing user adoption. We’ve seen these solutions using ideas and code releases that are 5 to 10 years old.

The Sponsor Changes or Leaves

Without management support, projects often die a slow, painful death. If there is a shift in management that causes your sponsor to change or leave, then your project is in trouble. Even if higher level management champions remain in place, a sponsor is a driving force who can advocate removing barriers that are in your way. It might be time to consider letting this one go and drafting a new project with a new sponsor.

Failing to Create Clear Lines of Communication

Particularly when working with an outside vendor, a software company needs to dedicate one person as the contact with that vendor. And the vendor needs to do the same to set up clear lines of communication. That person will keep his team in the loop and make sure the right questions are asked, information is shared and answers are delivered.

No Risk, No Reward

Many projects fail to get off of the ground because too much time is spent on risk mitigation, instead of coding. Your team has to be willing to take some risks with a proper mitigation strategy, and trust that a solution will be found for any problems that occur during development. Without risk, there is no reward at the end of a successful project. Consider this the next time a two-hour meeting is full of “what if’s.”

“What I’ve learned isn’t just “how not to run a project” – I’ve also learned about some of my own blind spots, how so-called “soft” skills are really important, and what kinds of mistakes that leads and organizations make.”

Sacrificing Quality for Schedule

When the costs begin to mount and the cost curve climbs away from the baseline, there is a temptation to cut corners. As your schedule slips, you really only have two choices to keep your project on track: move the target date, or revamp the deliverables you need to provide.

“When the scope kept ballooning, I should have raised red flags that we were in over our heads.”

Hope Springs Eternal

Some projects might get so far behind schedule or over budget that it seems a miracle is the only thing that can save them. Do not wait around for a miracle if you feel your schedule or costs are slipping. The sooner you intervene, either to increase manpower or manage end user expectations, the better. It may be the only way to avoid complete failure.

“I finally accepted, very deep down, that I should never ever assume that anyone in any given room knows more about what should be done than I do, no matter how many of them there are, or what their job titles or resumes might suggest.”

A Modest Proposal from Izenda

We can’t rescue your project, but we can make ad hoc reporting in your application a whole lot easier. Ask us about how our embedded ad-hoc reporting and analytics tool can save you countless man hours on your project, so you can get back to work on everything else.