Why Fixed-Fee ERP Implementations Win for Manufacturers – Rob Jolliffe of Sabre Limited, Part 1

Rob Jolliffe on Fixed-Fee ERP Implementation
The Integrate Intelligently Podcast — with Jeff Brickler, Scott Brickler (CADTALK), and Rob Jolliffe (Sabre Limited)

Rob Jolliffe of Sabre Limited joins Jeff Brickler and Scott Brickler to unpack how he built a fixed-fee, menu-driven ERP implementation model — why time-and-material billing creates perverse incentives, how tiered packaging kills scope creep, and why a mandatory support contract actually saves customers money.

Speaker note: three speakers again — Jeff, Rob, and Scott. Jeff opens as host and asks the framing questions; Rob carries almost the entire story of his own consulting practice; Scott steps in periodically, mostly recognizable by references to Eli Goldratt and to "CADTALK." A stretch in the middle — the book discussion and the "similar background" exchange right after it — moves quickly enough between Scott and Jeff that the attribution there is a best guess. Worth double-checking that section before this goes out publicly.

Introduction and Welcome
Jeff: Welcome back to the Integrate Intelligently podcast. I'm your host, Jeff Brickler, joined by two marvelous guests today — Robert Jolliffe from Sabre Limited, a Business Central VAR. Robert, thank you for joining.

Rob: Thank you for having me.

Jeff: And of course, our founder and CEO of CADTALK, Scott Brickler.

Scott: Glad to be here talking manufacturing.

Jeff: Robert, a bit of a story to kick us off — a few years back you gave a talk on fixed-fee ERP implementations at the Microsoft Business Central partner conference, Directions. I remember attending — it was one of my first ones, and I sat down in your session specifically. I'd love to hear what motivated you to build that model and how it's gone since.

Rob Jolliffe's Background in Manufacturing and ERP
Rob: Sure, happy to give some background, since it'll help explain where I'm coming from. My father and two of my uncles owned manufacturing companies when I was growing up. I like to joke that when I was in high school — maybe 14 — my dad's shipper-receiver quit right as summer vacation was starting, and my dad told me I was coming in to work that summer. Probably violated a few child labor laws, but that's how I ended up as a shipper-receiver in my dad's factory at 14 or 15. So I tell people I've been in manufacturing for 40 years, which gives away my age a bit.

I went to university for mechanical engineering, intending to become a production or manufacturing engineer, maybe move toward plant management or a COO-type role, or possibly engineering consulting. But I accidentally fell into ERP. I was always the guy at school who could fix a printing problem when WordPerfect wouldn't cooperate. I was good with computers, did IT service tech jobs in the summers — the kind where you carried floppy disks and a little screwdriver kit.

When I landed a job at a capital equipment manufacturer in Ontario — I'm Canadian, don't hold it against me — they wanted a part-time industrial engineer and part-time IT person. I convinced them I wasn't a great industrial engineer, so I ended up becoming their internal IT/ERP expert instead, self-taught. It wasn't a Microsoft ERP — the company's now owned by Infor — and they were engineer-to-order: some repetitive core components, but a lot of customized engineered solutions layered on top. That was different from my prior, more repetitive manufacturing experience, and it intrigued me.

After a few years there, being an outgoing guy, I'd go to user group meetings and talk about what I was working on, and people started offering me side work — "come do these reports for us." I started a practice out of my basement as an ERP consultant, and over about ten years, I probably visited 200 to 250 manufacturing companies running that particular ERP. I hired people along the way, going from just me to about ten people doing custom programming, training projects, and more.

The Question That Changed Everything: "Why Can't You Just Give Me a Price?"
Rob: I'd usually quote projects as time and material. I remember one production manager at a really unusual manufacturing company — they were turning 12,000-pound castings on an eccentric lathe, dealing with massive parts, two-story horizontal boring mills, the whole "land of the giants" feeling. He asked me, "why can't you just give me a price? I could never get away with billing my customers for time on a one-off job — well, maybe for a one-time thing, but why can't you price this?"

I started explaining the risk involved — I said something like, "your people could be incompetent, and if I'm supposed to train them, how do I control that? You're half of this project, I'm half of it." But it got me thinking: why can't I do fixed fee?

Why Time-and-Material Billing Creates Perverse Incentives
Rob: This was around 2008, right as the economy crashed — which, with great timing, is the exact year I decided to start selling Microsoft Dynamics. That didn't go well initially. But over the next few years, I realized I wanted to sell my own ERP rather than just service everyone else's, thinking I could do a better job and keep customers happier.

