ServerVultr

Data storytelling isn’t complicated. Great Power BI report structure starts with one simple idea: every good report should have a beginning, a middle, and an end.

Storytelling in data is simpler than people think

At this point in the series, people often assume that “data storytelling” means something complicated.

Something creative.
Something fluffy.
Something subjective.

It doesn’t. It starts with something very simple. Every good story has three parts:

• A beginning
• A middle
• An end

We instinctively understand this structure in films, books, and conversations. If someone starts a story halfway through, we feel lost. If they never finish it, we feel frustrated.

And yet the moment we open Power BI, we abandon that structure entirely. Most reports are all middle, with little if any beginning or end.

The problem: reports with no beginning

Open most dashboards and what do you see?

• Metrics
• Charts
• Comparisons

Straight away. No context. No framing. No explanation of why this page exists or what decision it supports.

It’s as if someone walked into a cinema, skipped the opening scenes, and pressed play in the middle of the film. The audience is immediately working harder than they should be.

They’re asking:

• What am I looking at?
• What timeframe is this?
• What problem are we trying to solve?
• Why does this matter now?

If your report forces the audience to orient themselves before they can think, you’ve already created friction. The beginning of a report should answer one simple question:

Why should I care?

The middle: where most reports live

The middle is where analysis happens. This is where you explore:

• What’s happening
• What’s driving it
• where the patterns are
• What’s surprising

And this is where most dashboards stop. They present the data. They present the breakdowns. They present the trends. And then they leave the room. No conclusion. No implication. No direction.

It’s the analytical equivalent of someone explaining a problem in detail and then walking away mid-sentence. Technically correct. Structurally incomplete.

The missing ending

Here’s the uncomfortable truth, If your report doesn’t have an ending, it isn’t finished. No matter how accurate the data is. The ending is where you make the implication clear.

It answers:

• So what?
• What does this mean?
• What should we do?

Without an ending, dashboards create discussion instead of decisions. And discussion is not the goal. The goal is clarity.

Power BI report structure should follow stories

A good Power BI report should function like this:

The beginning

Set context. Define the scope. Explain the decision.

Answer: Why should I care?

The middle

Explore the drivers. Surface the patterns. Highlight what matters.

Answer: What’s happening and why?

The end

State the implication. Reduce ambiguity. Point toward action.

Answer: What do we do next?

That structure isn’t creative writing.

It’s cognitive alignment.

Let’s try it on my football report

�

Why we abandon structure in analytics

There’s a reason most dashboards are all middle.

• We’re trained to build models.
• We’re trained to calculate measures.
• We’re trained to visualise data.

We’re rarely trained to structure thinking. So dashboards become containers for metrics rather than vehicles for decisions. They’re built as analytical canvases instead of narrative flows. And that’s why they feel dense. Not because the data is wrong. Because the structure is missing.

The spreadsheet mindset

Spreadsheets don’t have beginnings or endings. They have rows and columns. They’re designed for exploration, not persuasion. When we treat Power BI like an interactive spreadsheet, we get exploration-heavy dashboards that rely on the audience to assemble meaning. But business stakeholders don’t need more exploration. They need clarity. That requires structure.

Structure reduces cognitive load

When a report follows a beginning–middle–end structure:

• The audience knows where to start.
• They understand what matters.
• They aren’t left wondering what the conclusion is.

Structure removes interpretation work. It guides attention. It makes insight land. Without structure, even good visuals feel fragmented. With structure, even simple visuals feel powerful.

A practical test

I’ll use this story telling framework with my FPL dashboard in the next post. But try this on one of yours. Open one of your key reports and ask:

• Where is the beginning?
• What page establishes context?
• Where does the report clearly end?
• Is the implication explicit?

If the report simply stops after analysis, it’s unfinished.

If it doesn’t answer “what now?”, it’s incomplete. Storytelling in analytics isn’t about creativity. It’s about finishing the thought.

