Top 5 Project Management Methodologies: Lessons from My Experience

Project management is one of those things you only really figure out by doing. Over the years, I’ve had my fair share of wins—and a few frustrations—while trying to find the best way to manage projects. Whether you’re building software, implementing ERP systems, or tackling creative projects, you’ll find yourself asking: What’s the best methodology for this?

The truth? There isn’t one. Each methodology has its strengths, but none is perfect. Your choice often depends on the situation, your team, and the nature of the project. I’ve worked with several of these approaches, and while they all sound great in theory, they each come with their own quirks. Here’s my take on the top 5 project management methodologies – when they’ve worked for me, when they haven’t, and why no single method can claim the top spot.

1. Agile

Agile is like the go-to tool for software development…at least some people say that. I’ve used it for smaller projects where the requirements weren’t fully defined, and we knew things would change along the way. Agile thrives in this kind of chaos. It’s all about short iterations, constant feedback, and adapting quickly.

When It Worked for Me:
I once led a team that was developing integration with WMS tool. The client kept tweaking their requirements (classic). Agile helped us stay sane. By breaking the work into sprints, we could deliver small features, get feedback, and adjust before moving forward.

When It Didn’t:
There was another project (retail software implementation) where everything needed to be planned upfront. Agile turned into a nightmare because every “adjustment” threw the timeline into chaos.

What I Love About It:

• It’s flexible. If something changes, you can pivot.
• The focus on collaboration means fewer surprises.
• It’s great for catching issues early.

The Downside:

• It can feel disorganized if your team isn’t disciplined.
• Budget and timelines? Good luck predicting those.

2. Scrum

Scrum is Agile’s structured sibling. It’s still iterative but adds roles (like the Scrum Master) and rituals (like sprint planning and stand-ups). I’ve found it helpful when working with teams that thrive on rhythm and clear goals.

When It Worked for Me:
Scrum saved a project where the team needed more structure but still wanted the flexibility of Agile. The two-week sprints gave us clear deadlines, and daily stand-ups kept everyone aligned.

When It Didn’t:
Not every team loves structure. On one project, the rigid rituals (like sprint retrospectives) felt like a chore and killed morale.

What I Love About It:

• The sprint cycle keeps things moving.
• Defined roles mean everyone knows their job.

The Downside:

• If you don’t have a dedicated Scrum Master or Product Owner, the system collapses.
• It’s not great for very large teams or projects.

3. Waterfall

Ah, Waterfall—the classic, linear approach…and my favorite, especially when you are implementing large scale systems like ERP. This was the first methodology I ever used. It’s all about planning everything upfront and sticking to the plan. If Agile is jazz, Waterfall is classical music: structured, predictable, and a little rigid.

When It Worked for Me:
Waterfall was perfect for all the ERP implementations I worked on. The requirements were locked in from day one, and we could map out every step. No surprises, no deviations.

When It Didn’t:
For a software development project with shifting priorities? Total disaster. By the time we got to testing, half the requirements had changed.

What I Love About It:

• You know exactly where you’re going (if nothing changes).
• Budget and timelines are easier to estimate.

The Downside:

• Inflexibility. Once you’re in, you’re in.
• Discovering issues late is a killer.

4. DevOps

DevOps isn’t just a methodology—it’s a culture. I came across it while working on continuous delivery projects. It’s about breaking down silos between development and operations teams and automating as much as possible.

When It Worked for Me:
We used DevOps to build a CI/CD pipeline for a client’s e-commerce platform. The speed at which we could deploy changes (without breaking things) was incredible.

When It Didn’t:
It’s not something you can half-implement. One client wanted “a bit of DevOps,” but without proper infrastructure or team training, it became more work than it was worth.

What I Love About It:

• The automation saves so much time.
• Teams collaborate better when everyone’s aligned.

The Downside:

• It’s a beast to implement.
• The constant pace can burn teams out…and this is something you really want to avoid.

5. Kanban

Kanban is the simplest methodology I’ve used, and honestly, it’s a lifesaver for ongoing tasks or support teams. It’s all about visualizing work and limiting what’s in progress to avoid bottlenecks.

When It Worked for Me:
I used Kanban to manage a support team’s workload. We set up a board to track tasks, and suddenly, everyone knew exactly what needed to be done and when.

When It Didn’t:
Kanban wasn’t a great fit for a project with strict deadlines. Without defined timeframes, tasks dragged on longer than expected.

What I Love About It:

• It’s simple and visual.
• Perfect for managing continuous workflows.

The Downside:

• No structure means tasks can linger forever.
• Without limits, it’s easy to overload the team.

What I’ve Learned About Top 5 Project Management Methodologies

If there’s one thing I’ve taken away from working with these methodologies, it’s that context is everything. There’s no one-size-fits-all solution. Agile might work wonders for a fast-paced tech project, but it can’t handle the rigidity of a compliance audit. Waterfall is great when everything’s clear from the start, but in a dynamic environment, it’ll sink you.

At the end of the day, the best methodology is the one that adapts to your project—not the other way around. Sometimes, the magic lies in combining elements from different approaches to create something that fits your team and your project.

So, what’s your experience with these methodologies? Have you found the “perfect” one, or learned to embrace imperfection like I have? Let me know in the comments!

If you want to learn more about project management, I recommend that you read Project Management Absolute Beginner’s Guide by Greg Horine. Also, make sure you read one of my previous posts on How Many IT Projects Fail.