A Good BI Solution Needs Good Requirements - Here's How You Do That

I found out years ago that I had a special knack for requirements gathering. Many times I'd be on a project with other developers and there’d be an endless circle of trying to guess what the end user wanted or needed. These discussions could last hours or even weeks.

I'd take a different approach though. I’d simply ask the stakeholder what they wanted. It’s amazing how that alone made things go much easier.

The reason that was effective is that I reduced ambiguity about the project’s desired outcome.

That is the first big key to good requirements gathering. You have to actively communicate with the stakeholder to define the outcome you’re working towards. That means every interaction you have with a stakeholder leads to both of you walking away with a better understanding of where you’re going next.

Many BI professionals have a hard time with this, even some late in their careers. They will needlessly add complexity to a project, believing it makes them look more indispensable to the company. Or they may have trouble understanding the "why" behind the request and get lost cramming in every  functionality available.

The second big key to requirements gathering is reducing ambiguity before you start development. That’s where people have the most trouble. Quite often, they’ll find themselves still asking questions or for clarifications way too late in the design or development process.

This isn’t so much their fault as a lack of discipline in management. When people feel under a tight deadline, they’re afraid to ask the stakeholder to slow down to  research and discuss items in more detail.

That’s where processes come in handy.

How to Use Processes to Reduce Ambiguity

Processes are something we love to hate. They often feel bureaucratic and constricting. There’s nothing worse than filling out a form that doesn’t seem to serve a purpose anymore or entering data because some guy who no longer works there said so.

I think a good process is one that’s simple and intuitive. If management does it right, they become ingrained habits, where no one on the team has to think about doing them. They just do them naturally.

Down below is the typical process for a BI team. Most teams follow something similar to this, although naming conventions do vary.

The reason this works is that it’s easy to execute. The hard part isn’t the individual phases, but the transition between phases.

If you don’t clearly determine when the transition takes place, these phases will blend together and you have scope creep issues.

On my team, we established “checkpoints” for the project manager and the person working on the solution. If they haven’t fulfilled the goal of a phase, then the project doesn’t move forward.

The Discovery phase checkpoint is a requirements document. The design phase checkpoint is a report mockup and / or database schema. If you accomplish those items at the appropriate times, you’ll vastly reduce the ambiguity surrounding a project and improve the overall quality.

This may sound different to what's normally done. If the BI solution is a dashboard, many people will consider the mockup as part of the requirements document, but they should be done at different times.

The reason is that dashboards are meant to convey the information requested in the best possible way. When you don't clearly define what information the stakeholder wants ahead of time, the mockup design process isn't being used to its fullest potential.

What Makes a Good Requirements Document?

Requirements documents are good when they’re easy to read and provide just enough information. Don’t go overboard stuffing them with unnecessary details, such as field type and what case statements you’ll use. You don’t need that level of detail yet and it’ll overwhelm your stakeholders.

Instead, focus on the following:

• Business questions that the solution should answer
• KPIs that will answer those questions
• Fields that will support those KPIs (and if you have access to them)
• Desired features, such as filtering and dimensions

It is much easier for a stakeholder to digest that kind of information. Once you have that information and the stakeholder confirmed that it's what they want, you can move towards the design phase.

The design phase should end with a report mockup and / or database schema. The stakeholder usually doesn’t need to see the schema design, but they should see the mockup.

Filling out a requirements document and building the designs prior to development will astronomically improve your ability to deliver on a project.

Before You Start Discovery – Think About Your Stakeholder

It’s easy to say what you should do with a process, but it’s a whole lot harder to just do it. Stakeholders come in all shapes and sizes. Some are jerks and some are not. Other are smart and others less so.

These characteristics change the way you communicate with stakeholders.

Every once in awhile, you’ll get a really strong, knowledgeable stakeholder who sends you an exact list of fields and functionality they want on a report. When that happens – great! You’re done! You get to move towards development and send them what they want.

Sadly, that doesn’t happen often. Typically, you get an email or a walk-up from a stakeholder telling you “we know we want a report but we don't know what we want on it.”

I describe these stakeholders in two ways – weak and strong.

When I say weak, I don’t mean weak in the sense that they’re weak people, but in the sense that they don’t have a concrete idea of what they want or need. That’s okay. The better you get at requirements gathering, the better you’ll get at coaching them.

In addition to the weak-strong spectrum, personalities come into play. There’s low emotional intelligence and high emotional intelligence. Those are just like what they sound like.

Those at the top right are the best stakeholders in the world and my best projects were always the result of a strong collaboration with these people.

The stakeholders at the bottom right are usually tougher challenges to work with but can often produce good results.

The top left are usually nice people who know they need data but are not sure how or what they need it for. They require more coaching and guidance.

The bottom left people are… well, I just wouldn’t work with them. I’ll leave it at that.

I’ll be focusing on the weak stakeholders with average-to-high emotional intelligence for the rest of the article. I find that they’re the most common. They also pose unique challenges with building out requirements.

