In Scope: The IT Services Podcast

The episode covers legitimate PMI-based project management concepts (project charter, WBS, bottom-up estimating, Parkinson's Law) but at an introductory level with significant filler, mutual affirmation, and banter padding. A smart MSP operator familiar with basic PM methodology would extract only a handful of actionable ideas.

“I generally don't recommend showing the client your work breakdown structure. Two reasons. One, then they start negotiating with you...also, we're not giving someone our secret sauce to go show our competitor either.”

“Work fills to the time allotted.”

The content is almost entirely standard PMI methodology repackaged for an MSP audience; Parkinson's Law is decades old, WBS and bottom-up estimating are textbook concepts, and the framing adds little first-principles thinking. The 'organizational voice' metaphor is a nice articulation but not a new idea.

“much of my background is PMI based...a lot of the aspects that I speak of, the concepts I speak of are straight from PMI Project Management Institute”

“So I'll give you the deduced version of it. Work fills to the time allotted.”

Josh has genuine practitioner roots as a project engineer and now coaches MSPs at scale through PAX8 Academy, making him relevant and credible for this audience. However, he is now primarily a trainer/coach rather than an active operator running projects at scale, which limits the depth of current real-world examples.

“I'm part of the academy branch of PAX8. We work with instructor led courses, peer groups, business coaching”

“My background being a project engineer, I would have a boss, they'd give me a project and I would just go get it done”

Virtually every example is hypothetical and character-named (Sue, Sally, Sam, Timmy, Jimmy); there are no named MSPs, no real project dollar figures, no actual gross-margin data, and no before/after metrics from real engagements. The episode is almost entirely abstraction.

“Let's say I've got Sue, Sally and Sam. We're going to give them a blank sheet of paper and I'm going to say, hey, I need you three to scope a server migration”

“We need a network segmentation because the client needs a network segmentation.”

The host is knowledgeable and occasionally surfaces interesting angles (chicken-and-egg sequencing of WBS vs. scope statement, proposals vs. SOW), but questions are mostly leading and softball, and the conversation devolves frequently into mutual agreement and self-promotion. There is no real pushback or productive disagreement.

“which one comes first? The work breakdown or the written language in your opinion, or can they come at the same time?”

“What's kind of your guidance around proposals versus statements of work? Like, do you think they're intended for the same purpose?”