In the next post, we’ll use this framework and apply it to my FPL report. And in subsequent posts we’ll explore how the “hero’s journey” reframes your role as the report author — and why you’re not the hero in this story.

Related: Decision-Driven Analytics in Practice: A Fantasy Football Example

Start the series: Dashboards Don’t Drive Decisions (And That’s the Real Analytics Problem)

FPL Captain Choice with Power BI: A Story-Structured Report

If you’ve been following my series on data-driven storytelling, particularly the last post on structuring reports with a beginning, middle, and end, you’ll know I’ve been building toward something practical.

So now it’s time to apply that framework to my own FPL report.

Because if the structure works, it should work where the stakes are obvious: picking the right captain each week in your fantasy premier league team.

Turning My FPL Report Into a Story: Beginning, Middle, End

Your FPL captain choice is the most important decision you make each gameweek. This post applies the beginning–middle–end report framework to my Fantasy Premier League Power BI report and shows how to design it to deliver a clear recommendation.

Power BI report structure should follow stories

In the last post, I argued that a Power BI report should follow the same structure as a story:

Not because it sounds nice. Because it reduces cognitive load and improves decisions. So let’s apply that properly. Not in theory. In Fantasy Premier League.

The beginning: why should I care?

In FPL, there is one decision each week that matters more than any other:

Who is my captain?

Get it right and you double the points of your highest-performing player. So you get the score of your best player twice! If you make the right selection.

Get it wrong and you can drop thousands of places overnight.

This isn’t just another metric. It’s the highest leverage decision in the game. So the beginning of the report must frame that explicitly.

Not:

• “Gameweek Overview”
• “Player Metrics”

But:

Who should I captain this week?

That is the context. That is the scope. That is the decision. Everything that follows exists to reduce uncertainty around that one question.

If the opening page of the report doesn’t make that obvious within seconds, it’s not doing its job. As you can see from the screen shot below of the report page aptly named Beginning – Which player should I captain this week� the data suggested based on estimated points next week that the captain should be Cole Palmer or Nico Reily with a bit of Power BI Co-pilot for a bit of fun too.

The middle: what’s happening and why?

Once the decision is framed, we move into the middle.

This is where most dashboards live. But in a story structure, this part has a job: to build confidence in the decision.

In FPL terms, that means analysing:

• high form players
• high projected points
• strong historical scorers
• good value players
• position-based comparisons

But here’s the discipline: We only include what influences the captaincy or transfer decision. Not everything.

1) High form players

Form is one of the clearest short-term signals in FPL. If a player has scored well in the last 3–5 gameweeks, that’s meaningful momentum. So the report should clearly surface:

• Top  players by form
• With context (position, price, minutes played)

Not buried in a table with rows and rows of data. It should be highlighted. Because form directly influences captain confidence.

2) High projected points (EP_Next)

Projected points matter because captaincy is a forward-looking decision, you have heard it all before, “Past performance does not mean future returns”. Your report should clearly show:

• Top projected points overall
• And top projected points by position

This is where the story narrows. We’re not asking “Who is interesting?” We’re asking:

Who is most likely to deliver points this week?

So our middle section, page one of two aptly named Middle – Top Players by Form EP and Position�looks like this

3) High scoring but cheap – Good ROI for the business people out there

Transfers matter too. Let’s not forget that. The middle section should also surface:

• players with high total points
• relative to their cost
• with strong recent form

That’s how you identify value.

A £5.5m defender averaging 6 points per game might be a better transfer than a £7.5m underperforming midfielder.

The report should help answer:

• If I need a transfer this week, where is the value?
• Which positions offer upside?

This builds the case. This builds the confidence.

The end: what do we do next?

Now comes the part most dashboards miss. The ending. The implication. The recommendation.

Based on:

• form
• projected points
• value
• position comparisons

The report must land on:

This is the captain.

And optionally:

These are the top alternatives by position.

