I built my first Smart Manufacturing practice in 2006. I had zero direct reports, no budget, and honestly, no real idea what I was doing.
Twelve years later, that practice was generating millions in annual revenue across three continents. Then I did it again at a different company. And now I’m on the other side of the table, choosing which practices to work with.
So here’s what I learned. Not the polished LinkedIn version — the real one.
Start with One Thing You’re Actually Good At
In 2005, I stumbled into SAP xMII. Not because I was smart, but because a client needed it and nobody else wanted to touch it. Manufacturing integration middleware wasn’t sexy. It still isn’t.
But I learned it deeply. I became the person people called when xMII broke at 2 AM. That reputation — being the person who actually fixes things — matters more than any positioning statement.
Your first practice won’t be built on a diversified portfolio. It’ll be built on one thing you do better than the consultants at the bigger firms. For me, it was xMII and plant-floor connectivity. For you, it might be OPC UA, historians, MES, or edge architecture.
Pick one. Get really good at it. Everything else comes later.
Your First Win Comes from Someone Who Already Trusts You
I didn’t win my first Smart Manufacturing project through a competitive RFP. I won it because I’d already delivered an ERP implementation for that client, and the plant manager remembered that I actually listened to his problems instead of selling him a methodology.
He had a new problem: connecting several machines to a “middleware” so they could track OEE. The big SIs quoted six months and $800K. I quoted eight weeks and $120K, and I meant it.
We delivered in nine weeks. Not perfect, but good enough. That project became the reference that opened the next five doors.
Your first practice client is probably someone you’ve already worked with. Go back through your network. Who trusted you before? Who has a manufacturing problem that nobody’s solving elegantly?
Start there.
Build the Accelerators While You’re Billing
Here’s the thing nobody tells you: you won’t have time to build reusable templates and accelerators before you need them. You’ll build them while you’re on a client project, late at night, because you’re tired of solving the same problem manually every time.
I built my first xMII template library during the nights, three weeks into a project where we had to connect 12 different PLCs. I was exhausted. I was copying and pasting the same transaction logic over and over. So I stopped, stepped back, and made it reusable.
That template saved me 40 hours on that project. Then it saved me 60 hours on the next one. By the third project, I had a library that could cut implementation time by 30%.
That’s how you build accelerators. Not in a lab. Not in a vacuum. You build them when the pain of not having them becomes unbearable.
And here’s the unpopular opinion: most “accelerators” that consulting firms sell are garbage. They’re built by people who don’t do the actual work anymore. Build yours while your hands are still dirty.
Hire Slowly, But Hire Before You Think You’re Ready
We waited too long to hire my first person. We were billing 60+ hours a week, turning down projects, and still trying to do everything myself because we were afraid of the overhead.
That was stupid.
When we finally hired someone — a sharp engineer who knew Wonderware and SQL — everything changed. Not because he took work off my plate (though he did), but because having someone to talk through problems with made both of us better.
Here’s what I learned about hiring for a practice:
- Don’t hire generalists early. You need specialists who can own a technology or a problem domain. Generalists are great later, but early on, you need people who can be the expert in something.
- Hire people who like to build things. Practice-building is scrappy. You’re going to be writing proposals at midnight, debugging PLC code in a plant that smells like burnt rubber, and figuring out pricing models on the fly. You need people who find that exciting, not exhausting.
- Hire before you have the project. This feels risky, but it’s less risky than losing a $2M opportunity because you don’t have capacity. I learned this the hard way when I had to pass on a multi-site MES rollout because I literally didn’t have the people.
Pricing is Guesswork Until It Isn’t
Early on, I had no idea how to price things. I’d guess. Sometimes I’d be way high and lose the deal. Sometimes I’d be way low and hate my life for three months.
What eventually worked: track everything.
I started logging hours by activity type. How long does an xMII installation actually take? How about PLC driver configuration? Historian integration? UAT?
After about 18 months and maybe 10 projects, patterns emerged. I could estimate an xMII-to-SAP integration within 15% accuracy. That’s when pricing stopped being terrifying.
I built a simple Excel model (yes, Excel — nothing fancy) that had standard hour ranges for every common activity. Installation: 40-60 hours. Configuration: 80-120 hours. Validation in a GxP environment: add 40%.
That model became the foundation of the practice P&L. We refined it every quarter based on actual project data.
Don’t overcomplicate this. You don’t need AI-powered pricing engines. You need a spreadsheet and the discipline to track actual vs. estimated.
Build Partnerships, Not Vendor Relationships
Around 2008, I started working closely with the software vendors whose tools we implemented — SAP, Wonderware, OSIsoft (now AVEVA), and later PTC (Kepware).
Some people treated these like transactional vendor relationships. I treated them like partnerships. I gave them feedback. I told them what was broken. I brought them into deals early. I invited them to speak at client workshops.
In return, they sent me leads. They funded proof-of-concepts. They gave me early access to new features. When a big manufacturing company needed an xMII expert, SAP recommended me.
That’s how you scale without a big marketing budget. The vendors in your ecosystem are your best source of qualified leads, but only if you actually add value to their business.
Create a Portfolio, Not Just Projects
By 2010, I had a problem: every deal felt like a one-off. We were good at delivery, but we had no repeatable story. Clients didn’t know what to buy from us.
So I sat down and mapped out everything we’d done into four service offerings:
- Equipment Connectivity & OPC (edge connectivity, drivers, protocols)
- Historian Implementation (OSIsoft PI, Aspen IP.21)
- MES & Manufacturing Integration (SAP xMII/MII/ME, Wonderware MES)
- Real-Time Dashboards & Analytics (KPI visualization, OEE, downtime)
Each offering had a 2-page service description, typical scope, pricing range, case study, and standard deliverables.
Suddenly, sales conversations got easier. Instead of “we do Smart Manufacturing stuff,” I could say, “We offer four core services. Based on what you’ve described, you probably need Equipment Connectivity and Real-Time Dashboards. Here’s what that looks like.”
That portfolio structure became the backbone of the practice. It made us look bigger and more mature than we were.
You’ll Compete with Bigger Firms — and Win
By 2012, we were regularly competing against Accenture, Deloitte, and the big SIs. We lost some. But we won more than we should have.
Why? Three reasons:
- We were faster. Big firms have 14-week mobilization processes. We could start in two weeks.
- We were cheaper. Not because we were low-quality, but because we didn’t have the overhead. No $400/hour partners billing for strategy decks. Just people who knew how to connect machines.
- We knew the technology. I can’t count how many times a big SI sent a “manufacturing expert” to a sales meeting who’d never actually configured an OPC driver or written an xMII transaction. Clients noticed.
Here’s the secret: clients don’t always want the biggest firm. They want the firm that will actually solve their problem. If you can demonstrate deep technical credibility and move fast, you’ll win deals you have no business winning.
Scale is About Systems, Not Heroics
By 2015, the practice was doing well, but I was still the bottleneck. Every proposal had to go through me. Every architecture decision needed my sign-off. I was the single point of failure.
That’s when I realized: if I wanted to scale, I had to build systems that worked without me.
I created:
- Proposal templates — standardized scope documents, pricing models, risk sections. My team could generate a solid proposal in 4 hours instead of 4 days.
- Architecture patterns — documented reference architectures for common scenarios (historian + MES integration, edge-to-ERP, GxP-compliant historian, etc.)
- Onboarding playbooks — 4-week onboarding program for new hires covering tools, client expectations, and delivery methodology.
- Quarterly practice reviews — pipeline review, resource planning, lessons learned, service portfolio updates.
None of this was revolutionary. But it meant the practice could run without me in every meeting. That’s when we really started to scale.
What I Wish I’d Known at the Start
- Start charging for pre-sales engineering. I gave away hundreds of hours of architecture work for free in “pre-sales.” Some of that won deals. Most of it didn’t. Now I know: if a client wants serious design work, they pay for it.
- Build case studies religiously. Every project should generate a sanitized case study. Even if you never publish it, you’ll use it in proposals. I didn’t start doing this until year three. I should have started at project one.
- Don’t chase every opportunity. I spent years saying yes to everything. Automotive projects, chemical plants, food and beverage, mining. Diversification felt safe, but it diluted our expertise. Later, when we focused (pharma and automotive), we became known for something. That’s when the inbound leads started.
- Raise your rates every year. Seriously. If you’re good, raise your rates 10% every year. You’ll lose some price-sensitive clients, but you’ll attract better ones. I left too much money on the table early on.
- Invest in your people’s certifications. Kepware certified, OSIsoft PI certified, SAP MII certification — these matter. Clients ask. They want to see credentials. Budget for it.
The Practice You Build Won’t Look Like Mine
I built practices around SAP MII, MES, and Edge-to-Cloud Connectivity because that’s what I knew in 2006. If you’re starting today, the landscape is different.
Maybe your practice is built on Unified Namespace and MQTT/Sparkplug B. Maybe it’s edge ML and predictive maintenance. Maybe it’s cloud historians and data mesh for manufacturing. Maybe it’s IIoT cybersecurity and OT network segmentation.
The technologies change. The fundamentals don’t.
Be really good at one thing.
Deliver what you promise.
Build while you’re billing.
Track your costs.
Hire before you’re ready.
Create systems, not heroics.
The rest is details.
One Last Thing
Building a practice is hard. You’ll have quarters where the pipeline is empty and you’ll panic. You’ll lose deals you should have won. You’ll hire someone who doesn’t work out. You’ll underprice a project and regret it.
That’s normal. Everyone goes through it.
The difference between practices that make it and practices that don’t isn’t talent or timing or luck. It’s persistence. The people who make it are the ones who keep showing up, keep refining, keep learning, and don’t quit when it gets hard.
I built my first practice because I was too stubborn to stop. Turns out, stubbornness is underrated.
Anyway — that’s the playbook. It’s not complete, and it’s definitely not perfect. But it’s real.
If you’re building your first practice, good luck. It’s one of the hardest and most rewarding things you’ll ever do.
And if you ever want to talk through it, you know where to find me.

Leave a Comment