There’s no denying that it is difficult to manage a team; one small misstep can confuse a team, shatter morale, and leave you responsible for a disappointing project.

To help you avoid any mishaps, I’ve done a bit of research on modern project management techniques and concepts — along with ways to execute them so that you can lead your team more efficiently.

Here’s a crash-course in modern project management concepts

If you’re an experienced project manager, none of this will come as a surprise to you. But if you don’t necessarily have a formal background in PM work, and are currently looking to learn different approaches read on:

Waterfall Methodology

Waterfall has been mostly out of fashion for a while now, but many of these other systems were developed as a response to it, so we’ll cover it first. It was adapted to software development from the manufacturing world, and it’s sequential — not cyclical or iterative.

That means you plan the entire project out at the start of the project, and then go down the plan step by step, checking everything off.

Most of us instinctively plan in a Waterfall style, but a lot of its detractors argue that it’s inefficient, especially compared to other methods.

Scrum Methodology

Scrum has its origins in the late 80s/early 90s; it uses incremental, iterative cycles, instead of planning the whole project out at the start.

Scrum also has pre-defined team roles (product owner, development team, and scrum master).

This method acknowledges that customers/clients often change their minds about what they want in ways that can’t be addressed in traditional methods (like Waterfall), and focuses on maximizing the team’s ability to ship products and respond to new requirements as they emerge.

Scrum emphasizes working in sprints of 30 days and also has a heavy focus on daily meetings (standups or daily scrums) while a sprint is ongoing. There are also structured reviews and retrospectives as a part of the process.

Agile Methodology

Agile draws on older methods and ideas going back as far as the 1970s but became much more popular when 17 software developers came together to write and release the Agile Manifesto circa 2001.

Like a few of these terms, it’s often used as an umbrella term for a set of process, product, and project management techniques.

The idea behind Agile is (mostly) that you complete small portions of the project/product (vs. a full version of the project/product) in each cycle, and modify the overall project course based on customer/client feedback as you complete cycles.

Getting this feedback as you’re developing the product lets you create something that meets current customer needs, with minimal cost/waste/time spent. Part of the reason Agile has become so popular is that it’s relatively easy to modify for your specific team’s wants/needs.

Read more about Agile: Agile Project Management for Dummies Cheat Sheet

Lean Project Management

Lean isn’t really a “true” project management method in the way many of these other concepts are, but it has had a lot of influence in product development, so it’s worth touching on.

Like several of these ideas, Lean started in the product development and manufacturing world, created by Taiichi Ohno at Toyota.

You’ve probably heard of the Lean Startup, which codifies a lot of the product development aspects of Lean into a set of business processes and adapts them for the startup world. The fundamental idea behind Lean is more value with less waste — getting rid of the waste in your business processes. Other Lean philosophies include:

• Anything worth doing is worth doing fast and right
• Avoiding rework by clarifying objectives and goals (and doing it right the first time, as already referenced)
• Using iterative cycles, as several of the other project management methods do
• Eliminate bottlenecks in the work and the process
• The last planner principle, which means that you plan in greater detail as you get closer to actually doing the work (instead of planning everything at the start of the project), and create those plans with the people who will actually do the work

Some teams work with one specific project management style straight “out of the box,” without feeling the need for modification. Other teams take a system and modify it until it meets their needs (or take the big-picture pieces from 2–3 different project management concepts and then work them together into their system).

Typically, the pieces being modified are:

• Sprint length
• Length & frequency of meetings
• What’s being completed in that sprint / how much feedback you’re getting on it

For example, daily standups are often too much for a lot of teams, so they switch it to weekly. Another option is to do a meeting on Monday to discuss what’s on deck for the week and give your team a chance to ask any questions they have, then a recap on Friday to discuss what got done, what didn’t, and why.

Generally, it’s good to test for about 1–3 months to see if something will stick.

It’s especially helpful to create (with your team’s input, of course!) a list of problems that you’re attempting to solve by trying out a new project management method. That list will give you a metric as to whether your test was a success or not.

Even after you’ve found something that works well for your team, it’s still a good idea to do quarterly check-ins and make sure your system is still working as intended. Signs that your project management system needs to be shaken up to include:

• Tasks or projects are consistently falling through the cracks
• Meetings aren’t as productive as they used to be
• People are unsure of what they’re supposed to be working on, in what order, when, or why

At one of the startups I worked at, the project management methods evolved over time.

If you’re a part of a small team, it’s your job to make sure you find a process that works, a lot of work will overlap and one department can have effects that ripple across to other departments — because of that, conversations need to happen out in the open instead of just using one person as the go-between, and our project management methods are designed to reflect that.

‍