Basecamp Best Practices

Something surprising happened to me over the course of the last couple of months: I got railroaded by my colleagues at school into adopting Basecamp.

At Christmas time, two teachers asked me if I could set up Basecamp so that they could collaborate on the school play with a musician who worked outside the school. Unlike most school IT people, I try to make my default answer 'yes' instead of 'no', so I set it up.

Three months later, and without me pushing it at all, we just upgraded to the unlimited Basecamp plan and are now running 100+ projects. Another time, I'll explain what we're trying to do. Incidentally, many iPhone Basecamp clients don't handle this number of projects well at all.

Of course, with new toys come new things to worry about and my big concern was becoming overloaded with tons of sparsely-poulated projects. A secondary concern was notification overload.

I mentioned on Twitter that I was writing a "Basecamp Best Practices" document for the staff and a number of people expressed interest in reading it so here it is:

These are not prescriptive rules, but please do try to understand why I suggest these rules before breaking them!

Basecamp is not email

Yes, Basecamp has "messages", but those should be reserved for communication about the project in hand. Most communication should stay in email, unless it needs to be part of the project's record.

What I'm saying here is don't announce a quick 3pm meeting through Basecamp. On the other hand, the emails that the Office sends out about pupil absences would be useful if they were posted as a message in a pupil's record.

Avoid Notification Overload

Be careful before you subscribe "Everyone at Cedars" to your message thread in Basecamp - this will generate an email to everyone. Sometimes that's appropriate but just a word of caution.

Privacy and Permissions

It's possible to restrict access to your project to only the people who are working on the project. In many ways that's desirable, as it saves everyone from having to scroll through lists of projects they're not involved in. It also keeps that project's updates out of everyone's dashboard.

A Project Should Be Big and Focused

Try to avoid making a large number of tiny projects. A project should have a clear goal in mind and have a defined end point. If you go to the "Project Settings" link in the top-right, you can add an "Overview page announcement". It would be a good idea to use this to write a few lines about what your project is going to achieve. If you can't think of what to write, maybe that doesn't need to be a project.

Writeboards vs. Messages

The difference between a writeboard and a message is that anyone can edit a writeboard at any time. Messages can only be edited by their author within 15 minutes of posting. For any text that you want people to add to, you should lean towards using a Writeboard.

Here's an example of a message that would have been better as a Writeboard:

{a URL to a message thread with lots of "please add XYZ to this" comments}

...instead of comments asking for changes, the commenters could have just changed the writeboard directly.

A simple rule of thumb: if you want to discuss something, it's a message. If you want to work on it, it's a Writeboard. Remember that Writeboards can have comments attached to them.

Naming projects

In your Dashboard, all the projects are listed down the right hand side. This is going to get big fast. I've edited the names of all the policy rewriting projects to begin "Policy - " so that they all sort together. Similarly, the pupil profiles all begin [PRO].

Certainly Basecamp isn't perfect but I've been bowled over by how easily and enthusiastically my computer-literate-but-non-technical colleagues have adopted it.