3 rules for designing a strong analytics use case for your proposed project

3 years ago 321

Although IT and business users may think they have a solid business use case for their analytics, management might not agree. Here are some rules that can help you avoid disappointment.

If you've ever pitched a data project to management and gotten ho-hum results, you're likely not alone. In 2019, the Harvard Business Review uncovered several alarming conclusions when investigating the data and digitalization efforts of organizations. "The percentage of firms identifying themselves as being data-driven has declined," the HBR report said. "We knew that progress toward these data-oriented goals was painfully slow, but the situation now appears worse. … These sobering results and declines come in spite of increasing investment in big data and AI initiatives."

SEE: Hiring Kit: Video Game Programmer (TechRepublic Premium)

HBR followed up with business executives to see why there was widespread disappointment, and one recommendation was "not to focus on overall data-driven transformation in a large enterprise but rather to identify specific projects and business initiatives that move a company in the right direction."

In other words, finding success in data-driven projects that involve analytics and artificial intelligence comes down to identifying strong business use cases where everyone can see immediate results for the business.

But finding a strong business use case isn't as easy as it sounds. Here is one pitfall that IT commonly runs into. The business wants a use case that can deliver immediate business results, but when it comes to assigning a project lead from the business side, the person assigned is usually not a key knowledge expert but is more of a junior employee that the department can afford to spare for project work.

I ran into this situation more than once in my IT career. In one case, I was tasked to work with the finance department to streamline reporting so that the month-end accounting and reconciliation cycle could be reduced by one day. Accounting assigned a more junior person as its project lead. This person had an idea about how to simplify reporting so reports would be more readable, and doing this did shorten task time for some personnel—but it didn't impact the month-end close times to any great degree. The finance project lead was happy with the project, but I thought it fell short—and so did the CFO.

SEE: Digital transformation: A CXO's guide (free PDF) (TechRepublic)

Here are some potential use case issues and rules to follow to prevent them:

Issue: Like my example above, the simplified solution didn't actually help very much.

Rule: If you're IT and you're tasked to work with a business department on an analytics or AI use case, make sure that you're working with a subject matter expert on the business side who possesses the business acumen and experience to know what it is going to take to impact the business. Never settle for less.

Issue: Upper management is too busy to review a use case and confirm its usefulness.

Rule: Insist on reviewing any use case proposal directly with upper management before you start. What you want to confirm is that the use case you're proposing will really deliver the kind of business impact that management is looking for.

Issue: IT defines projects and then just goes away and does them. In the early days of analytics and AI pilot projects, when not much was expected, this was an acceptable approach—but it isn't anymore.

Rule: Clearly communicate your business use case proposal to management and users. What will it accomplish for the business? Can the results be quantified? What do you need to do on the project in order to get to the bottom-line results? Your use case presentation to management should incorporate as much input from internal subject matter experts as you can possibly get. You should be able to explain the technology behind the project in plain English—as well as how the use case will affect existing business processes and results. Project benefits (and also risks) should be explained, as well as budgetary impacts. Do not proceed with an analytics or AI use case unless management enthusiastically confirms and supports its value before you start.