Behind the Research: The Charter That Never Gets Written
Most private cloud projects die because of budget urgency. Companies spend millions on hardware before they’ve defined the outcome. As James Harless puts it: it’s like pouring a foundation for a house, then deciding mid-build you actually needed an apartment complex.
This is Priority 2 in World Wide Technology's Data Center Priorities series: Private Cloud.
I’ve been producing research-driven content for tech companies for over a decade, and I’ve developed a specialized "cringe" reflex. It’s that physical wince you feel when you spot the gap between what an expert knows and what actually makes it into the official white paper.
It’s the difference between lived experience and "official guidance." Between war stories and marketing assets.
My recent conversation with James Harless about private cloud infrastructure hit that gap harder than most. Because according to James, the biggest threat to your data center isn't a security breach or a hardware failure. It’s budget urgency.
The "Quarterly Spend" Trap
During our discovery call, James and I went off-script almost immediately. I had my list of "safe" questions—drivers, technical specs, virtualization layers. But James kept circling back to something much more visceral: the "concrete" problem.
"Almost every customer fails at this," he told me. Not some. Not many. Almost every one. He wasn't being a cynic; he’s just a practitioner who has watched smart, well-resourced teams spend millions on sophisticated gear that delivers absolutely nothing the business wanted.
The failure pattern looks like this: A company realizes their public cloud bill looks like a phone number, or they have data sovereignty laws breathing down their neck. They decide to build a Private Cloud. Everyone gets excited. Heads nod in meetings.
Then, the "Budget Clock" starts ticking.
"We have money left this quarter and we need to buy the hardware right now."
So they buy the racks. They lay the foundation—literally and metaphorically. And only then do they try to figure out what they’re actually building. By that point, as James puts it, "It’s planted." You are now forced to build whatever those specific boxes allow, whether it matches the business need or not.
The Document That Acts as a Pre-Nup
In the actual episode, James introduced a concept that sounds boring but is actually a survival tactic: The Charter. It’s not a project plan or a technical spec. It’s a blunt agreement between business leaders and IT that answers three uncomfortable questions:
- What are we actually trying to accomplish?
- Why are we doing this? (No, "because cloud" isn't an answer).
- How will the business actually interact with this?
The Charter is "scope protection." It’s the document the technical team holds up when a stakeholder tries to add a 50th feature mid-build. It lets the engineers say: "That’s not what we agreed to build. If you want an apartment complex instead of a house, we have to go back to the steering committee and break the concrete."
Why "Capital-P" Private Cloud is a Culture Shock
James describes private cloud as a spectrum. On the far left, you have "lowercase" private cloud—basically just your old data center with a fresh coat of paint. On the far right, you have "Capital-P" Private Cloud. That right side is the "AWS experience" on-premises. It means self-service, cost transparency, and—this is the part that kills people—shared responsibility.
In a real cloud model, the "call a friend" culture of traditional IT has to die. If your database fails in AWS, you don't call Jeff Bezos; you check your dashboard. Most organizations say they want the speed of the right side of the spectrum, but they aren't willing to give up the control (or the manual labor) of the left side.
They try to "organically grow" a single-family home into a 50-unit apartment building just by tacking on rooms. It doesn't work in architecture, and it doesn't work in the data center.
The Part That Didn't Make the Cut
After we stopped recording, James mentioned why WWT's approach feels different: they’re developing these frameworks with customers in the trenches, not in a vacuum.
The Charter concept didn't come from a licensed methodology or a textbook. It came from James watching multi-million dollar projects "die in the crib" because of scope creep and executive misalignment. It’s reverse-engineered from failure.
Research gives you the roadmap, but conversations like this give you the location of the landmines. The real story isn't the tech—it's the discipline to agree on what you're building before the concrete truck shows up.