Helping Weak Stakeholders Get to Production

Weak stakeholders don’t always start off the discovery process the same way. Some might sheepishly walk up to your desk, asking what’s possible without providing much information. Others might schedule a mass meeting with you and every subject matter expert to brainstorm topics.

The problem that weak stakeholders pose is that they bring a lot of ambiguity to a project. Since ambiguity is the enemy of a successful BI solution, this means you have to work extra hard and think more strategically about helping that stakeholder get to a more clear goal or direction.

Regardless of the way weak stakeholders try to start it off a project, I always coach the them to step back and start with asking questions. Specifically, I suggest they write down questions that they often ask themselves. Those questions could be about their strategy or something their clients ask them. If they need help, I can meet with them personally for fifteen or so minutes to brainstorm. I also suggest they meet with their own team or teams to brainstorm ideas.

Then, I tell them to send me that list of questions. If they have some ideas for KPIs, great. If not, that’s okay too.

Be Careful with Subject Matter Experts

A common problem that weaker stakeholders have is that they are overly swayed by subject matter experts not on their team. Subject matter experts are great for their expertise, but they sometimes commandeer a request for a report for a different audience by demanding more metrics relating to them specifically.

For this reason, I suggest to weaker stakeholders that they determine their own list of questions first before brainstorming with subject matter experts (and I usually suggest to the subject matter experts that they make their own report request).

After I get the business questions from the stakeholder, I research and find out what data can support those questions and how we can get to that data. I’ll make a list and schedule the requirements meeting with the key stakeholder and their team.

Requirements Meeting

Before the requirements meeting, I’ll send an agenda and a list of unresolved questions that I think they or the subject matter experts can answer. I let them know this meeting’s purpose is to discuss the data I can provide and how it aligns with their business strategy.

During the meeting, I break the data and their questions into big picture and lil’ picture. I’ll label items as must haves, nice to haves, and ‘meh.’ This is useful since we haven’t actually built any datasets and we need to know what to prioritize in the event we have unexpected setbacks.

This is also where I include subject matter experts, who can raise red flags if we’re misunderstanding the use of the data or strategy. For example, a social media expert might say “wait, wait, we don’t use the campaign naming convention in that way!”

After the meeting, I’ll draft the requirements document. I specify what metrics and dimensions they want and send it to them for final approval. I tell them this will be version 1. It’s okay to have new ideas, but for the sake of meeting the deadline, we build this version. If they want to add more, great, we can build that as version 2.

You’d think we’d be done after that, wouldn’t you? No, sir. We get to design the solution!

Design Meeting

If you did the Discovery phase correctly, this part should be easy – regardless of the type of stakeholder. You simply design a mockup for reporting and / or a database schema based on the requirements document.

If you're designing a reporting solution, you will schedule a design meeting with your stakeholder. Some people handle this in different ways, preferring a big reveal, but I like to send the mockup ahead of time. That way the stakeholders can discuss it internally before meeting with me. I tell people that it’s okay to have a bout of inspiration with new metrics or KPIs, but 90% of it should be the same as the requirements document.

Once they sign off on the mockup, version 1 is locked for development and we finally get to build the damn thing!

Helping Strong Stakeholders Get to Production

Strong stakeholders usually require only one or two meetings and a handful of emails to get to the requirements document and subsequent mockup. They’ll typically send an email ahead of time or schedule a quick thirty minute meeting with you detailing the KPIs they want.

My only advice is to read their communication closely and verify what is and what is not possible. When you meet with them, label what is a nice to have and what is a necessity, so that you can work according to build out the necessary datasets and reports.

After that, you can design and present the mockup. You can meet with them, but often these stakeholders may have already given you a clear sense of what they want. Emailing the mockup to them with your questions is sometimes appropriate.

The biggest challenge with strong stakeholders, depending on their emotional intelligence, is that you may have to talk them down from bad UI practices with reporting. I typically notice this more with men than women, but stronger stakeholders sometimes treat discovery and design like a negotiation. You can mitigate that by bringing in other subject matter experts or stakeholders with a vested interest in the project who’d support you.

Last Bits of Advice on Requirements Gathering

As you’ll notice, the big theme throughout requirements gathering is bringing clarity to complexity. That means over communicating through email, meetings, and the requirements document.

Don’t be afraid to ask dumb questions during all this. Too many people worry they'll look ignorant in front of stakeholders and will hold back asking questions that really do make everything better.

For example, I work in marketing. I should never ask a stakeholder what a goal conversion is in Google Analytics, but there’s no shame in me asking a stakeholder why a goal conversion matters to their business strategy.

Lastly, your stakeholders are collaborators – not customers. The success of any business intelligence solution depends on that collaboration, both during development and its usage afterwards. All stakeholders have to make a valid contribution in terms of their time and their vision. You can coach a weak stakeholder so they can become strong, but they ultimately have to want the solution you're working towards.

It doesn’t make you a failure if the stakeholder is a failure.