Episode Details

Here’s a brutal truth: managing BI without ALM is like building a skyscraper with Jenga blocks. It all looks fine—until someone breathes on it. Here’s what this video will give you: first, how to treat Power BI models as code, second, how Git actually fits BI work, and third, how pipelines save you from late-night firefighting. Think of it as moving from duct tape fixes to a real system. We’re not here to act like lone heroes; we’re here to upgrade our team’s sanity. Want the one‑page starter checklist? Subscribe or grab the newsletter at m365 dot show. And before we talk about solutions, let’s face the core mess that got us here in the first place.Stop Emailing PBIX Files Like It’s 2015Stop emailing PBIX files around like it’s still 2015. Picture this: it’s Monday morning, you open your inbox, and three different PBIX files land—each one proudly labeled something like “Final_V2_UseThisOne.” No big deal, just grab the most recent timestamp, right? By lunchtime you’ve got five more versions, two of them shouting “THIS ONE” in all caps, and one tragic attempt called “Final_FINAL.” That’s not version control. That’s digital roulette. Meanwhile, you’re burning hours just figuring out which file is “real” while silently hoping nobody tweaked the wrong thing in the wrong copy. On paper, firing PBIX files around by email or Teams looks easy. One file, send it over, done. Except it never works that way. Somebody fixes a DAX measure, another person reworks a relationship, and a third adds their “quick tweak.” None of them know the others did it. Eventually all these edits crash together, and your so-called “production” report looks like Frankenstein—body parts stitched until nothing fits. And when things break, you’re left asking why half the visuals won’t even render anymore. The real danger isn’t just messy folders. It’s the fact you can lose days of work in one overwrite. That polished report you built last week? Gone—replaced by a late-night hotfix someone dropped into “Final.pbix.” Now you’re not analyzing, you’re redoing yesterday’s work while cursing into your coffee. It feels like two people trying to edit the same Word doc offline, hand-merging every edit, then forgetting who changed what. And suddenly you’re back in that Bermuda Triangle of PBIX versions with no exit ramp. Here’s a better picture: imagine ten people trying to co-author a PowerPoint deck—but not in OneDrive. Everyone has their own laptop copy, they all email slides around, and pray the gods of Outlook somehow keep it consistent. Kim’s pie chart is slotting into slide 8 on her version but slide 12 in Joe’s. Someone else pastes “final numbers” into totals that already changed twice. Everyone pretends it’ll come together in the end, but you know it’s cursed. Power BI isn’t any different—PBIX files don’t magically merge, they fracture. And yes, the cost is real. Teams I’ve worked with flat out admit they waste hours untangling this. Not because BI is impossible, but because someone worked off a stale file and buried the “real one” in their desktop folder. Instead of delivering insights, these teams run detective shifts—who changed which table, who overwrote which visual, and why the version sent Friday doesn’t match the one uploaded Monday. Business intelligence becomes business archaeology. Of course, some teams argue it’s fine: “We’re small, email works. Only two or three of us.” Okay, but reality check—at two people it might limp along for a while. Do a quick test: both of you edit the same PBIX in parallel for a single sprint. Count how many hours get wasted reconciling or fixing conflicts. My bet? Enough that you’ll never say “email works” again. And the second your team grows, someone takes PTO, or worse—someone experiments directly in production because deadlines—everything falls apart. Look, software dev solved this problem ages ago. Treat your assets like code. Put them somewhere structured. Track every single change. Why are BI teams still passing PBIX f