Todd Webb

When we started using Basecamp for project management we focused on two basic features, milestones and messaging. We dabbled with to-dos, writeboards, and templates but never used them consistently. However, in late 2006 we decided that we needed to better understand how we were utilizing our growing development team (mostly external contractors). We needed time-tracking; however, I wanted it to be adopted quickly, consistently, and by 100% of the development staff. I needed it to be as easy as possible but still provide some useful decision support data.

Reporting Frequency

The first factor we considered was reporting frequency. We wanted to be able to make resource adjustment decisions monthly, so we needed a monthly report. We also desired a consistent reporting period. As a result, we settled on weekly reporting of hours worked during the previous Monday through Sunday period.

Granularity

The second factor we considered was granularity. Our goal was to generate reporting data that could be sliced and diced enough to provide meaningful decision support, but we didn’t want the team to spend more than 10 minutes per week recording time.

We ended up collecting three dimensions of time data including person, project, and category. We also collected time data in full hour increments rather than fractional hours.

To achieve high level categorization of hours we used a to-do template called TIME TRACKING with the following tasks:

• PRODUCT REQUIREMENTS
• DESIGN
• DEVELOPMENT
• INTEGRATION & TESTING
• LAUNCH
• OTHER
• PROJECT MANAGEMENT

We used upper case for all the task descriptions to make them stand out relative to any other to-do items that might be listed under a project. This to-do template was added to all projects with time tracking turned on. (We also used a shorter list of general time tracking to-dos for some generic projects related to bug fixing and other maintenance work). The time tracking option adds a small green clock icon next to each task. This provided us with a category dimension that was consistent but super easy to collect.

Entering Hours

The process to enter hours was really simple. Each week, preferably on Monday when memory was freshest, each team member would go to each project they worked on during the previous week and click on the to-dos tab. Then, one at a time, they would click on the time tracking icon next to one or more tasks in the TIME TRACKING list and enter the total number of hours they worked during the week on that project on that category. The hours were always reported on the date of the Sunday at the end of the reporting period. So if a week was missed for some reason the hours could be entered later with the correct Sunday date. Finally, team members entered a short note, one to two sentences, to indicate what they did during the hours they reported.

Training

Training on the process was pretty straight forward. We went over the process with the team using a Webex teleconference and I produced a short screencast video (for future team member training and review) that we kept on our internal wiki.

Reporting

Once we had the tracking process in place, and everyone was consistently reporting hours, generating monthly reports was a fairly trivial task. Each month we would look over the time reports for the previous month to make sure everyone had reported for all periods and there were no obvious omissions. We then exported the time report in csv format and opened it with MS Excel. Within Excel we created one or more pivot tables from the report data. We generally reported hours by project, by person, and by contract company (a dimension we could add directly in the spreadsheet). We also compared total hours reported to total possible hours using some assumptions to get to a 100% utilization baseline.

Costs and Benefits

Overall we estimated that the process cost us about 10 minutes per resource per week plus 15 minutes of project management time to download and generate management reports. The resulting data and pivot table reports provided us with more than adequate decision support information.

Conclusion

We were very pleased with the Basecamp time tracking solution. We were able to generate meaningful decision support reports with very minimal burden on the team and at very low cost.

Clearly, this solution was tailored to our situation. As an internal product development organization we did not need the granularity and accuracy that would be required to bill hours to clients.

If you are in a similar organization and you are considering using Basecamp, or already do, I recommend you give this process a try.

Props

I tip my hat to Jennifer Glaeser who helped to define and implement this process (the “we” I refer to above). Thanks Jen.

About two years ago I joined a small internet company as a project manager for product development. The company had begun using Basecamp as a tool to get a handle on numerous client and internal projects. During those two years I’ve been able to guide our use of the tool as we added some rigor to our project and development processes and, due to the acquisition of our company, I have observed some of the difficulties of using Basecamp in a rapidly scaled organization.

Simplicity Is Good

Because my development team (and in fact the entire company) was totally virtual, Basecamp filled an important need to compartmentalize project information in an online location. However, because we were also collaborating with sales, client services, and product managers it was important to have a tool that they could understand and adopt quickly. For this reason I have always appreciated the simplicity of the Basecamp product. While some may complain about the lack of features in Basecamp, I believe that our success in achieving complete adoption by the company (50+ people including employees and contract, with dozens of projects already in-process) in a matter of weeks is due mainly to the ease with which we could define processes and guidelines and communicate them to our colleagues.

Tool Simplicity Proposition: When implementing a new tool in an organization, more features lead to unnecessary processes, confusion, and wasteful debates on non-core issues. It is usually better to introduce the fewest features possible (and in fact hide unused features if possible) and slowly introduce new features and processes as the organization demands it and only after careful thought about the implications. (I may post something more on this idea later)

Scalability Will Be an Issue

So for a year or so we continued refining our use of Basecamp and exploiting more and more features as we gained experience. However, when the company was acquired last winter some of the shortcomings of Basecamp began coming to light. One of which is scalability. I’m not talking about scalability in the technical sense but in the usability sense. When you get past having a few dozen projects, a few dozen active client projects, and a few dozen employees managing the whole system becomes more and more tedious and wasteful.

One frequently requested feature that becomes more essential as the organization scales up is project templates. Because our company maintained a keen focus on efficiency of implementations and operations we quickly recognized some strain on resources to set up new projects. Being a resourceful shop from an operations standpoint we put some effort into scripting the Basecamp API to load up standard project setups based on a text configuration file. If you find your organization spending lots of time doing repetitive setup of projects in Basecamp, you may consider a similar approach because there is no template feature in the tool and no indication that 37signals plans to expand the limited To-Do template features.

Another issue you will likely run across when your organization scales is project access authorization and basic user management. While Basecamp is easy to use when you have a few dozen users it becomes more difficult to manage when you have a couple hundred internal users and a couple hundred client users in the system. As with any company we’ve seen the departure of a number of people over the past year and their accounts have remained in the system because no one thought to remove them. It can create a particularly large security hole if the person has been flagged to receive access to all future projects. Unfortunately, at this writing, I am not certain that the basecamp API allows any method to link up the user list with internal LDAP even if you did a lot of programming. It’s a major drawback to adoption in a large company.

Another issue is group authorization management. I believe some people use the Company concept to organize and authorize internal groups to access particular projects but that is not as elegant a solution as the Groups feature that 37signals has included in their Highrise product.

Conclusion

Overall I would say that Basecamp served us well as a small virtual company. It was easy to adopt for the non-technical folks on the team. It wasn’t distracting. Clients loved having one place to go to see everything related to their implementation. I would use it again if starting a new company myself. However, it will not serve your needs forever if your organization and client list scales significantly.

I don’t think 37signals has ever claimed that it would scale like that and would probably argue that they aren’t interested in serving that market anyway. That’s fair I suppose. As a result, it is worth paying attention and identifying a point at which your organization has outgrown the tool.

Does anyone out there have recommendations for identifying when you’ve reached that point? And if you have, what tools might be a good option to use for the next phase of growth while still adhering to the principles of simplicity and ease of use?