Setting Up Your Project for Success: Traditional, Agile, or Something in Between?

Every project manager eventually hits the same fork in the road: do you run this project the traditional way, go full agile, or build something in between? Get this decision wrong at the start, and you’ll spend the rest of the project fighting your own process instead of delivering the work.

There’s no one-size-fits-all answer. How you set up a project depends on the project itself — its scope, its team, its stakeholders, and how much things are likely to change along the way. The good news is that you don’t have to guess. A handful of questions about the classic “iron triangle” of scope, schedule, and budget will point you in the right direction.

Start With These Questions

Before you pick a methodology, get honest answers to the following:

• Scope — Is it fixed, or is it likely to shift? Are the requirements fully fleshed out, or still taking shape?
• Size — How big is this project, in terms of stakeholders and schedule?
• People — What roles do your main stakeholders play? How stable are your resources — do you have a dedicated team, or are people splitting time across projects?
• Cushion — Do you have a contingency fund if things go sideways?

Your answers here are the real inputs to the next decision: traditional (waterfall) or agile.

Traditional (Waterfall): When Things Need to Stay in Stone

Waterfall — sometimes called the predictive or traditional method — is linear by design. One phase finishes before the next begins, full stop. The five phases, as PMBOK lays them out, are Initiation, Planning, Execution, Monitoring & Controlling, and Project Close. Anyone pursuing a PMP will spend a lot of time learning exactly what happens inside each one.

If you choose this path, planning is where you earn or lose the project. In my experience, three artifacts make or break everything downstream: requirements, schedule, and budget. You cannot execute well without a firm grip on what your team is building, and when they’re building it — and schedule and budget are joined at the hip. Every hour of work is money spent, whether that shows up as time, materials, or salaries. Treat planning as an afterthought, and you’ll pay for it in every phase that follows.

Agile: When You Need Room to Move

Maybe you looked at waterfall and liked most of it — but some part of your project needs more flexibility than a strict linear process allows. That’s the case for a hybrid, agile-influenced approach. Some project managers just loosen a few constraints on the traditional model. Others blend several agile frameworks together. Both are legitimate, and the right mix depends on your project.

Here’s a quick tour of the major agile approaches, and what’s distinctive about each:

Methodology	What It’s About	Certifying Bodies
Scrum	Structures the whole process around teamwork — how the team works, learns, fails, and succeeds together. Named after the rugby scrum.	Scrum Alliance (CSM), Scrum.org (PSM I/II/III), PMI (PMI-ACP)
Kanban	A visual board (“kanban” is Japanese for signboard) for proactively managing the flow of work from inception to delivery.	Kanban University, Scrum.org (Professional Scrum with Kanban), ProKanban.org, Kanbanstudy
Extreme Programming (XP)	An engineering-practices-first framework for software development.	XP Alliance, NICCS (Certified XP Professional)
Crystal	Puts the people on the team — and how they interact — ahead of tools and process.	No dedicated body; covered under broader PMI and ICAgile credentials
Feature-Driven Development (FDD)	Built for complex, long-term projects; breaks feature sets into manageable, iterative releases.	No major standalone certifying body
DSDM	Focuses on the full project lifecycle; created in 1994 by the DSDM Consortium in the UK.	Agile Business Consortium
Adaptive Project Framework (APF)	Built around adapting to changing requirements and giving clients systematic control over project details. Pioneered by Robert K. Wysocki.	No standalone body; taught within broader agile curricula

I’ve built plenty of agile projects by borrowing pieces from several of these at once — most often pulling elements of XP and FDD into IT projects, since my PMI-ACP training covered them in depth and some of their practices just make sense in that context.

One warning, though: agile is not an excuse to skip planning. I’ve seen projects go sideways because the team assumed “we’re not doing waterfall” meant “we don’t need a plan.” That’s backwards. A hybrid agile approach still needs a solid plan — it just needs to build in room for change.

Building Your Own Hybrid

The best way to design a hybrid approach is to actually know what’s out there. Don’t stop at Scrum just because it’s the most popular — spend time with the lesser-known frameworks too. Somewhere in Kanban’s visual flow, or DSDM’s lifecycle focus, or APF’s adaptive client control, you’ll likely find a piece that fits your project better than anything in the “standard” playbook.

Do that homework, plan diligently, and you’ll end up with a hybrid project plan that’s actually built for the project in front of you — not just borrowed wholesale from a textbook.