Shape Up - Basecamp
4 Project Management Lessons to Take From Basecamp’s Shape Up
Shape Up - Basecamp

4 Project Management Lessons to Take From Basecamp’s Shape Up

For 15 years, Basecamp has been a stand-out example of how much you can achieve with a small team. They’ve built one of the top project management tools and have continuously shipped upgrades and features, all with under 50 employees. And now we finally know how they do it.  

It’s not by using Agile, or scrum, or waterfall and it’s not by outsourcing work to contractors or anything like that. It’s through a framework that they built and honed over time. This framework, called Shape Up, contains a few important lessons about project management that can be applied to most businesses and industries.

What Basecamp’s Shape Up teaches us about project management

1. Spend more time planning projects before starting them

Basecamp’s model for project management is split into two tracks: shaping and building. While most of the team is working on building a new feature, others (or sometimes one empowered generalist) are shaping what the next project might be. According to Basecamp, shaping “defines what the feature does, how it works, and where it fits into existing flows.” It also answers typical questions about the problem you’re trying to solve, the target audience, and more.

They emphasize that shaping is largely design work, essentially “sketching” out the project you have in mind. That said, your sketches can’t be too concrete — experts need the freedom to design a solution without being impeded by some wireframe you thought up. They just need to go far enough to delineate:

It’s only after this shaping has been done that the Basecamp team writes a “pitch” for the project to even be considered for actual execution. 

The risks of not enough planning

Basecamp’s system is a great method for avoiding one of the critical errors people make when managing projects: rushing through the planning phase. Ask yourself how much time you spend planning a project versus executing it. Is it 5% planning, 95% executing? Maybe 90% planning and 10% executing on a good day? This kind of split will usually lead to a few common issues down the road:

  • Projects going outside the initial scope
  • Unforeseen issues slowing down the process
  • Increased rounds of review and editing in later stages of the execution
  • A project in which the time and effort required to complete it far exceeded the actual business benefits  

Spend more time planning — or shaping — your projects before you ever start working on them. You should have a sketch of your project, with requirements, boundaries, and risks, before you even decide whether or not to actually do it. Your bosses may balk at time spent examining a project you don’t end up pursuing, but this will save your team a ton of time and money down the line. 

Bonus tip: if you embrace this notion full-on, it will also stop you from rushing to address customer feedback. If you launch a new project and get a ton of feedback from clients that you should change this and that, your instinct might be to quickly make these updates to keep people happy. Treat this feedback like any idea: it needs to be shaped. If you think it could be worthwhile, break down the idea’s boundaries, essential elements, and risks before you even consider making the change.  

2. Put trust in those executing the work

When shaping projects, Basecamp highlights that you don’t want to be too prescriptive, so your experts are empowered to seek out the best course of actual. This type of team empowerment is a theme of the entire framework. In fact, an entire section of Basecamp’s ebook is dedicated to handing over responsibility. What do they mean by this? They mean allowing those who will be executing on the project to take charge of how it unfolds. 

In the Basecamp model, people who have been chosen to work on a project are assigned the entire project, not individual tasks. They liken assigning tasks to “putting the pitch through a paper shredder. Everybody just gets disconnected pieces.” Instead, their team members are encouraged to take a few days to get acquainted with the project (and, in the case of developers, with the existing system or code). They familiarize themselves, and really consider what will need to be done in order to achieve the deliverable. 

They call this stage “getting oriented” and emphasize that managers need to respect this phase of the project. Asking them for progress updates in the first day or two will just hurt the project by stripping away this initial discovery phase. 

After getting oriented, the Basecamp team begins to create tasks for the project. They highlight the difference between imagined and discovered tasks: basically the tasks you think you’re going to need and the tasks you only realize you need to complete as you begin working on the problem. The latter group of tasks often only appear way later in the game if you start a project by assigning all the work between group members. 

Avoid micromanagement

By handing over responsibility in all of these ways, Basecamp avoids another common project management hiccup: confusing project management with micromanagement. You’re there to empower your team, support them in their efforts to execute on a deliverable. By being too prescriptive with the work in advance, you’re really creating a situation in which the experts on your team have to be reactive instead of proactive. They’re first reacting to the tasks they’ve been assigned; then they need to reactive to the variety of tasks that you didn’t anticipate which inevitably emerge further into your build. 

Trust your team enough to let them outline their own role in each project. The worst case is that you need to add tasks that they’ve missed. The best case is that they enter the project having already thought deeply about each required element and phase, and are better prepared to take on whatever comes their way.

3. Set finite time cycles, but allow for full focus

Estimating a project timeline is one of the most difficult parts of project management. Trying to account for all of the different factors and risks which could slow progress is often an exercise in guesswork. It usually leads to timeline adjustments as the project progresses, which has an unfortunate ripple effect on teams throughout the business

Basecamp avoids this issue by setting a six-week time cycle for all projects. Period. No exceptions. They settled on six weeks as they felt it was a long enough cycle to complete a project from start to finish, but short enough for people to still feel the pressure. What happens if a project isn’t finished after six weeks? They end it there, and go back to the pitching phase, essentially forcing the entire group to decide whether it’s worth investing in that project for another cycle. That might seem harsh, but it’s a clear cut way to avoid dragging deadlines and overinvesting in projects that are too difficult or won’t bring enough benefit. In Shape Up, they put it like this: “If we bet six weeks on something, the most we can lose is six weeks. We don’t allow ourselves to get into a situation where we’re spending multiples of the original estimate for something that isn’t worth that price.”

No distractions, no interruptions

Now, if you’re going to set this kind of finite time cycle, you can’t start pulling team members off of the project for other work. In this framework, that team should be fully dedicated to a single project for six weeks — no distractions. If you’re not willing to dedicate those resources for that amount of uninterrupted time, you might want to reconsider whether the project is really worth it to begin with.

We’ve all been in a place where we have two or three projects on the go simultaneously. As you work to juggle deadlines and priorities, something inevitably suffers. By setting finite time cycles, but having teams fully focused during those periods, you avoid distractions while preventing projects from dragging on aimlessly. 

We mentioned at the start of this post that Basecamp doesn’t use Agile or scrum or waterfall. 

The entire Shape Up framework was built by Basecamp because they felt it was the right system for their team. It was iterated on and honed over time. Even though they created this ebook to share their own framework with the rest of us, they state explicitly that “The Shape Up method presented in this book is tightly interwoven. It may take some thought and experimentation to pull out the right pieces and adapt them to your team.” 

That idea — adapting project management methods to your team — is something that far too many businesses ignore. More often than not, people hear or read stories about how X business used X system to build their incredible product, and they jump all over it. Occasionally, they’ll even drop existing methods off a cliff when they discover the new big thing. This is not the right way to approach project management.

Make the method your own

Even if you do use Agile or scrum, you should be treating these as guidelines that you then mold to your own situation. They aren’t laws, to be followed or broken; they’re examples of what worked for one group that you can then take inspiration from. For example, our CTO at Unito Eryk Warren shared how we’ve adapted the Agile framework to fit our team size, culture, and general approach to development. 

If you read Shape Up and think their method would be a fit for your team, start integrating specific elements into your existing system. Test out what works and what doesn’t. Get feedback from your team. Do post-mortems. Work at it until you settle into something that feels natural for your team and keeps your colleagues happy and productive. 

We’d like to thank Basecamp for sharing their incredible framework. You can find the full eBook here: https://basecamp.com/shapeup