I ended up taking a Microsoft course on building repeatable, fixed-fee ERP projects — though they were talking about very small projects, maybe $20,000 max, narrowly targeted at a specific industry vertical. I went to Directions, learned about Dynamics NAV, and moved my practice over. Around the same time, I read an article on LinkedIn arguing that time-and-material billing is unethical — and I agreed with basically every point. If you go to a restaurant and get charged extra because a young chef wasted a few steaks learning to cook a proper medium-rare sirloin, that's not your fault to pay for. Time-and-material billing hides what you're really being charged, creates a perverse incentive to make projects take longer, and leaves the customer with a weaker incentive to speed things up — because the seller is usually not encouraging them to.

By 2016 or 2017, I'd developed a fixed-fee, or quasi-fixed-fee, model. Around the time I first spoke at Directions, I'd actually attended a session by a company selling fixed-fee, repeatable implementations — at $100,000, not $20,000. I'd been telling myself I had to price at $20,000 because nobody would pay more, but they pointed out it depends entirely on what your competitors charge — if competitors are at $200,000 and you're at $100,000, you're still the cheaper option and you'll win plenty of business. That was a lightbulb moment: it's not the cheapness that sells fixed fee, it's the fixed-fee-ness of it.

How Fixed-Fee Implementation Actually Works
Rob: Our implementation methodology combines an upfront fixed amount, invoiced in installments, plus a monthly retainer during the project. We make the customer responsible for more of the work than our competitors would, because I don't make money by doing those activities for them — competitors will upsell $250-an-hour work that a $30-an-hour employee could realistically handle. So we train the customer's own people to do things like changing the layout of a purchase order form, or adding terms and conditions — repetitive stuff they'll need to do themselves anyway. That way it's not billable to us, and it empowers them — teach a man to fish.

Video conferencing was the other piece that made this work. We record every training session, so if a customer calls back saying their team didn't understand something, we first find out who specifically didn't get it — often it's one person, meaning the training itself was fine. We tell them to rewatch the video and note what's still unclear, then we do a targeted deep-dive into just that section. A lot of the time, they rewatch it, realize what they missed, and don't even need us. Our model requires them to rewatch first — some skin in the game — but once they've done that and there's still a genuinely confusing 12 minutes, we'll spend half an hour clarifying just that part. It's worked very well; customers are generally happy with it. We've had a couple of clients who wanted their own project manager dictating our process — that doesn't work for us. It has to follow our methodology.

Rob: Can I add one more thing? I don't want to just blather on.

Scott: No, you're fine.

Applying Lean Thinking and Theory of Constraints to ERP Projects
Rob: This whole model creates room for continuous process improvement, and I'm a Lean Six Sigma guy — my engineering background took me down the Theory of Constraints path. I've read every Eli Goldratt book and listened to every recorded seminar I can find. I've read Lean Thinking about six times, and I've taken —

Scott: I think "It's Not Luck" is actually the more important book, by the way.

Rob: What's that?

Scott: I think "It's Not Luck" is a more important book than "The Goal."

Rob: Yeah — "It's Not Luck" is a fascinating book, it's the sequel, still following Alex Rogo, except now the Theory of Constraints approaches he'd set up have broken down and stopped working — the bottleneck processes just aren't holding. Really interesting book. Anyway, I've been applying my own variation of the seven Muda — the seven wastes — to ERP projects. That includes things like having someone overqualified do work that doesn't need that skill level, which is its own kind of waste, or overtraining someone on things they don't actually need. A lot of our model is about narrowing down, early in the project, exactly what a given customer needs, rather than training on everything and wasting everyone's time and money sitting in a class for things they'll never use.

That means some of our customers take a bit longer to go live than with our competitors, but when they do go live, the error rate is really low, support stays smooth, and it's not the disaster-day-one experience a lot of ERP projects turn into.

Scott: That's really interesting — similar background here. The idea that if your process is consistent enough, you can actually apply Theory of Constraints to it, but if every project is bespoke chaos, you can't get enough repeated iterations to even see where the real problem is.

Rob: Right — and I'll add one more thing: if you run this as a project with PMPs in charge, they tend to treat every project as inherently bespoke and recreate the wheel each time, because uniqueness is where they feel their value comes from. I don't have project managers — I have an operations manager and project coordinators who report to them. The operations manager is responsible for consistency across all projects, and they're incentivized to build repetition into the process rather than chase uniqueness and turn every project into its own snowflake.

Scott: That's a cool way to approach it — it's really the only way you can extract value on both ends of the deal, so it works for you and it works for the customer. That's the win-win you actually want.

Scott: Listening to your story, it just felt so familiar — very similar background to mine. I'd agree with you 100%, it's a great way to approach it.

Rob: Yeah, thank you.

Tiered Packaging: Basic, Enhanced, and Premium Scopes
Jeff: How did you handle — one of the hardest things I remember from being on projects is scope creep. It's always "hey, can you just do this one little thing" — I get it even with contractors at my own house, the plumber's there to fix a faucet and suddenly it's "oh, and my toilet's been running too." Nothing malicious, it's just natural. How do you handle that?

