Report Requirements Gathering
Requirements gathering is one of the most important steps in the reporting process, even if it feels like the least exciting one. Taking the time to clearly define what is needed before development starts can save everyone from the familiar cycle of endless email chains, confused meetings, and “that’s not what I meant” moments later on. It also improves report accuracy by making sure the developer and stakeholder are actually on the same page (imagine that!). When requirements are rushed or incomplete, the report often comes back looking like a first draft that somehow made it into production. Spending a little more effort up front usually means fewer poorly defined reports hanging around for years and quietly adding to the technical debt pile.
When a report is in the requirements gathering phase, I recommend the following people be present if possible.
- Stakeholder/Owner: This is the person (or people) who actually need the report and will use it. They should be able to explain what decision or problem the report is supposed to support, what data they expect to see, and how they plan to use the results. Without them in the room, requirements almost always end up incomplete or wrong.
- Report Developer: The person who will build the report should be present to ask practical questions early. They can identify missing details, unclear logic, data availability problems, and unrealistic expectations before development begins. This helps prevent a lot of rework later.
The developer is not only there to give technical input. They are also there to learn about the business and how the company’s data is actually used, which is especially valuable when the developer is newer to the organization. - Project Manager: The project manager helps keep the discussion focused, documents decisions, tracks open questions, and makes sure the request is properly prioritized against other work. They also help set realistic timelines once the requirements are clear.
Note: I have found that relying on a single person to collect requirements often creates an unnecessary middleman. This leads to repeated back-and-forth communication and results in weaker, incomplete requirements.
Including these three roles in the requirements discussion significantly improves the quality of the information gathered and reduces the risk of building the wrong report. It may take more than one meeting to get the requirements right. At a minimum, both the stakeholder and the report developer should be involved.
Understand What The Stakeholder or User Wants
This is paramount. Do not walk away until you understand the nuances of the report requirements. Incomplete understanding will come back to bite you. Multiple meetings are fine—necessary, even. Do not assume the requestor fully knows what they want. Most of the time they arrive with only a vague idea. They rarely understand the data the way a report developer does.
And, if you finish the requirements process without learning something new about how the company uses its data, you have done something wrong.
I break requirements gathering into two distinct approaches.
Report Developer Present The developer participates directly in collecting the requirements. In my experience, this is the superior method. When I worked directly with the requestor from start to finish, the process was painless, often enjoyable, and consistently produced useful reports. The developer can immediately confirm whether the necessary data exists, surface logic problems early, ask the right clarifying questions, and absorb how the business actually thinks about its information. Over time the developer becomes a genuine asset rather than just a coder.
Man-in-the-Middle Someone else gathers the requirements and relays them to the developer. This approach is less optimal if the goal is a report the requestor will actually be satisfied with. The intermediary is usually not familiar enough with the data to recognize pitfalls or ask the probing questions that matter. Information gets filtered and distorted—what I call the Grapevine Effect. The result is repeated cycles of clarification, reports that miss the mark, and a developer who learns almost nothing about the business.
I learned this distinction the hard way. Early in my career, handling the full process myself produced good results. As request volume grew, the department tried to make me more “efficient” by removing me from requirements gathering so I could focus solely on coding. The outcome was the opposite of efficient: endless rounds of requirement debates, reports that never quite landed, and a developer who looked ineffective while learning nothing new about the organization.
Direct involvement is slower at the front end, yet far more effective overall. The time spent understanding the real need is repaid many times over in reduced rework and higher-quality output.
Embrace The Crazy
Sometimes you are going to get a crazy requirement. And I mean totally bat shit, no holds bar, how did you ever get into a management position crazy. Even everyone on your development team might think its nuts. I am telling you right now, embrace the crazy. The crazy will increase your ability to create reports in the future by learning different report writing techniques, garnering awe from your fellow co-workers who ask, “How did you do that?”, and push the bar on your confidence as a report developer. Here are two examples of times I got some crazy requirements.
Move the label 3 pixels on the graph
The report looked excellent. The Nobel prize level economic formulas produced the correct numbers, the graphs rendered cleanly, and everyone believed it would impress the company owner. The owner did like it — until he applied an unusual filter. That filter caused one label on a pie chart in the SSRS (now paginated) report to sit slightly off. It looked fine to everyone else, but not to the report requestor.
I complained. I criticized Report Builder. I insisted Microsoft should have handled edge cases like this better. At the time I had a short temper, and the idea of spending time moving a single label three pixels felt absurd.
I had no choice. I needed the label to shift three pixels only when a specific value range appeared. After extensive research — Microsoft documentation, forums, and blogs from people facing the same limitation — I found a relatively obscure technique that used custom VB code inside the report. After some trial and error, I made it work.
The process took two or three days of unnecessary frustration and complaining. But more importantly, I learned something new about the platform. The accomplishment felt good. That knowledge later helped me solve other difficult reporting problems. Looking back, the better response would have been simple: “That’s going to be challenging. Let me figure it out.”
The Report No One Wanted to Build
A more senior report writer once described this request as the kind of report that gave him nightmares. He dreaded these assignments and routinely talked requestors out of them. A group of DBAs also argued that a report with that many columns would be useless to end users and urged the requestor to reconsider. These seasoned DBAs and report writers could see the light, but would the report requestor?
The light never came. I had to build it.
The requirements were extreme: dynamic headers, dynamic columns, nested pivots (a pivot inside a pivot inside a pivot), every customer’s data on a single row, and support for as many as 2,000 plus columns. Development was grueling. Early versions crashed the web server, then the Power BI server, then the SQL Server. The testing team left versions sitting in their queue for months. At one low point I sat outside, frustrated, asking myself why this particular problem had landed on me.
I grew up in a technology-oriented household. At age twelve I was paid to do data entry for stock trading, and I tried to program simple games. My father worked at AT&T on the team that maintained their Unix systems and kept a book on Assembler that explained how the language moved blocks of memory. That old concept became the solution.
I treated temporary tables like memory blocks. Nested loops moved and reshaped the data the same way Assembler instructions had once shifted memory. The final version ran efficiently, stayed stable, and no longer crashed any of the servers. Testing went relatively smoothly — the remaining issues were mostly formatting.
I had learned a technique most report developers never need (or want) to master: building a report with deeply nested pivots, runtime-generated headers, and support for over two thousand columns. The business got the report they required. I gained a rare skill and a different attitude.
If another request like that arrives, my response will be different: “Certainty of death. Small chance of success. What are we waiting for?”
The Final Say
Requirements gathering is not a box to check before the “real” work begins. It is the foundation that determines whether a report becomes a useful tool or another source of frustration and technical debt. When the stakeholder, the report developer, and (when possible) a project manager sit down together, the odds of building the right thing rise dramatically. Direct involvement by the developer is especially powerful: it produces clearer requirements, reduces rework, and turns the developer into someone who actually understands the business rather than someone who simply writes code from incomplete notes.
The hardest requests often deliver the greatest long-term value. The label that had to move three pixels and the report with nested pivots and thousands of columns both looked unreasonable at first. Both forced deeper learning. Both left me more capable than before. The difference between those experiences and the ones that dragged on endlessly was not the difficulty of the request—it was the attitude I brought to it.
So when the next “impossible” report lands on your desk, remember: the goal is not to avoid the hard problems. The goal is to understand the real need, stay present in the conversation, and then get to work. Certainty of difficulty. Small chance of an easy solution. What are we waiting for?
Leave a Reply