Modern Project Management: What you need to know & how to make it work

It can be difficult managing a team. If you do it badly, you can confuse your team, shatter morale, miss deadlines, and possibly worst of all: be responsible for leading a disappointing project.

But fear not! We’ve laid out all the modern project management techniques and concepts, along with ways to execute them (and additional reading for each one), so that you can lead your team more efficiently.

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

If you’re a traditionally trained 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 have yet somehow found yourself in the role of project manager (even if that’s not your official title!), having a handle on these basics can help:

Waterfall Methodology

Waterfall has been mostly out of fashion (especially in the software engineering world) 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 originally 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 (since we’re never taught anything different, unless we go out of our way to learn it), but a lot of its detractors argue that it’s inefficient, especially compared to other styles.

Read more about Waterfall: The IT Project Manager: How To Manage Waterfall Projects

Scrum Methodology

Scrum has its origins in the late 80s/early 90s. Scrum 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 mind 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.

Read more about Scrum: The Scrum Guide

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 essentially 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 because it’s fairly 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 in 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

Read more about Lean and how it applies as a project management concept: Lean and Agile Project Management: How to Make Any Project Better, Faster, and More Cost Effective

How to figure out what works for your team

Some teams work with one specific project management style basically 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 own 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

(This is one reason that many of our users love Shortcut — unlike a lot of other project management tools, it isn’t opinionated. You can work within a specific project management style, or set it up to work with the custom workflows that you and your team have developed over time.)

One major aspect that affects how teams evolve their project management style is team size. A small start up with a team of 10 employees is likely going to work differently than a 50-person team that is spread out amongst multiple locations.

For example, daily stand-ups are often too much for a lot of larger teams, so they might 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.

Read more about how project management evolves based on team size: Project Management Evolution: Startups vs. Enterprises

<!-- Code for CTA component starts here-->

<div class="post_body_cta"><div class="post_body_cta-heading">
Build what’s next
</div><div class="post_body_cta-text">
Experience the most lightweight, enjoyable way for your team to work.
</div><div class="common_buttons_wrap"><a href="/signup" class="button primary text-color-white w-button">Get Started - free forever</a>
<a href="https://api.app.shortcut.com/oauth/signup" class="button is-google w-button">Sign up with Google</a></div></div>

<!-- Code for CTA component ends here-->

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

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 really 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 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 Shortcut, our project management methods have evolved over time as our needs have changed. At one point, we didn’t do daily standups — after employee number six, they were added.

We also have a bi-weekly priorities meeting where we check in on high-level goals (our Epics) that we set in the Milestones for the quarter. Those meetings were also added after we had a team of 6–7 employees and some of the team went remote.

When it comes to responsibilities, our team members are in charge of their own Epics. They don’t have to do all the work, but it is their job to herd their own cats to whatever degree they need herding.

All that said, we’re still fairly light-touch, because we’re such a small team and we all communicate so regularly. An overwrought system wouldn’t work well for us — it’d just weigh us down.

Our goal is to keep responsibility in our individual team member’s hands, instead of being held in the hands of one specific member or manager.

We’re a small, cross-functional team, with constantly overlapping work  —  a change in any 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.

What works for your team? What doesn’t?

We’d love to hear more about the project management styles you’re using  - let us know on Twitter!