tcan 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 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.
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.
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.
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
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
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 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 Clubhouse, 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.