Manage Your Basecamp Projects Like 37signals
Note: This piece was written when 37Signals was the parent company responsible for creating Basecamp. As of February 2014, 37Signals is now just known as Basecamp.
If anyone knows project management, it’s 37signals.
The web-app firm behind Basecamp (a tool that’s been used to manage over 8 million projects), 37signals is renowned for its customer-centric collaboration software. Its company blog, Signal vs. Noise, draws 75,000 readers daily, and Co-Founder Jason Fried is a leader in not only the industry, but business in general. His manifesto “Rework”—penned with Co-Founder David Heinemeier Hansson—is a New York Times bestseller, and espouses the company’s philosophy: speed and simplicity is the key to success.
Naturally, this philosophy is reflected in 37signals’ approach to project management. Product Manager Ryan Singer has been with the company since the beginning, and is co-designer (along with Fried) of the original version of Basecamp itself. So I caught up with Singer to find out how they manage their projects—and I learned some surprising things.
In this article, you’ll find out:
Why organizing your Basecamp projects by role is all wrong;
Why defining all your to-dos up front is a waste of time;
Why you shouldn’t use Basecamp to plan; and,
Why 37signals doesn’t manage deadlines.
You’ll also learn the importance of creating a “kill list,” and what it means to make “chowder” for a project. In short: if you use Basecamp, you’ll want to read this.
Here’s how to manage your Basecamp projects like 37signals:
Identify Key Areas of Customer Concern
When you get a new project, all the tasks that are involved can seem overwhelming. At 37signals, they start by breaking a project up into a few key areas of customer concern. Say, for example, they’re working on a conference registration app. First, they break that up into the independent items that need to be worked on in order to deliver a finished product to the customer: e.g., the registration form, payment processing and a check-in feature. Then, the team tackles these areas one at a time, in order of what’s most important and what’s going to inform the rest of the project.
Singer represents this process as a map of sorts, with the key “territories,” or areas of concern, demarcated:
CONFERENCE REGISTRATION APP
Like many companies, 37signals does custom, integrated work on every new project they start; they don’t follow a specific, step-by-step methodology. But what’s unique about 37signals’ projects—and agile software development in general—is the ability to work in an iterative way. They create a mockup; implement a prototype that can be clicked on and used; see what’s working and what’s not; revise it; add more; revise that; and so on. Whether you follow a clear methodology or an iterative process, identifying the key areas of customer concern will help you focus your efforts, Singer says, and move the project towards completion step-by-step.
Divide Your Basecamp by Projects, Not Roles
Some companies divide their Basecamp projects by workplace role, with separate to-do lists for, say, Design, Programming and QA. Each item on the list is a task that department is responsible for. Going back to our example, within the “Conference Registration App” project in Basecamp, they might set up their to-do lists as follows:
However, Singer notes that if you’re managing projects this way, you’re not using Basecamp to its full potential.
At 37signals, they divide their work by project, not role. They create to-do lists that represent areas of customer concern and that incorporate everybody’s to-dos. So, instead of the “Design” to-do list, with “registration form” as a task, they have the “Registration form” to-do list—which integrates the Design, Programming and QA tasks. Here’s what the reconfigured to-dos would look like:
“The overarching purpose for this is that, as a manager, I want to be able to get a “state of the world,’” Singer explains. “I want to be able to look at one place and see what’s done and what’s outstanding, and see actual units of progress that mean something to the customer. I need that in order to plan, estimate and know where we stand on projects.”
If every project is being housed in the same place in Basecamp, it can be hard to make heads or tails of all the information. But if you have a dedicated Basecamp project that corresponds with the project you’re working on, you can see exactly when there is only one to-do left for that project. The “Catch Up” feature comes in particularly handy here: you can get a snapshot of everything was completed for the project on a given day, without having to toggle between the projects for different roles. And when it’s done, the whole project goes away—as opposed to having, say, a Design project that never ends, but just adds and subtracts to-do lists as customer projects come and go.
Define To-Dos One Area at a Time
Instead of trying to define all of the necessary to-dos for a project in the beginning, Singer says, he picks out one area of concern that is the most valuable, and defines to-dos for that area only. He then ranks the other areas of concern in order of importance, and works through them in this same fashion one by one. To go back to the registration app example, say the registration form is identified as the most important area: break that out into specific to-dos, but don’t worry about trying to define to-dos for other areas of the project.
The to-dos for the primary area of importance are listed in Basecamp—but Singer notes that they use Basecamp as a communication tool, not a tracking tool. To-do lists serve to communicate to team members what they need to get done, not as a way to keep tabs on their progress.
Going back to Singer’s illustration, here’s the “areas of concern map” for the registration app, with darker colors being more important:
These rankings, Singer says, are a question of how far ahead he can see to the end goal (in this case, having a functioning piece of software). Maintaining a big-picture view is important for the project leader, but focus is the number-one priority for the team. Singer ensures that his teams works through the area they’ve currently identified as most important before moving on to something else.
Use Basecamp to Communicate, Not to Plan
Many project management software programs include such traditional features as Gantt Charts. Basecamp doesn’t—and that’s intentional.
“Gantt Charts are a tool people use for planning,” Singer says. “We don’t use Basecamp to plan, we use it to communicate. That’s a deep difference in approach.”
Instead of creating a detailed plan with dependencies and phases and tracking how the team implements that plan, Singer lays out the state of the world for a project—and then lets the design and development process unfold. The state of the world—the key areas of concern and the to-do list for the area at hand—provides a common reference point that the team can see the status of and communicate on. But they are learning along the way, adding and completing to-dos as they come and re-prioritizing areas of concern when necessary. This, says Singer, allows them to see exactly where they stand at the end of each day.
Instead of using Basecamp to manage plans, 37signals uses it to have discussions about particular to-dos, share files and images and communicate new or completed to-dos to the rest of the team.
Manage Scope, Not Task Due Dates
Basecamp has a “Dates” feature that allows you to assign deadlines to specific to-dos. But 37signals doesn’t use it.
“Basically, we don’t work that way,” Singer says. “We have an overall budget for a project: it could be three weeks or three months. We know the things we need to do, and we’re very careful to avoid doing things that are unnecessary. I would rather control the scope of a project than control the amount of time people spend on specific things.”
In other words, they manage project scope, not task due dates. So how do they ensure they hit deadlines without setting due dates? On major projects, Singer reports, the team will reach a point near the end where they must assess whether or not they’ll be able to finish in time. To determine this, they do an audit of all outstanding to-dos and attach hourly estimates to them. They break up anything that’s too big, physically write the estimates into the to-dos and multiply them by 1.5, to have total confidence in the figures. This clearly shows the team what they can manage and what they can’t in the amount of time they have. They can cut what isn’t absolutely necessary and, occasionally, shift milestones.
In fact, Singer describes how in the original version of Basecamp, the only date-specific feature was “Milestones,” meaning high-level dates along the life of a project. An average project for 37signals might have four or five, including project kickoff and completion. By managing tasks around these major milestones, instead of focusing on deadlines for each individual task, the team ensures that the work they’re doing is moving the project towards completion.
Top Five Tricks for Using Basecamp
Of course, there’s no better source for Basecamp best practices than the team that created the software. Singer shared a list of their top five tips and tricks:
Identify unnecessary items. Often, the team will have ideas for a few things they’d like to do, but which aren’t entirely necessary to the project’s completion. For example, maybe there’s an optimization that would improve the software product, but if push comes to shove, it will function without it. The team will group these ideas at the bottom of the to-do list, and prepend a tilde (~) to them. It’s a way to differentiate between the “musts” and the “maybes,” so they know what to cut if they’re pressed for time. Here’s an example of what this to-do list might look like:
Divide the “chowder.” Since they categorize to-do lists by areas of customer concern, the teams at 37signals usually end up with individual to-dos that don’t quite fit into any of them. They call these tasks “chowder,” and they put them into their own list (think of it as the project’s junk drawer). While the “chowder” list is handy, Singer notes that you must watch its size carefully: if the list is too long, it means people aren’t thinking carefully about what they’re working on, or aren’t clear about how the to-do is contributing to the project.
Keep a high-level view to-do list. For projects lasting three months or longer, Singer keeps a high-level, “master” to-do list, which houses the names of the other to-do lists as line items. This allows him to see all the pieces that are in play, without cluttering the rest of the team’s focus. It also ensures he doesn’t forget the key areas the team identified in the beginning—even if they don’t know the to-dos for all of them yet.
Create a daily “status update” thread. Unlike many agile development organizations, 37signals doesn’t do stand-up meetings. Instead, at the end of the day, the first team member to stop working posts a message to the Basecamp project titled “status update.” The body is a set of bullet points stating what they worked on that day, and they include everyone on the team in the notifications. As the rest of the team finishes working, they respond to that comment thread with their own bullet points. This gives the project manager an overall broadcast of the day—and the manager can respond to team members’ specific bullet points with questions or feedback. If a team member’s status update doesn’t change for several days in a row, it can indicate to the manager that they’re stuck on something.
Get everyone’s feedback—later. Singer describes an early challenge for 37signals: a team of three or four people would work on a project in secret, and then, all of a sudden, the rest of the company’s 40 employees would be surprised by a new feature they had to learn in order to support customers. To address this, Singer keeps projects private in the beginning, when he wants to protect the team’s focus from the clutter of too many opinions. Once the projects have momentum and he’s no longer worried about the team getting sidetracked by outside feedback, Singer gives the entire company access to the projects. He will also create different groups on the “Everyone” page in order to send notifications to everyone on a specific team (for example, “registration app team”), instead of having to cherry-pick names out of the entire company directory.
Make Basecamp Work for You—But Keep It Collaborative
People come up with many creative ways to use Basecamp, and Singer endorses any use that works for them. However, he notes that the program’s best use is for collaboration–and its weakest is isolated issue tracking.
Some people at 37signals use Basecamp to create their own projects and manage personal to-dos, because they want everything work-related in one place. But Singer notes that they’re not getting the full benefits of Basecamp working alone. For his personal to-dos, Singer simply uses a text document in which he can easily copy, paste, create and delete high- and low-level bullet-point lists. Basecamp is unnecessarily cumbersome for such tasks, he says, and is only worth the trade-off when collaborating with other people.
“You’re really in the sweet spot with Basecamp when you’re using it to communicate and discuss things,” says Singer. “The further you get from communicating and [the more you get] into tracking, the less effective it is. But if Basecamp works for someone and they want to stretch it to do something it wasn’t designed for because they like it better than the alternatives–I think that’s great.”
Images courtesy of Ryan Singer, feltpresence.com.