So one of the previous post in this series made Brent Ozar’s newsletter, it was the one called Data Overload Is Killing Decision-Making  and he added comment in his newsletter about my post that said “Gethyn Ellis says Data overload is killing decision-making, and I’ll add this one of the reasons people are leaning harder on AI to distill stuff” So I did, for my ending I got Power BI Copilot describe based on my data the best team this week. Here it is if you want it for Friday’s deadline

This doesn’t remove nuance. It removes ambiguity. It gives the manager clarity.

Why this works

This structure works because it aligns with how the brain processes decisions.

Beginning: Why should I care? → Captaincy decision.

Middle: What’s happening and why? → Form, projections, value.

End: What do we do next? → Captain selection + alternatives.

That’s not creative writing. It’s cognitive alignment.

What this means for business analytics

Now zoom out. Replace:

“Who should I captain?”

With:

• Which supplier should we renegotiate with?
• Which product should we prioritise?
• Which region should we invest in?

The structure is identical. Most business dashboards stop in the middle. The FPL example makes it obvious because the stakes are visible and immediate. If I publish an FPL dashboard that never tells me who to captain, it’s useless. The same should be true in business.

The real test

If someone opens your Power BI report and asks:

“So what should we do?”

Then your story hasn’t finished. In FPL, that costs you rank.

In business, it costs you clarity, speed, and alignment. That’s why structure matters.

Want to apply this beyond FPL?

Fantasy Premier League makes the stakes obvious.

Get the captain wrong and you drop rank. Get the decision wrong in business and you lose time, money, and momentum. The structure is the same.

Inside the Data Accelerator, we work with teams to move from reporting to decision support — starting with the decision, structuring reports with intent, and making the implication explicit.

If you’re serious about turning your Power BI reports into decision tools, not just dashboards, that’s exactly what we focus on.

In the next post, we’ll look at something even more uncomfortable: you are not the hero of the report — the audience is.

Related: Power BI Report Structure: Beginning, Middle, End

Example: Decision-Driven Analytics in Practice: A Fantasy Football Example

With the release of Microsoft SQL Server 2025, one of the most important, and most missed changes, isn’t about performance, security, or AI features. It’s about reporting. And SQL Server Reporting Services in particular.For years, organisations have relied on SQL Server Reporting Services (SSRS) for on-premises operational reporting, invoices, statements, regulatory extracts, and those “must-print” pixel-perfect outputs.In SQL Server 2025, released at the end of last year, Microsoft has drawn a clear line in the sand: SSRS is no longer moving forward as a standalone product, and on-premises reporting is now consolidated under Power BI Report Server.This post explains what’s changed, what’s bundled (and what isn’t), and how to think about your next steps.

A quick recap: what SSRS used to be

SSRS has long been the default Microsoft option for on-premises, server-hosted reporting. It’s best known for paginated reports (RDL): highly formatted, page-based reports designed for printing, exporting to PDF, or distributing by email.

It has been the workhorse for operational reporting in countless SQL Server estates, and for good reason: it’s reliable, mature, and fits well into traditional IT governance.

However, Microsoft has confirmed that SSRS 2022 is the final release of SSRS, and that there is no SSRS “version” shipping with SQL Server 2025.

Reference:

Reporting Services consolidation FAQ (Microsoft Learn)

So what replaces SSRS in SQL Server 2025?

The consolidated on-premises reporting platform is now Power BI Report Server (often referred to informally as “Power BI Reporting Services”).

Power BI Report Server is an on-premises server product that supports:

• Paginated reports (RDL) — the same report type SSRS was built for
• Interactive Power BI reports (PBIX) hosted on-premises
• A modern web portal experience, security integration, and standard report management capabilities

In other words: rather than shipping and maintaining two separate on-premises products (SSRS for RDL and Power BI for interactive reporting), Microsoft has aligned the on-premises story around a single report server.

Reference:

SQL Server 2025 announcement (Microsoft Tech Community)

Is SSRS and Power BI Report Server “bundled into the same product”?

Not as two separate installs. The practical change is this:

