What it takes for a new report to stand on its own

Reporting transformation can look surprisingly simple at the start. There is an existing report, the data exists somewhere, and the business generally knows what it needs. On the surface, a new platform should make the whole process easier. Build it, test it and move across. 

What I have learned is that the closer a report sits to senior decision making, the less it is simply a report. There are years of business knowledge sitting behind it, along with decisions made long before the project started. There are people who understand why a number looks the way it does, even when that logic has never been properly documented. There are also habits, preferences, ownership questions and different views about what really matters. 

You start by thinking you are modernising a report. Quite quickly, you realise you are changing a process that people have learned to depend on. That takes time. 

The simplicity you see is rarely the work that happened 

An executive report might ultimately be only a few pages, but that does not mean the work behind those pages is simple. I have found myself asking questions that sound basic but are often surprisingly difficult to answer. Which source is actually the right one? How is this measure meant to be calculated? Who owns the commentary? Has this definition always meant the same thing? Is this part of the process intentional, or is it simply how it has always been done? 

Then there are the things that are harder to put into a project plan. Different teams care about different things. People are busy. Ownership does not always sit neatly with one person. Something one stakeholder considers essential might be viewed as an improvement by someone else. 

And yes, there can be politics. Usually not dramatic politics, but the everyday organisational kind. Competing priorities, different accountabilities, strong opinions and understandable nervousness about changing something that eventually reaches senior leaders can all shape the work. None of this appears in the architecture, but it absolutely affects the journey. 

Trust does not arrive with the new report 

This is probably the biggest lesson for me. The old report has something the new one does not: history. 

People have looked at it month after month. They know where to find things, what looks normal and when something looks wrong. Even if the process behind it is manual, inefficient or harder to maintain than it should be, people have learned how to work with it. 

The new solution does not automatically inherit that trust. It might use better technology, automate steps that used to take hours and introduce stronger controls, but none of that means someone will immediately trust the number in front of them. 

That confidence seems to build much more quietly. A KPI reconciles. A calculation gives the expected result. The right commentary appears in the right place. A reporting period changes and everything follows correctly. An issue comes up and the team can explain what happened and resolve it. 

That last point has become particularly important to me. Trust does not mean creating the impression that nothing will ever go wrong. Sometimes trust grows because something did go wrong, and people could understand why, fix it and see that the process responded as it should. 

Sometimes matching the old report is progress 

As consultants, we naturally want to improve things. When a new platform opens up more possibilities, it is easy to see opportunities to simplify the design, improve the process, introduce automation and create a better user experience. 

All those things may be worthwhile, but I have learned that there is a point where too much improvement at once simply becomes too much change. 

Sometimes the first version needs to feel familiar enough for people to test it properly. That is not because the goal is to recreate the past forever. It is because people need something they can compare. 

Can I reconcile this number? Is this the KPI I expect to see? Does this commentary still mean what I think it means? Can I understand what changed between periods? 

Those comparisons can feel repetitive during a project, but they serve a purpose. Eventually, people stop asking those questions as often. The old report is no longer the answer key for every conversation, and the new one is beginning to stand on its own. 

For me, comparability is not the destination. It is a temporary reference point that helps people become comfortable enough to stop looking backwards. 

UAT is where confidence gets tested 

I also think differently about User Acceptance Testing now. A test case marked Pass is useful, but a page full of successful test results does not necessarily mean the business is ready. 

The questions I care about more are simple. Does this make sense to the people who use it? Do they understand what they are looking at? Would the process still work when everyone is under pressure during a reporting cycle? Would they use the report without needing the project team beside them? 

That is a different kind of test. 

UAT is also often the point where opinions really come to the surface. That is not a bad thing. People finally have something real in front of them, so naturally they start seeing things they would like to change. 

The challenge is working out what needs to change now and what can wait. Something that does not meet an agreed requirement is different from an idea that would make the solution better. Both matter, but they do not always need to be solved at the same time. 

For consultants, that can mean saying no, or at least not yet. For the business, it can mean making choices about what is genuinely required for the first release. Neither side always enjoys that conversation, but avoiding it usually creates a harder one later. 

There are lessons on both sides 

One thing I would say to businesses going through this kind of change is to allow time for decisions, not just development. Technology teams can build quickly when they know what has been agreed. The pauses often come from somewhere else. 

A definition needs to be clarified. Someone needs to decide who owns something. Two stakeholders have different expectations. A requirement that sounded clear at the beginning turns out not to be clear at all. 

Those moments need business attention, and they can take just as much time as the technical work. 

For consultants, I think the lesson is equally important. Do not confuse technical progress with business progress. You can have data flowing, a report built, testing underway and a backlog shrinking while the organisation is still working out whether it is comfortable with the change. 

That gap matters. Sometimes the right answer is not more technology. Sometimes it is a clearer conversation, a simpler approach or getting the right person to make a decision. And sometimes people simply need a little more time. 

I have stopped expecting the straight line 

I used to think that a well-managed transformation should move cleanly from requirements to build, testing and release. I do not really believe that anymore. 

Assumptions turn out to be wrong. Requirements make more sense once people can see something. Technical constraints appear. Priorities change. Decisions get revisited. There are days when it feels like you are going backwards, and that can be frustrating for both the business and the consulting team. 

But I have stopped judging progress purely by how smooth the journey looks. I now ask a different question: did we come out of that difficult conversation knowing more than we did before? 

Did we finally make the decision that had been sitting unresolved? Did we remove an assumption? Does the business understand the process a little better? Is there more confidence in the outcome? 

If the answer is yes, then the work is still moving in the right direction. 

The final report may eventually look simple, but the work required to make it dependable usually is not. When the business understands what sits behind the numbers, the consultants understand what really matters to the business, and both sides have worked through the difficult parts together, something starts to shift. 

The new report no longer needs to be constantly compared with the old one. People start using it because they understand it, they know what sits behind it, and over time, they have found their own reasons to trust it.

Planning a reporting transformation? Altis designs executive reporting that earns trust and stands on its own. Contact us to start the conversation.