More companies are handing enterprise projects to their functional leaders and SMEs. But few are recognizing it for the org design decision it is—and the ones that don’t are introducing immense risk, eroding value, and slowing down their strategies.
Late last year, a potential client I’d love to work with approached us about a training need. Their most recent three projects hadn’t gone well, with one creating real compliance risk due to a missed requirement and overlooked dependency.
“We need to train our business SMEs in the basics of project management,” they said.
“Say more,” I prompted. “What’s the role of these leaders?”
I wasn’t surprised by their answer.
The organization used departmental managers and subject-matter experts to run enterprise projects.
And when I say “run,” I mean plan and manage the project, gather and articulate requirements, oversee a vendor (often the implementation partner on an ERP, CRM, or HRIS rollout), and design and execute testing, training, and rollout.
All this in addition to demanding day jobs.
These folks were “accidental project managers” trying to run enterprise-critical work without the time, role, or mandate to do it right.
Before I wrote a proposal, I asked them one question. “Let’s assume we did a two-day training. How much of those tools, habits, and skills could your business people reasonably take on in addition to their day jobs?”
“Almost none,” they said.
Reluctantly, I turned the business down. I’ve got a rule. I don’t take money for work I don’t think will add value.
Instead, I pitched an experiment. Take your two highest-risk projects. Put a real, dedicated PM on them—contract, redirected, or promoted from within. Make sure to pick someone who wants the job. Give them training and coaching. Then measure what happens.
If those projects perform better, measure the savings in effort, time, and rework, as well as the avoided risk. Then decide whether to scale the model.
They appreciated the candor. They took the advice. We didn’t get the business. And I couldn’t be prouder of that.
But here’s what I’m noticing. The gap between what that client came in to buy and what would have worked shows up almost everywhere I go now. That’s what this issue is about:
When and how should organizations use SMEs as project managers?
And what can PMOs do to steer organizations to what works…not just what’s easy to pitch?
Does Your Org Have Invisible Project Managers?
Probably. In the PMOs I work with, dedicated project managers are scarce, and more enterprise-critical work is being handed to functional managers and subject matter experts who already have a full day job.
And the model can work (sometimes).
When a project is contained within one department, when the SME has real room in their schedule, when the scope is tight, and the stakeholders are few, an SME-led project often gets the job done.
But the projects a PMO owns usually aren’t any of those things. They’re enterprise-wide. They touch multiple departments. They have dependencies that the department-level SME can’t see. They often involve vendors the SME has never worked with before. And they carry real strategic weight, which means every missed requirement or overlooked dependency has downstream consequences.
That’s where the accidental project manager gets set up to struggle. They’ve been asked to be the PM, the BA, and the department lead at once, with formal training in only one. And usually a fraction of the time needed for any of them.
Choosing to use “utility players” to run these projects is an easy choice. No budget ask needed or political capital spent to get the help.
But this strategy is an organizational design choice, just like decisions about reporting structures or department boundaries. It has trade-offs as well as preconditions that lead to success or failure. Success requires:
- Realistic allocations (“day job” to project work)
- Desire to do all the jobs (motivation matters)
- Aptitude in all three areas: project coordination, business analysis, and operational duties
- Surgical help in key areas (like training material, test case build-outs, etc.)
- Clear vendor roles and accountabilities
- And yes, training and coaching
Orgs that don’t design around these constraints are introducing unnecessary risk, eroding value, and slowing down their strategy execution.
How SMEs Became PMs: A Theory
Since work environments shifted to virtual or hybrid, more of the work we do happens without leaders watching. I think that has a lot to do with why the accidental PM problem has accelerated.
Before the pandemic, busyness was something you could observe. You walked past someone’s desk and saw the stack of documents, the half-eaten lunch, and the sticky notes climbing up the monitor. You noticed who was running between meetings. You could tell when someone was fried.
Overload had a posture. And managers calibrated who to lean on (and who to leave alone) using that visible signal.
Now, everyone looks the same on a screen. Slack dots go green whether someone is reviewing test cases, stuck chronically answering “quick questions,” or staring at the ceiling. Calendars fill up with work no one else can see the weight of.
When a new project launches and a leader asks, “Who can take this on?”, the answer tends to be whoever isn’t visibly overwhelmed. And whoever isn’t visibly overwhelmed is, more often than not, the person already carrying more than you realize. That’s how execution drag gets routed into the PMO’s portfolio. One “yes” at a time.
I don’t think this is a case for hauling everyone back to the office. (Busyness was always a crappy metric of capacity and effectiveness anyway.) I think it’s a case for being honest about what we can and can’t see from where we sit. If we can’t see who’s overloaded, we can’t make good decisions about who should run our most important projects. And we can’t conclude, from the absence of complaints, that anyone has room for a major assignment on top of the day job.
Can Training Turn SMEs Into Solid Project Managers?
Yes, for people who already have the time, the role, and the desire to be project managers. No, for people who don’t.
Training is usually the first lever organizations reach for when projects start to struggle. I understand why. It’s:
- Cheaper than hiring a dedicated PM
- Easier than building a business case for new headcount
- Easier than admitting to leadership that you’re understaffed
- More politically palatable than redistributing work
- A visible action (people can see you doing something)
All of those are rational reasons. None of them is the same thing as “this will fix the problem.”
You can train someone on every PM framework ever invented, and they still have the same 40 hours in a week they had yesterday. Most of those hours are already claimed by the day job. Adding “project manager” to a plate that was already full doesn’t create capacity; it moves the breaking point around.
There’s a selection problem, too. Training assumes the person being trained wants to be a project manager. Plenty of SMEs I meet in training rooms didn’t ask for that path. They’re there because their boss sent them, and the informal project leader role they’ve been playing for a year is starting to feel permanent.
So when does training help? When it’s paired with a real role change (not just another hat added to the existing one), realistic time allocation, and someone who wants the job. Absent those, training is a line item, not a solution.
PM Staffing is an Org Design Decision. Most Orgs Are Making It by Default.
Running enterprise projects with SMEs and functional leaders isn’t inherently bad. It is, however, always an organizational design decision. In the STAR model of execution systems I use with my clients, it touches almost all dimensions: Structure, People, Culture, Strategy, and Process.
Most orgs I work with didn’t choose this model on purpose. They drifted into it. Someone left and wasn’t backfilled. A project landed on a manager’s desk because they happened to know the system. A leader assumed the “business owner” would also run the work. Over time, those one-off decisions hardened into a pattern—and running projects with accidental PMs became “just how things work here.”
That’s the default mode. And the default mode is where the damage happens.
By default, orgs don’t have written criteria for when a project needs a dedicated PM. They don’t have a formal expectation of how much of an SME’s week should be project work. They don’t have an escalation path for when an accidental PM is in over their head. They don’t distinguish between projects contained within one department and projects that cross four. Work gets assigned based on who’s in the room and who’s willing to say yes.
By-design orgs look different. They’ve written down what kinds of projects get a dedicated PM (usually: enterprise-wide scope, multiple vendors, regulatory implications, or strategic weight above a certain threshold). They give SMEs a real-time allocation for the project work they take on. They fund training and pair it with mentoring. They define escalation paths. They treat this the same way they’d treat any other structural decision: documented, staffed, and measured.
Both kinds of orgs might be using SMEs on enterprise work. The difference is whether they’re running the model on purpose or by inertia. The orgs doing it on purpose make it work. The orgs doing it by inertia put their strategy execution at risk.
Dedicated PMs Don’t Require Full-Scale Org Redesign (Probably)
If you’ve read this far thinking this is going to require rewriting your org chart, stay with me. It almost never does.
In most of the orgs I work with, two or three concrete moves change the equation. You don’t need a new function. You don’t need to overhaul your staffing budget. You need to redirect existing people or buy a small amount of external help.
Here are the two moves I see work most often.
Option A: Take someone who’s already doing PM work and make it their job.
Take a department where three people are doing 25% project work and make one person 75-100% dedicated to project work.
Crucially, you don’t have to pick the person with the most subject matter expertise to be the PM. That’s not the PM job (or doesn’t have to be). If you do pick someone with high subject matter expertise to run projects, it’s a good opportunity to transfer knowledge to others (which usually should be happening anyway).
Pair the time reallocation with training and a 1:1 mentor who’s done this well before.
Measure those project outcomes against the ones being run by accidental PMs. Give it at least 6-9 months (depending on the length and complexity of the project, and the stage it was in when the dedicated PM took over).
This move is often cheaper than people think. Sending one person to a full PM training costs about $1,000. Sending a cohort of twenty untrained SMEs costs $15,000 or more, and most of them didn’t want to be there anyway.
Option B: Hire a contract PM for six months.
A short-term contract PM on your two highest-risk projects is a low-commitment experiment. No permanent headcount. No org restructuring. Less budget dance with finance. You’re buying a controlled comparison between how projects run with a real PM and how they run without one. At the end of six months, you have data instead of opinions about whether the model is worth scaling.
Either option lets you start small, measure, and then decide. You’re not redesigning the org. You’re running a pilot.
Will one of these pilots eventually force a structural conversation? Sometimes. If the pilot works well enough that leadership wants to scale it, you’ll need to decide whether PMs live within a PMO, within business units, or elsewhere. But that’s a better problem than the one you have today.
Do You Actually Need a Project Manager — or a Business Analyst?
Not every struggling project needs a PM. Some need a business analyst.
When I diagnose a project that’s in trouble, what looks like a project management problem is often a business analysis problem wearing a PM costume. Think about the requirements that were missed and the dependencies that were overlooked in the story I opened with.
Strictly speaking, a project manager doesn’t discover what the requirements are (though some people are excellent PM/BA hybrids). They coordinate the people who do. When requirements are missed, what usually fails isn’t coordination. What failed was elicitation, analysis, and validation—the work of a business analyst.
Business analysts and project managers are distinct disciplines with distinct roles. (I wrote about this in more depth a few months ago.)
A BA sits with stakeholders, maps current and future states, uncovers dependencies, and translates fuzzy business needs into specific, testable requirements. A PM takes those requirements and orchestrates the people, time, and money required to deliver them.
When orgs use SMEs to fill both roles at once, BA work is usually shortchanged. SMEs tend to assume they already know the requirements because they’ve been close to the work for years. That assumption is how you end up in a late-stage testing session, discovering a cross-departmental process gap nobody mapped during discovery.
So here’s a diagnostic worth running before you decide you need more PMs:
- Are your projects failing at coordination and delivery (missed deadlines, budget overruns, stakeholder miscommunication)? That’s a PM gap.
- Are they failing because the wrong thing got built, or the right thing got built without considering a critical dependency or stakeholder? That’s a BA gap.
- Are they failing at both? You need both. One person can sometimes do both jobs, but only on projects simple enough that the workload fits in one pair of hands.
If the diagnosis says “BA gap,” then adding PM training won’t help. You’ll train the wrong muscle. Worse, you might put a trained PM on a project that’s going sideways for reasons they can’t fix.
If You Only Do One Thing
Pick one project on your portfolio that’s high-risk, high-visibility, and currently being managed by someone who’s also doing another job. Put a real, dedicated project manager on it.
One person. Their job, for the duration of the project, is to run it. A co-lead arrangement or a part-time assignment won’t give you what you need. If you must, put them at 75%…but no less.
You can contract for them. You can borrow them from another part of the organization. You can promote someone internally who’s been 25% doing this work anyway. However you source them, make sure the person wants the job.
Then measure. Track the same things you’d track on any project (schedule, budget, scope, quality), but also track the softer signals. How many fewer escalations land on executive desks? How much less rework does the team do? How often does the SME who would have been running this project now have time to do the work they were hired to do?
Six months from now, you’ll have something better than opinions. You’ll have data about what a dedicated PM is worth in your organization. Then you can decide, with evidence instead of ideology, how much of your portfolio deserves the same treatment.