• SSRS is not included with SQL Server 2025 as a new, updated SSRS release.
• Power BI Report Server is the consolidated on-premises reporting product going forward.
• Power BI Report Server supports both RDL (paginated) and PBIX (interactive) reports on-premises.

So if your question is: “Do I now have one on-premises reporting platform that covers both SSRS-style paginated reporting and Power BI-style interactive reporting?”  the answer is effectively yes, via Power BI Report Server.

If your question is: “Is SSRS still bundled as its own separate reporting feature in SQL Server 2025?” — the answer is no.

Why this matters for organisations running SSRS today

If you’re currently using SSRS heavily, you do not need to panic, but you do need a plan.

SSRS 2022 remains supported under its lifecycle, but Microsoft’s direction is clear: future on-premises reporting investment is centred on Power BI Report Server.

This matters because many estates still treat SSRS as a default dependency, embedded in operational workflows, tightly coupled with SQL Agent jobs, triggered exports, scheduled subscriptions, and business-critical PDF pipelines.

The good news is that RDL and paginated reports remains a first-class citizen in the on-premises world via Power BI Report Server,  you’re not being forced to redesign everything as dashboards overnight.

What should you do next?

Here’s a sensible, low-risk approach:

1. Catalogue your SSRS reports and classify them (operational/regulatory / management / ad-hoc).
2. Identify the “hard” ones: complex subscriptions, custom extensions, unusual authentication, or legacy dependencies.
3. Stand up Power BI Report Server in a test environment and validate a representative set of RDL reports.
4. Decide your target model: on-premises PBIRS, cloud Power BI, or a hybrid approach.

Reference:

Power BI Report Server overview (Power BI)

Conclusion

SQL Server 2025 marks a clear change in Microsoft’s reporting roadmap. SSRS as a standalone product isn’t moving forward in new SQL Server releases, and Power BI Report Server is now the consolidated on-premises reporting platform that supports both paginated (RDL) and interactive Power BI reporting.

If you’re responsible for an on-premises SQL Server estate, now is the time to understand the shift, assess your SSRS footprint, and plan your reporting future in a controlled way, before the change becomes urgent in a few years time.

Need help migrating from SSRS?

If you’re running SQL Server and relying on SSRS for operational reporting, now is the time to plan your next move.

We help organisations:

• Audit and rationalise SSRS estates
• Design and deploy Power BI Report Server environments
• Migrate reports safely with minimal disruption
• Modernise reporting architecture (on-premises, cloud, or hybrid)
• Improve performance, security, and governance

Whether you need a structured migration plan, hands-on technical support, or strategic guidance on your reporting roadmap,
we can help you move forward with confidence.

Book a Reporting Strategy Call

---

Useful Links

Best FPL Team so Far This 2025/2026 Season: Using Power BI to Analyse Points, Form, and Player PerformanceOne of the best things about Fantasy Premier League (FPL) is that it feels analytical, at least it is to me. I know for many folk most decisions are still driven by gut instinct, social media hype, or last week’s highlights. Over the weekend, I was listening to a football radio show (names withheld to protect the guilty) where the presenters were debating their players of the season so far.It sparked a simple question:

What happens if we let FPL data decide?

Rather than opinions, narratives, or club bias, I decided to use my Power BI FPL model to answer two very specific questions:

1. Who are the best-performing players this season so far, based purely on points?
2. Who are the players in form right now, based on recent performance?

The results were interesting, and in one case, mildly controversial.

Ranking Players by Total FPL Points

The first step was straightforward. I already have a Power BI semantic model with:

• A Detailed Player Data fact table (match-level FPL data)
• Dimension tables for Player, Club, and Position

To rank players objectively, I added a DAX measure that calculates a dense rank across all players based on total FPL points.

Player Rank Measure (Season to Date)

Player Rank in Club = RANKX( ALL ( 'Player Data (Dim)'[Player Name] ), CALCULATE( [Total Player Points] ), , DESC, DENSE )

This measure ignores any filters on individual players and ranks everyone globally by points scored so far this season.

