Three Reports a Bank's Leadership Actually Reads (and 100 Hours a Month Back)

[#1]

Every month, right before the monthly portfolio meeting, a project manager pulls data from Jira, finance systems, and other sources, compiles it into a spreadsheet, rebuilds the same reports as four weeks ago, and prepares the same 12-slide deck. Everyone treats it as a normal part of the monthly routine. What if it is a governance failure, not a reporting problem?

Boubyan Bank was in exactly that position while trying to mature its project and portfolio management practice. At eazyBI Community Days, Tomasz Pabich from Genius Gecko walked us through Boubyan Bank’s reporting journey and how they got more than one hundred hours given back every month. The part worth borrowing, though, isn't the number. It's how few reports it took to get there.

Where the Hours Were Going

The bank was running many initiatives at once, across different departments, and leadership needed a clear view of their progress and costs. The lack of data was not the problem. The data was in Jira — and, as there is always a little trick, in several other systems as well. That detail is what usually turns a reporting task into a data-gathering project.

So the month-end routine was manual by necessity: pull from each source, normalize it by hand, update the spreadsheet, refresh the deck, distribute it. Every hour spent on that was an hour not spent asking why a plan had slipped.

Boubyan Bank already knew what they needed from the eazyBI. The team already knew which reports mattered to their portfolio process — they weren't starting from a blank canvas and hoping a BI tool would tell them what to care about. That made the implementation different: the goal was to move existing reports into an automated environment, rather than figure out the requirements from scratch.

Report One: Projects by Status

The first dashboard is almost embarrassingly plain — a breakdown of projects by their current status. Nothing about it would win a data visualization award.

It earns its place because of what a change in it means. When the count of projects in execution jumps, that is not neutral information. Either the organization has taken on more than it planned to, or work that should have closed hasn't, or priorities have shifted somewhere without the portfolio view catching up. Any of those is worth a conversation, and the report's job is simply to start it.

This is the pattern behind a lot of good executive reporting: the visual answers one question, and its value lies in the second question it provokes. A report that answers everything usually gets read by nobody.

Report Two: Plan Stability

The second one is more interesting to steal. Instead of tracking whether projects are on plan, it tracks how often the plan itself changes. Each change is recorded, and the report shows how frequently plans are revised across the portfolio.

The logic: replanning is healthy. Projects change as they progress. Initial estimates may prove wrong, and the scope often becomes clearer along the way. But a project that has been replanned six times in a quarter is telling you something. Either the initial planning was too optimistic, or the requirements were never stable, or the risk is accumulating faster than anyone is admitting. Each replan tends to carry a cost, so catching the pattern early is cheaper than catching it during the year-end review.

Most portfolio reporting measures outcomes. This one measures the quality of the process that produces the outcomes, which is a leading indicator. Frequent changes can be an early sign that a project is not going according to plan. In eazyBI, you can track these changes over time using the change history. The resulting chart shows how stable the plans are across the portfolio, rather than just the current status of each project.

Report Three: High-Level Health Indicators

The third layer is a set of trend indicators — is this getting better or worse — with no detail attached.

What makes these reports useful is what they leave out. They are deliberately simple, so a stakeholder can read them in seconds, notice something moving in the wrong direction, and know where to look next. They are the starting point, not the analysis.

The principle Tomasz described is that a good report shouldn't need a long explanation. It should show what's happening, flag what needs attention, and signal when action is needed.

That's a higher bar than it sounds. It rules out most of the dashboards built with genuine enthusiasm.

The Part That Isn't about Reports

Two decisions did as much work as the dashboards themselves.

The first was delivery. Plenty of organizations have good dashboards that no one opens, or that are checked only after the decision has already been made.
Boubyan Bank made sure the right people saw the right reports at the right time. The reports became part of the regular portfolio review, rather than something sitting in a dashboard waiting to be checked.

The second was where reporting lives. The bank also brought in BigPicture for advanced planning and Gantt work, which raises a question every growing Atlassian stack eventually faces: when two apps can both show progress, which one should?

They kept high-level reporting in eazyBI and used BigPicture for planning. Stakeholders start in eazyBI to get the overview and move to BigPicture only when they need more detail. It may seem like a small decision, but it helps keep reporting consistent across the stack, rather than leaving teams with different versions of the same information.

What the Hundred Hours Actually Bought

The time savings are real, and automation is what produced them: reports that were previously rebuilt by hand in Excel and PowerPoint can now refresh themselves.

But hours saved is the easiest benefit to measure, not the largest one. The bigger change is that portfolio conversations at Boubyan Bank now start with current data everyone has already seen, rather than a deck assembled the night before. Planning gets better because the feedback loop is shorter. Problems surface while they're still cheap.

In the end, it came down to three reports. Not a data warehouse project or dozens of dashboards, but three reports that leadership actually reads, delivered reliably and kept in one agreed place.

What does the equivalent look like in your organization? I'm curious whether anyone else here tracks plan stability as a distinct metric, or whether it usually gets folded into general schedule variance. And if you've faced the eazyBI and BigPicture overlap question, I'd like to hear where you drew the line.

Tomasz Pabich's full presentation from eazyBI Community Days is available as a recording, as well as a longer write-up of the Boubyan Bank story on the eazyBI blog.