Project Management · 2026-05-09
Types of Projects in Project Management: Deliverable-Based vs Results-Based
There are two types of projects in project management — and most PMs never stop to ask which one they're running. Here's the distinction between deliverable-based and results-based projects, why confusing them is how good PMs end up delivering the wrong thing, and the one question that cuts through it all.
Have you ever been in a project where everything was going well — milestones hit, team delivering, stakeholders updated — and yet something felt off?
Not about the work. The work was fine. But that nagging feeling kept coming: when we finish, the applause won't come. The sponsor won't be thrilled.
I've been there. Most experienced PMs have. And for a long time, I couldn't fully explain why it happened. The project was delivered. What else were they expecting?
It turns out — everything.
Let me lift the curtain on something that doesn't get enough attention: there are two fundamentally different types of projects in project management, and they require completely different approaches.
Type 1: Deliverable-Based Projects
This one feels honest. Clean, even.
You know what you're building, you build it, and when it's done — it's done. A new office building. A road. An ERP system rollout. A product launch event. The finish line is tangible and visible. Binary, really: either the thing exists, or it doesn't.
The PM's world here is familiar and navigable. You manage scope, budget, and timeline. You track milestones. You run status meetings. You solve blockers. You push toward a final acceptance — a sign-off, a certificate, a go-live.
The questions that drive your week are: Are we on track? Is the quality right? Is scope creeping? Will we make the deadline?
The risks mostly live inside the project. A delayed supplier, a technical blocker, a scope change — these are things a good PM team can handle.
There is a certain confidence to this type of project. When it's going well, you feel it. The team is delivering, the plan is holding, and the finish line is getting closer. It just feels right.
Type 2: Results-Based Projects
This one is different. Fundamentally different.
You're not promising a thing. You're promising a change. A business outcome. A shift in reality that goes well beyond what your team physically produces.
Customer satisfaction improvements. Market growth. Innovation. Process efficiency. Cultural transformation. These are results that depend not only on what your team does — but on how the organization absorbs it, how the market reacts, how people change their behavior.
The PM's world gets considerably messier. The finish line isn't a sign-off — it's a number on a dashboard, six months from now. The risks live in market conditions, in human behavior, in organizational culture, in decisions made by people not even on your team.
The questions sound different too: Are we solving the right problem? Will people actually change how they work? Are we measuring the right things? Does what we're building connect to what success actually looks like?
And there's a different kind of pressure. Everything can look green on your project plan — and yet that nagging feeling shows up. Because you know: your deliverable is just an input. What happens after is what they're really watching.
The Examples Say It All
Here's a quick look at how the same project can carry both expectations at once:
ERP rollout: PM delivers → system live, data migrated, users trained. Business expects → lower operational costs, faster reporting, fewer errors. New office building: PM delivers → building complete, within spec and budget. Business expects → improved team collaboration, talent attraction, reduced turnover. Customer service redesign: PM delivers → new process documented, team retrained, tools deployed. Business expects → CSAT score improvement, faster resolution times, fewer escalations.
See the pattern? The left side is what the PM team builds. The right side is what the business expects. These are not always the same thing — and the gap between them is where projects go wrong.
The Story I Wish I Had Been Told Earlier
After a company acquisition, I was leading part of a larger integration effort. One workstream was to roll out the ERP system of the mother company to the newly acquired one — a full migration across data, processes, and teams.
Classic deliverable-based project, I thought. And it was. We worked hard and we delivered. System went live. It was celebrated.
A few months later, the complaints started arriving. Operations managers were unhappy. Senior management was asking uncomfortable questions. Expected efficiency improvements were not materializing.
Here's the honest truth: nobody explicitly said the project was responsible for the efficiency gains. The scope was the rollout. We rolled it out.
But the business expectation — what the seniors actually cared about — was never about the ERP. It was about what the ERP was supposed to unlock: better operations, lower costs, smarter processes. We delivered the vehicle. They were waiting for the destination.
The Mismatch — and Where PMs Fall Into the Trap
This is the gap that catches good project managers off guard. The project is scoped around the tangible deliverable. But the sponsor's expectations — spoken or unspoken — live entirely at the outcome level. By the time the mismatch surfaces, the project is over.
Here's what's important to understand: the outcome and the goal of a project come from business strategy and from decision-makers — not from the PM. You don't invent success criteria. They do.
But you are responsible for making them visible, explicit, and agreed upon. Even when the seniors haven't fully articulated them. Even when nobody asks you to. Especially then.
Because if you don't do it, you will find yourself in my ERP situation. Delivering exactly what was asked, while the organization expected something else entirely.
The Best Question You Can Ask
"What does success look like to you?"
Not "what should we deliver." Not "what's the deadline." What does success look like — to you, to the business, to the people who will judge this when it's done?
The answer tells you everything.
If they say: "A fully built, certified building delivered by Q4" — you're in deliverable territory. You know your finish line.
If they say: "Well... we need the acquisition to generate 20% efficiency gains within 18 months" — stop. That's an outcome expectation dressed up as a project. And now you have a much more important conversation to have, before a single task is assigned.
This isn't about avoiding accountability. It's about creating the right kind — one that's honest about what the project can directly control, and what depends on the broader business context around it.
Tips from Practice
1. Know which type of project you're in. It shapes everything — how you plan, how you communicate, how you measure progress, and how you manage your sponsor.
2. Figure it out at the very start. The later this conversation happens, the more expensive the misalignment becomes.
3. Ask "What does success look like?" — and push until you get a real answer. Vague answers are a warning sign. That's where hidden outcome expectations live.
4. Set the right success metrics together with your stakeholders. Not just project metrics (on time, on budget, on scope) — but business metrics too, where relevant. Make them explicit. Write them down.
5. Get buy-in on the project setup, not just the plan. Everyone should agree on what the project is — and is not — accountable for. That conversation protects everyone.
In reality, many projects carry both types at once. A construction project is clean deliverable-based work — until the sponsor mentions 30% ROI in five years. An ERP rollout is a go-live — until it's also expected to transform operations. Knowing which type you're dealing with — and making that explicit — is one of the most important things a PM can do before a single task is assigned.