Building the “Best Team So Far” in Power BI

With the ranking measure in place, I created four table visuals in Power BI, one for each position:

• Goalkeepers
• Defenders
• Midfielders
• Forwards

Each visual was filtered by position and sorted by Player Rank. From there, I selected the top performers to assemble a 15-man FPL squad.

To be clear:

• This team does not consider FPL budget constraints
• It sticks to the FPL squad requirements
• It is purely performance-driven

The Best FPL Players So Far (By Points)

Goalkeepers

• Robin Roefs – Sunderland
• Jordan Pickford – Everton

Defenders

• Gabriel – Arsenal
• Marc Guéhi – Crystal Palace
• Trevoh Chalobah – Chelsea
• Jurriën Timber – Arsenal
• James Tarkowski – Everton

Midfielders

• Declan Rice – Arsenal
• Antoine Semenyo – Bournemouth
• Bruno Guimarães – Newcastle
• Bruno Fernandes – Manchester United
• Morgan Rogers – Aston Villa

Forwards

• Erling Haaland – Manchester City
• Thiago – Brentford
• Jarrod Bowen – West Ham

Two observations stand out immediately:

1. This squad would leave you around £17m over budget
2. There isn’t a single Liverpool player in the list

Data can be uncomfortable like that.

The Problem with Total Points

Season-long points are useful, but they have a major weakness: recency bias works both ways.

• A player who started the season hot but faded still ranks highly
• A player returning from injury or hitting form late can be under-represented

To solve that, I introduced a form-based approach.

Measuring Player Form (Last 30 Days)

Instead of looking at the entire season, I created a measure that calculates average points over the last 30 days, based on actual kickoff times.

Player Form Measure

Form = VAR TodayDate = MAX('Detailed Player Data (Fact)'[Kickoff_Time]) VAR StartDate = TodayDate - 30 RETURN CALCULATE( AVERAGE('Detailed Player Data (Fact)'[Total Points]), 'Detailed Player Data (Fact)'[Kickoff_Time] >= StartDate && 'Detailed Player Data (Fact)'[Kickoff_Time] <= TodayDate )

This dynamically adjusts as new matches are played, ensuring that form always reflects current performance, not historical reputation.

---

Ranking Players by Form

With form calculated, I applied the same ranking logic as before.

Player Rank by Form

Player Rank Form = VAR ThisPlayerForm = [Form] RETURN RANKX( ALL ( 'Player Data (Dim)'[Player Name] ), CALCULATE( [Form] ), , DESC, DENSE )

Now I can instantly answer questions like:

• Which defenders are actually delivering right now?
• Are premium midfielders justifying their price recently?
• Is a forward on a hot streak or living off one big haul?

This is where Power BI really shines: switching between season consistency and short-term momentum without rebuilding anything.

Why This Matters for FPL Strategy

Using both views together gives you a much stronger decision framework:

• Total points highlight reliable, season-long performers
• Form identifies momentum, rotation risk, and short-term opportunity

If you’re planning transfers for the second half of the season, form-based rankings are often the difference between climbing the mini-league and standing still.

More importantly, this approach removes emotion from decision-making. No hype. No narratives. Just data.

From FPL to Real Business Decisions

What I’ve described here isn’t really about Fantasy Premier League.

It’s about:

• Clear metrics
• Trusted models
• Decision-making backed by data

The same principles apply whether you’re picking an FPL captain or making multi-million-pound business decisions from dashboards.

Want This Level of Clarity in Your Organisation?

If your reporting feels slow, inconsistent, or hard to trust, that’s exactly the problem my Data Platform & Analytics Accelerator is designed to solve.

It helps organisations:

• Build reliable Power BI and Microsoft Fabric foundations
• Define consistent metrics that people actually trust
• Move from dashboard noise to decision clarity

Book a call today to discuss the Accelerator and see how it could work for your organisation:

Book an appointment to talk about the Data Platform Accelerator

