It's a well-known fact that gathering or, it's more accurate to say, eliciting requirements in BI projects, is a sore subject. BI doesn't offer classic requirements gathering procedures within an IT project - users often do not know what they want until they see the data and click on the first versions of reports. And that won't change.
By playing into agile development, you take the risk of wasting the resource and not getting a result (going around in circles). These risks can be managed to reduce the negative impact - through the right questions, identifying risks and structuring expectations at an early stage.

There are few in-depth investigations on this subject, BI vendors have little interest in such issues - it is too complicated and doesn't help in any way to sell licenses.
Within our projects, we built guides and instructions for ourselves, it's time to share them with the world - they contain both relatively original things and copies of what has already been heard.

I wanted to call it some kind of ... canvas, but I've got a feeling that it was already used somewhere)
Therefore, now there's a tool called "Lords of the Boards" - a guide on the steps of report development in corporate BI projects.

This framework is our version of a question bank that BI analysts need to pose to themselves and the customers at different stages of a report development project. It seems to me that focusing on the right questions is the most effective way. A lot depends on this "question bank".

The purpose of the guide is to assist BI analysts:

• Accelerate the process of gathering and eliciting customer requirements
• Prevent from stillborn BI projects
• Minimize the execution risks and maximize the effect of a launched BI project

The guide is conceptually related to Dashboard Canvas, a Roma Bunin's masterpiece, but has a different focus. Although all coincidences are probably not a fluke.

How to use it?

• One can open (1) the guide on the second screen during the interview with the customer, make lines on the a4 sheet with a 4x4 grid and make notes during the meeting; (2) use it to check oneself when structuring the received request and planning the project
• Not all topics are applicable to all projects, if this guide somehow helps to structure the project preparation and its management, that's a good start
• Leave comments and feedback – it's a hot-button issue and I probably didn't cover every eventuality.

All this is not yet a full-fledged system methodology. Perhaps this is the next abstraction level, which our colleagues and community experts will head over after they reach the following maturity stages.

In addition to the guide itself, it also includes a set of useful thoughts:

All of us know pretty much about hard and soft profiles of a good BI person. This is a subject for a separate article - but loosely speaking this is a business-minded engineer with creative and communication skills. People who end up doing this job are different, and most of them tend to develop their strengths - technology, business, design or communications. Leveling up the weak spots of the team members is certainly an important task for a BI lead - but this diversity, on the other hand, enriches the team, provides it with more interesting expertise and growth incentives. Therefore, in addition to the development of common skills, we focus on "preaching" a certain mindset in the form of principles - guidelines that help everyone, despite differences, to take a shortcut and drive BI projects to success.

Here are some of them:

• Customers often get it wrong - they misinterpret the report, the way they see it
• You are in charge of the project - you are responsible for your resource (=company resource) when it's used in an inappropriate way
• Before you start the project, you owe a service to the clients, after you start the project, they also owe their resource and adoption to you. Hold the projects where the customer avoids you
• Divide demanding requirements into parts and arrange them chronologically in different "releases", force the project to be accepted and released piece by piece.
• Do not treat a small task as a small task, most of the requirements or data problems are hidden from you
• Assume no liability for the process imperfection. When changing processes and systems, maintain the boundaries of responsibility between you and the process / system owner
• Confront about the current and potential project risks and draw confirmation from the customers that they acknowledge these risks and agree with them.
• Do not focus on features and visualizations longer than on solving business problems and checking the business value of what is being developed.
• Give serious consideration to agreements and fix them, if the requirements change, gently rub the customers in these agreements and make them admit their fault.
• Use Fail-Fast approach after you make sure that the customer is ready to it.

Not all of these principles are clear without context, if you are interested - I will describe them separately.
By superimposing these principles on the analyst’s soft skills and the specifics of the task, I got several strategies for the role-based BI analyst's self-positioning in a project:


Productive Strategies:
May be optimal depending on the case

Strategy 1 - Like a god

• You do everything from business logic to technology and visuals
• You settle the dates and roles, structure the working group and experts
• You demand necessary actions from the customer/experts, formalize the business logic yourself
• You bear all risks

Conditions:

• No data owner
• Owner's business function doesn't have any initiative or resource

Strategy 2 - Like a boss

• You know better what should be done in terms of data and visuals
• You settle the dates and roles, the mode of interaction
• You demand the necessary actions, business logic from the customer/experts
• The customer assumes the risks both for the systems and requirements,while you take risks for the visual and equipment

Conditions:

• You really have to be skilled in the data domain and picking an effective visual (and not the way you see it)
• In the end, the clients are expected to be happy if they did everything they were asked to

Strategy 3 - Like a partner

• You act as a visualization and data expert, who offers final solutions and caters to the customer expectations
• You serve as a consultant in the business logic development
• You share the risks with the customer

Conditions:

• You are not ready to impose the terms how it should look visually
• The customer does not have adequate requirements, final metrics and "takes cue from the data", accepts the risks
• There are no hard deadlines, the customer signs off on work on agile

Strategy 4 - Like an executor

• You serve as "hands" - we'll do whatever you say
• You receive input requirements both with regard to logic and visual, you just offer it, and it's up to the client to make a decision
• You set deadlines and adjust them in case of requirements changes
• The customer bears all responsibility

Conditions:

• You do not have expertise in visualization or the task is about getting numbers rather than visualization
• There is a clear and complete requirements specification

Low-productivity strategies

Strategy 5 - Like a friend

• You get down to work having a good human contact with the customer
• You are anxious to "help" - you mix roles and do not communicate risks and responsibilities before and during the project
• You do not appreciate the timing and shifts, you judge by the situation

Conditions:

• You are sure that you are in complete sympathy with the customer, you are experienced in productive projects
• The customer doesn't have adequate requirements, final metrics and "takes cue from the data", accepts the risks
• No hard deadlines
• You've got resources for this
• Not a top-priority project

Strategy 6 - Like a slave

• You serve as "hands" - we'll do whatever you say
• You receive general input requirements and unearth them by yourself
• You are responsible for the result and do not communicate the risks to the Customer

Conditions:

• There is no proper project management in your work, no customer contact (super top?)
• Inadequate customer expectations

These strategies are useful to be cognizant of and to switch yourself and the customer over to constructive roles depending on the current conditions. A perfect analogy with "Games People Play" by Eric Byrne.

Use the service and leave comments. Once you have read this far, I wish you derive odd perfectionist pleasure from the process)