Rob: The best way to think about our projects is there's a box, and within that box, customers can adjust things as much as they want — an extra user field here, a report tweak there, printing something landscape instead of portrait. Since we train customers to handle the aesthetic side of reports themselves — and some clients get very specific, down to font size and gray-scale percentage and exact positioning — we don't have to worry about that at all.

When I originally built these projects, I sat down with my team and identified where the real variability was versus where things were predictable. We kept the predictable stuff tightly controlled, and delegated as much of the variable stuff as possible to the customer, so a lot of what would be "scope creep" for competitors becomes self-service for our customers.

The second layer is that our fixed fee comes in three tiers — like a cable package: basic, enhanced, and premium — built around a "minimum viable go-live." If a customer picks the middle tier and their team starts asking for top-tier features, it's a simple conversation: upgrade to the top tier. Then they have to go to their boss and justify spending, say, an extra $20,000 — and 99% of the time, once they have to make that case, the answer is "never mind, we're fine."

Shifting the Right Work to Customers (Teach a Man to Fish)
Rob: One of the real advantages of moving from time-and-material to fixed fee is that almost all the arguments disappear — there's no "why wasn't this in the plan," because they chose their tier from predefined, published options on our website. If someone asks why they were made to choose tier two, the answer is: we didn't make you choose anything, do you want to upgrade to tier three now? It's like ordering an eight-ounce steak and wishing you'd gotten the twelve — do you want to buy another steak? The menu model has essentially eliminated scope creep as a problem. The one exception: custom programming stays time-and-material and is explicitly outside the fixed-fee project scope from day one.

Scott: Selfishly, I'm sitting here thinking about how this applies to our own side of things, Jeff.

Jeff: One of the reasons I went to Robert's talk in the first place — and I'm glad we're finally discussing this — is that I love this idea. It's a little selfish of me, Robert, but I think we already do part of this today, and I think we could push it even further toward a menu-driven model like yours.

Scott: I've been pushing in that direction since I first heard your talk years ago — not quite to the extent you've built it out, but really trying to drive toward it.

The Mandatory One-Year Support Contract
Rob: One last piece of information that's genuinely useful for anyone listening who's evaluating an ERP system: we require a mandatory one-year help desk support contract. It's robust — you can pull consulting hours out of it too — I call it a continuous improvement support contract, since manufacturing process improvement is where I live.

Early on, we didn't require this, and what happened is customers would try to DIY things because they didn't fully understand the ERP and didn't want to get billed $200–250 an hour just to ask a question. That led them to paint themselves into corners and create bigger problems trying to save what might have actually been very little money — especially since a lot of ERP vendors bill in half-hour or hour minimums, so a five-minute question turns into a hundred-dollar bill, like calling a lawyer or an accountant.

To prevent customers from abusing an open-ended support contract on one side, and being scared to ever call on the other, we put a governor on meeting frequency — you can book meetings, but only one at a time, so you have to wait for the current one to finish before scheduling another. Beyond that, help desk tickets — closed-ended, "here's my question, there's an answer" — are unlimited. And if we need to get on a call or into your system to fix something, you have to be present for it. That keeps people from just dumping problems on us and disengaging — since they have to be there anyway, they might as well learn how to do it themselves the first time.

Operations Managers vs. Traditional Project Managers
Rob: That's really cut down on customers fumbling around on their own, getting stuck, getting frustrated, and quietly retreating back to Excel. Now there's no excuse not to call, since it's a flat monthly amount that barely covers our cost but gives them real value.

Jeff: We had something similar — this was actually the original intent behind that idea, Scott. With any software you sell and service, including CADTALK, customers won't call you if they don't have that built-in support relationship. The risk if they don't call is twofold: either they DIY it and break something, or they say nothing and quietly suffer — and then they're just unhappy. "This thing is terrible, Robert sucks, Microsoft's terrible," all of it.

Scott: Absolutely.

Jeff: You don't want that. You want the customer genuinely pleased with the implementation and the product — and usually it's not that the product is bad, it's that they're a bit stuck and don't want to ask.

Scott: You don't know what you don't know. If there's nobody to ask, you just make assumptions.

Rob: That's a really smart way to structure it — it aligns the incentives for everyone. Some customers use it a lot, some barely use it, and it evens out over time, kind of like an insurance policy in the end, and everybody benefits.

Rob: I like to describe it like those old dial-up internet providers who'd sell a megabyte of bandwidth but then sign up a hundred people sharing ten megabytes between them, assuming they'd never all log on at full speed at the same time — which, famously, happened when George Lucas released The Phantom Menace trailer around 1999 and crashed a chunk of the internet with the first massively downloaded movie preview ever. I remember everyone complaining about their internet that week. It's the same principle — shared across many customers who aren't all drawing on it at the exact same moment, so it works.

Scott: That's basically how banks work.

Rob: Yep, 100% — everybody's pooling their money. Nobody likes banks, though, so hopefully this goes over a little better.