Because whether it’s FPL or the boardroom, better data always wins.

Useful Links

Why Data Platforms Like Microsoft Fabric Don’t Fix Broken Data Culture

Why Reporting Slows Down as Organisations Grow

Xander’s First Season – A Proud Dad’s Reflection

Power BI & Microsoft Fabric Consulting and Training | 2025 Review

As the final working day of 2025 draws to a close here at GRE Towers, it feels like the right time to reflect on what has been another highly successful year for data consulting, Power BI delivery, Microsoft Fabric projects, and technical training.

Throughout 2025, we’ve worked with organisations across the public sector, private sector, fintech, insurance, retail, and not-for-profit space, helping them make better decisions using data.

Data consulting highlights from 2025

Over the past year, our data consulting and advisory services have included:

• Embedding Power BI dashboards directly into a fuel delivery company’s application
• Providing a Virtual DBA service to a large software licensing company, managing and optimising their SQL Server estate
• Delivering ongoing Virtual DBA services for a fast-moving retail organisation
• Designing and architecting a Microsoft Fabric deployment for a local authority
• Providing fractional CEO and CTO services to a healthcare startup (more on this in 2026)
• Delivering fractional CIO / CTO support to NICS Wellbeing
• Supporting a large insurer with data strategy, business alignment, and BI modernisation, including a roadmap to migrate legacy BI infrastructure to Microsoft Fabric
• Optimising Power BI and Microsoft Fabric capacity for an insurer, delivering significant cost savings on their F512 capacity
• Implementing a data engineering solution for risk reporting with a fintech operating in the insurance broker space

These projects reflect a growing demand for modern analytics platforms, cost-effective Fabric capacity planning, and strategic data leadership.

Power BI, Microsoft Fabric, and SQL training delivered in 2025

Training remains a core part of what we do, and in 2025 we delivered a wide range of bespoke and commercial training programmes, including:

• Bespoke Power BI training for a leading food manufacturer
• Bespoke Power BI and Paginated Reports training for two leading UK police forces
• Bespoke Microsoft Fabric training for a large local authority
• SQL training for a large local authority
• Authoring a commercial PostgreSQL DBA training course for a major training provider
• Delivering multiple Microsoft-certified courses for large Microsoft training partners

Our training focuses on real-world use cases, ensuring teams can apply what they learn immediately.

Data consulting and training plans for 2026

Looking ahead, 2026 is already shaping up to be another strong year.

Consulting in 2026

• Continuing data engineering and risk reporting work with a fintech in the insurance broker space
• Ongoing Virtual DBA services for a large software licensing company
• Continued SQL Server and platform support for fast-moving retail
• Supporting a not-for-profit organisation with Power BI development, focusing on KPI reporting and insight delivery

Training in 2026

You can view our public training schedule on the website, with new dates added regularly.

Looking for Power BI, Microsoft Fabric, or data consulting support in 2026?

If you’re planning to improve your data analytics, reporting, or platform strategy in 2026, now is the ideal time to start the conversation.

Whether you need:

• Power BI development or optimisation
• Microsoft Fabric architecture and cost optimisation
• SQL Server or PostgreSQL DBA support
• Fractional CIO / CTO or data leadership
• Tailored training for your team

We can help.

Moneyball in Madrid: Data, Decisions, and a Weekend of FPL Analytics

I’ve spent the weekend in Madrid delivering my talk “Moneyball: Building a Killer Fantasy Football Team with Power BI.”It was a brilliant event, and despite my session being in English, the turnout was fantastic. A big thank you to everyone who came along, engaged with the content, and stayed behind afterwards to ask questions. Events like this remind me why I love blending data, football, and teaching.

One question stood out above the rest. Joaquín González Galdo LinkedIn profile asked:

“What is the key metric you use when making decisions in FPL?”

