Basecamp: Blessing or Curse?
When I first saw Basecamp, it was a couple of years ago at a different company and we just started working with contractors. We didn’t have any good way for the team to communicate with the contractors other than via email. It was inefficient, scattered, and not easy to get off track with the various projects. When Basecamp was released, I thought it was amazing and exactly what we needed. It helped us organize the various projects with outside contractors and gave us visibility into the status of the various projects.
Fast forward two years. Now I work in a very different environment. With my previous company, we had maybe two to five projects happening concurrently. At Pop Art, we have at least 20 or more happening at the same time. When various customers had difficulty accessing our extranet, I suggested Basecamp as an alternative. “Suggested” is probably a gross understatement as I truly fought hard for Basecamp. What I didn’t realize was how Basecamp would both be a blessing and a curse in this new environment.
Basecamp had grown up in the year and half lapse since I had used it last. It added many new collaborative features. It extended the features centered around the message board and the file repository. It also added a great new feature called Writeboards that turned Basecamp into a Wiki like tool. I would bring it up now and then when we had internal discussions about how to improve our extranet that only worked for some customers. None of the features were reason enough to switch but their possibilities excited me.
In December of last year, a project came a long that was unlike any other. We had just jumped head first into web standards based design and started on a project where we were to design 24 web sites for SelecTrucks dealers in 30 weeks. With two designers, one CSS architect, two developers, one project manager and a whole lot of drive, we were going to need a tool to keep the project on track. Sending 24 different schedules to the team for the dealer sites was not going to work as there was going to be a lot of overlap with dates and deliverables. We needed a simple yet powerful tool that could centralize the schedule for the two dozen sites. We chose Basecamp and it was a huge success. Without it, I don’t know if we could have stayed on schedule with the project. It had some issues, especially with moving deliverable dates around but overall it helped the team stay on course.
Eventually when other small projects surfaced, we threw them into Basecamp as well. When the director of the PM department saw how much the design team loved the tool and it helped projects stay on track, she decided to give it a try (with a lot of convincing on my part). What happened next both exposed the strength and weakness of Basecamp as a tool for an agency like ours.
Once we adopted the tool, we went all in. It didn’t make any sense for us to only put some of projects in. It was a lot of data entry but with everyone willing to give it a shot, we were soon up and running. It was a success. Even with some issues here or there, the centralization of all current projects in one simple tool was very empowering. It was so successful, that we also moved over the information from our two home built maintenance task web apps. It was at this point that Basecamp became both a blessing and a curse.
The Curse
1. What project manager?
In an agency of our size, the role of the project manager is critical to success. Basecamp doesn’t recognize roles and this is a problem. The only roles that Basecamp is aware of is “Private” and “Public” - usually translating to “Team” and “Client”. It is easy enough for any team member to log in to Basecamp and filter by their milestones or to filter by one of their projects, but there is no convenient way for a project manager to filter by their key projects. Either they get all of their projects that they are a part of or only their own milestones. Another problem is that other than through RSS feeds, a project manager has no way of knowing when milestones or to-dos are checked off. This has led to the strange practice of our designers and developers sending the project managers an email to let them know something is ready to be checked off. The more we use Basecamp, the more I realize that Basecamp is designed to be the project manager instead of helping a project manager.
2: Tickets please
When we moved our maintenance tasks over to Basecamp, we soon realized that there was no good ticketing system included. To simulate a ticketing system, you have to put in a milestone, then associate a message with it, then assign it to the first person. When that person is done with it, they need to change the milestone to be assigned to the next person or they need to check it off and create a new milestone for the next stage of the task. Even if they try the former technique, they need to change the milestone date. This can be very complex for such simple functionality.
3. Can anyone To-Do this?
The To-Do feature is powerful but it cannot be assigned to anyone nor have a due date. In an agency, there are deliverables which the client is aware of and internal deadlines which the team is aware of. It would be great if the to-dos could be assigned to internal resources and we reserved the milestones for client deliverables. Because of this limitation, To-Dos are rarely used and internal tasks are created with milestones. This makes the milestone queue very dense and eventually prevents the sharing with clients, limiting one of its most powerful features.
4. A dashboard is worth a thousand words
The dashboard for all projects in Basecamp works great if you have a few projects that you are associated with. When you are involved in 10 projects or more, the dashboard becomes almost unreadable. Milestones do not have project titles associated with them so on the same date in the dashboard it can say “Design Comps” and “Design Comps” and until you click on that milestone you don’t know which one is for which project. This forces our project managers to put abbreviated titles for our projects at the beginning of milestones which just makes the process of entering and managing milestones that much more complex.
5. Miles of milestones
The worst side effect of any project management tool is when their is maximum effort required to change the project schedule. If the schedule is too difficult to change, then an artificial resistance to change can be introduced into the project. Basecamp has an all or nothing feature where milestones following any milestone can either be shifted as many days or not, but this is not “smart” enough to make a project manager efficient.
With all of these issues, does Basecamp have its place in a creative agency? Yes!
Next post: The Blessing

You might want to take a look at Goplan. It addresses most of the issues you mentioned. Send an email to goplan@webreakstuff.com if you want an invite.
Comment by Tiago Macedo — October 19, 2006 @ 10:34 am
For the past couple months I’ve been writing the specs for my new project management system. This information is quite useful. Thanks!
Comment by Ryan Brooks — October 19, 2006 @ 4:07 pm
I hear you.
I’m actually in the beginning stages of creating a online project management application for everyone from freelance designers to design firms, it will cover everything from an integrated client extranet to billing and invoicing.
It all started when I was looking for a solution to manage my own projects.
Comment by Chris Robinson — October 19, 2006 @ 5:02 pm
I know with RE-volve we are looking into SalesForce. They have an AppExchange which has tons of really cool things. Some are free some are not, but there are tons of things you can use with it…plus you can customize it for yourself. You can create and tie in your own edits to make it work how you like it. I am not a rep, just a happy user.
Thanks,
Seth
http://www.re-volvemedia.com
Comment by Seth — October 19, 2006 @ 7:42 pm
Hi, You might want to try Agility from AgileEdge… http://www.agileedge.com. Its a really nice light project management tool that does the ticketing aspect you were refering to really well.
Comment by Mike — October 20, 2006 @ 2:16 pm
[…] Pop Art Design Team « Basecamp: Blessing or Curse? […]
Pingback by 72 dpi In the Shade » Basecamp: Blessing or Curse? Part II — December 7, 2006 @ 11:42 pm
While I think basecamp’s overall concept is great (I used basecamp for 2 year), there were some things that seemed small at first but ended up driving me nuts. Fortunately, basecamp has some good competition now. I recently just switched to OnStage, a very similar but slightly better design system, IMO.
Comment by Brian Kaminski — May 12, 2007 @ 2:40 pm
Why bother about all those software drawbacks? Why not just go for something else? These were quiestions I asked myself trying to use Baseccamp. Goplan is no different, it’s more like a Basecamp clone. I’ve chosen Wrike http://www.wrike.com/. This artilce helped me http://www.pcworld.com/businesscenter/article/134816/project_management_lite_basecamp_and_wrike.html
Comment by Ikey — October 2, 2007 @ 7:33 am
I agree with Brian, the competition is heating up and Basecamp is not moving in a very agile way. SharpForge has the role based access (including the ability to configure anonymous access), work item tracking and then goes futher. Each project has a Subversion repository and a wiki. The wiki content is stored as versioned html in the repository. When you commit a change your can reference workitems with #{number} or commits with r{number} just like in trac. Basecamp is good but it just just wasn’t designed to evolve.
Comment by Clare Leech — March 18, 2008 @ 11:52 pm