It’s a deceptively simple question, yet powerful. Choosing a single metric to define your decision-making process is something every analyst and FPL manager wrestles with. It deserves a full blog post of its own, and it’s the kind of question I’ll be bringing to the next episode of the Power BI FPL Show with Ben Ferry and Justin Bird. There’s a lot to unpack, from expected points to form trends, fixture difficulty, and effective ownership. Watch this space for a deeper dive.

Power BI File and API Scripts Now Available

During the session, I promised to make my Power BI file available, along with the PowerShell script I used to connect to the FPL API and pull individual player gameweek data. I’ve now uploaded everything to my GitHub hub repo, and you can access it here:

Feel free to explore, clone, modify, and test the model. The Power BI report demonstrates how to build a star-schema model for FPL, how to perform gameweek-level analysis, and how to apply metrics and calculations that help drive decision-making. The PowerShell connector script is lightweight but effective, making it a useful starting point for anyone wanting to extend their own FPL-powered data pipelines.

When Your Internet Fails and You Panic-Transfer Your Keeper

Ironically, just as I was demonstrating the value of data-driven decisions, the venue Wi-Fi failed—leaving me
unable to update my own team live during the talk. Classic.

Once I returned to a stable connection, the first move I made was in goal: Roefs out, Henderson in.

Henderson’s estimated points came in at around 7, compared with Roefs at 2.7, making the swap a straightforward one under my evaluation framework. Even small improvements at the goalkeeper position can meaningfully shift weekly variance, so this one was a no-brainer.

Semenyo vs Grealish – A Tale of Two Underperformers

I’m still torn on whether to transfer out Semenyo. His numbers and projected points definitely suggest that he should go—yet selling him would mean losing team value. Value preservation is a key element of long-term strategy, so for now he survives.

Grealish, however, hasn’t been pulling his weight either, and unlike Semenyo, I’m not emotionally invested in holding him. His form has dipped, and Everton have been erratic.

So I made the switch: Grealish → Harvey Barnes (Newcastle United)

Barnes has been sharp, has strong underlying metrics, and a very favourable run of fixtures. There’s also some interesting off-the-pitch chatter about him potentially switching international allegiance to Scotland following their World Cup qualification, nothing like a burst of motivation to keep his form trending upward.

Woltemade Out – But Who Comes In?

The next move was shipping out Nick Woltemade. West Ham’s Callum Wilson is in form, and although the fixture against Liverpool looks challenging on paper, the FDR simply isn’t capturing how poor Liverpool have been defensively. There’s a part of me that thinks Wilson could genuinely haul. He’s clinical, he’s confident, and he loves a headline moment.

The alternative I’m considering is Igor Thiago from Brentford. He’s less injury-prone than Wilson, he’s been ticking along nicely, and the fixtures are much kinder. His underlying numbers put him firmly in the “viable punt” category. I may still pivot before the deadline.

I chose Thiago.

When Gut Instinct Creeps Back In

One thing I admitted during the session: over the past few weeks, I let my gut start to override my framework. With Manchester City’s tough run of matches, I tried to be clever and avoid captaining Haaland. It hasn’t paid off. This week, the data actually suggested that Harvey Barnes could be a viable captaincy option. His estimated points placed him right in the conversation. But there’s one metric that trumps everything: effective ownership. Haaland’s remains huge. If he hauls—and he’s due—going without him as captain would be catastrophic.

So, despite Barnes being a legitimate option under the model, I’ve done the sensible thing: Haaland is back as captain.Here’s my final lineup

A good reminder that data-driven decision-making is a discipline. It requires consistency.

Final Thoughts

Madrid was superb. Great city, great people, great conversations, and a great reminder of how global the FPL and Power BI communities have become. I’ll be writing more about key metrics, decision frameworks, and how to build your own analytics workflow for Fantasy Premier League.

Until then, enjoy the files, enjoy the data, and good luck for the gameweek ahead.

Useful Links

Exploring Microsoft Fabric Through Fantasy Premier League Data

The Cost of Doing Nothing: How Ignoring Data Strategy Drains SME Growth

How to Win at Fantasy Premier League Using Data Analytics and Power BI