Steve Backman's blog

Basecamp and Project Management

By Steve Backman, November 16, 2008
Back in September, Peter Campbell kicked off a discussion about project management in this space. I wanted to pick up the thread by focusing in on Basecamp. Among project management-related tools, Basecamp has the buzz. It is quite common when we start a new project, that someone from the team involved will have used it and know their way around it.

The company 37Signals offers Basecamp as a pay as you go hosted service. On their web site, 37Signals tags Basecamp, “Get projects done.” Searching Google for “Basecamp ‘project management’” yields 227,000 hits this morning. All that said, it is a mistake to consider Basecamp a project management system. It is much better to think of it as a communication tool that supports project management.

Interestingly, the 37Signals tagline expands to “Basecamp is the smarter, easier, more elegant way to collaborate on your internal and client projects.” Facilitating collaboration is definitely Basecamp’s strength. As a standard practice for our web and other projects, we store project documents (tracking revisions); set major project dates (milestones); track tasks that follow from those milestones; collaboratively edit and design documents; and above all, as a way to have easy, lively blog-like discussions of project issues. You can follow projects messaging via email or subscribe to an RSS feed.

There is a lot you can do with these tools to keep a project moving ahead and keep a whole team, typically including client staff and consultants. From a formal project management point of view, however, you may miss some things or find what’s there incomplete:
  • You can’t assign dates to individual tasks (only to entire task lists associated with a milestone). This is perhaps the biggest grievance on the Basecamp forums features wanted list.
  • You also can’t prioritize tasks or assign more than one person to them. These things mean that you can’t really use the Todo lists as an issue or “bug” tracker.
  • You can’t create Gantt charts or other formal project management diagrams.
  • You can create templates for individual todo lists, but you can’t template a whole project. So, we have a todo list template for our steps in a configuring a new Drupal install, but not a template for everything that has to happen from design to go live.
  • You can track time spent on tasks, but you can’t bill from that time. There are add-ons that help with this.
  • It is easy to maintain multiple projects with multiple client teams and keep them separate and secure, but you can’t assign project-level administrators. All administrative roles are global to all projects.
  • Somewhat different: the collaborative note pages (“writeboards”) use a wiki like mark-up language. Most folks would probably refer a standard editor.
  • Basecamp alone doesn’t have group chat, though you can add it in using 37Signals’ “Campfire.” This allows twitter-like project-based discussion.
Despite these gaps, Basecamp makes a lot of sense when your style of project management emphasizes collaboration. This is particularly so where you need to have collaborative teams including both client staff and outside designers, strategists, developers, which is typical for us. Further, I find myself often in the situation of convening teams that include folks thrust in the position of managing software or web projects for the first time. They have the budget, they have the goals, they represent users with needs, but they aren’t used to what happens next.

Basecamp is in the space as other systems we have tried, including Central Desktop, Zoho Projects, Active Collab, and, yes, our own Drupal-based imitation of some of the features. My thoughts here to some degree apply to all of them, even where some of these have some of the features not (yet) in Basecamp. Emphasizing what we called the client-side coordination of project management, we have found Basecamp’s well-engineered, intuitive, Web 2.0-ish, framework a plus.

Basecamp presents the most essential features for collaborative, iterative, even agile development in an appealing, less techy, less threatening way. It is a compromise, but using things that have more of a full project management mold may produce a drop off in team us. We find greater fall back on just emailing the project manager and expecting him/her to repost messages.

In the Basecamp forums, users express a lot of frustration with 37Signals nonchalance about some of the feature requests mentioned above. It has to be said that they do regularly add features. In the last year or so, they added the ability to response to emailed messages from within your email. They added discussion threads on individual tasks (todo’s). These and some other functional and usability improvements have made a difference. When I read some of the frustration and even anger at 37Signals (ok, see http://www.whybasecampsux.org), I also think about what which of the front line features, including ones we want, might tip things back toward less team participation. If individual tasks had space for due dates, priorities, and multiple team members, would that discourage the client staff from quickly easily throwing things onto lists for everyone to process?

In other words, it’s a trade off.

For those out there using Basecamp, here are some of the things we have found that make a difference:
  • Show people in person how to use it as part of a planning meeting. Don’t rely on just adding people and sending a message.
  • Although you can’t “clone” a project or have a project template, you can create todo list templates and these can really help frame standard approaches in your project streams.
  • Continue to monitor regular email, copy messages into Basecamp and respond there, and don’t make a big deal about it. Over time, folks will likely grasp the advantages of using the system and drift over.
  • Make sure you choose everyone’s best email address.
  • Use external links to incorporate external tools that might have your higher end PM functions. Create a project note (“writeboard”) with web links to google docs or spreadsheets, hosted project diagrams, wiki pages, issue tracker, code repository, or resources from other systems you use. This keeps everything centralized.
  • Check out the add-ins to Basecamp. There are both free scripts (for example, see these cool Firefox scripts for basecamp: http://userscripts.org/scripts/search?q=basecamp) as well as paid resources. (http://www.basecamphq.com/extras) For example, one I like that is cool and inexpensive is ThickToast from vb123.com. It allows you to take the standard XML export of your project data and bring it into an Access or SQL server database for further analysis or integration. There are also tools to integrate with popular products for time tracking, SVN code repository, billing and more.
So, bottom line for us has been, get past the idea that adopting Basecamp, or other such communication software, will give you a complete project management system. Instead focus on its use as a tool to support collaborative styles within a project management framework.

Building Intranet and community network sites

By Steve Backman, October 6, 2008
These days, having an “Intranet” comes up a lot as a requirement for website projects. I’m using the term advisedly to refer to a range of needs for private space for organizing campaigns and collaboratively developing ideas.

This is different from project specifications that call for members-only sections. Those kind of requirements typically focus on log-in based spaces for designated folks to download private materials, sign up for events not open to the public, maintain their profile and so on. The “members-only” pages communication model typically still has your organization and your site at the center. It places constituents in individual relationships with you.

Here we are talking about requirements that point toward building a communication and collaboration network. Contact, discussion and organizing takes place among the participants as well as with the site owner. Historically, Intranet referred to private spaces for organizational staff, while Extranets extended to clients, volunteers, board, and more. With more organizational work flowing through collaborative networks, the distinction doesn’t seem as important. Typical requirements that organizations bring us today include:

  • a shared space to brainstorm, draft, edit public policy documents or strategy and tactics for advocacy campaigns
  • space for community organizations doing the same kind of work, such as immigrant rights or youth services, to collaborate on development best practices documents
  • spaces for researchers in different places or in different organizations to collaborate on community development or employer research agendas
  • private spaces to post and discuss assignments for classes in a school or workshop trainings
  • shared private calendar of events of interest for organizations working together
Many tools out there can be adapted to meet needs like this—whether this was their intended purpose or not. We find ourselves recommending several kinds of possibilities, ranging from the simple and out-of-the-box to the more complex. Planning and customizing may make a lot of sense when you need to develop a more strategic collaborative model with specific community networks, particularly less technical and more program-driven and community-based teams. Where time, cost, staff attention span pose limits, simpler solutions may do. And they could serve as proofs of concept for a second generation strategic initiative.

  • Creating a wiki. You can do this using an inexpensive hosted service, such as wikispaces or zoho’s wiki, or you can install on your own server the original mediawiki or newer full systems such as tikiwiki. Wikis have the advantage of totally flexible, malleable structure for sharing knowledge. They intentionally have limited features and the formatting or mark-up syntax may frustrate less technical folks.
  • Creating a simple web site that is mainly kept private. Google sites or Wordpress come up as solutions of this sort. In just a few hours, a site can begin to emerge that can have private discussion spaces, with blog-like commenting, places to store documents and keep track of revisions, make lists and calendars to organize a work plan and collaborative needs. Google sites have the advantage that they build on what for many is first-order collaboration—sharing an individual Google document, spreadsheet, or calendar. Wordpress has more polish and can be installed locally.

  • Adapting project management tools for a knowledge network. We have used and recommended Basecamp for this, and Central Desktop offers similar solutions. These are hosted services, with fees per month that grow the more private spaces you create. Again, you can also have blog-like discussion and commenting, collaborate and monitor versions of documents, have an organizing calendar and so on.

  • Sharepoint from Microsoft offers similar features to the last category. Though an extension of an internal network, it can be opened up to outside team members as well. Larger organizations put a lot of time into customizing it or using its integration with Exchange and other Microsoft stuff, if that is your path in life.

  • All these choices come up as alternatives to building the Intranet or collaborative space as a section of a public website. All the major content management systems, both proprietary and Open Source, have this ability to one degree or another. When the needs go beyond the simple, the power of a full CMS can and should be harnessed to meet goal driven needs. At one time, we thought that all our Drupal websites could just have the same Intranet/collaborative space option. The advantage over just using one of the other types of tools here comes from the ability to refine different types of users, categories, workflows and so on. And this is true with the other CMS systems.
There is planning to be done for any of these options. For example, choosing whether it’s OK to have your private discussion and materials hosted outside (even if based on logins) versus the security of installing it locally can be an important consideration. The communication model for new users, including around email integration, needs careful consideration. You will need to determine what will bring your intended participants into a lively collaborative network, how much structure you need to provide, who will monitor it and other such questions. It is great to know that once you work through these questions, the technical choices get better all the time.

website software dilemmas

By Steve Backman, September 16, 2008
Is it just me, or is everyone redoing their web site all of a sudden? This summer, we had a rash of requests to talk about web site options. I am writing this after a neighbor who has never previously talked tech with me literally stopped me in the street about her organization’s site.

Here’s the problem. A redesign today isn’t that different than it was five years ago. The process is about the same. The time commitment, designer hours, and cost is about the same. Many people still think that’s what they need. Liven up the design, get new content up, and show you have a pulse.

OK, everyone today also wants easier changes to their site. Nonprofits held captive to board members or the founder’s niece for every little change is so 1990s. If you redo your site with Adobe Dreamweaver, at least get set up for easy page maintenance with companion product Contribute. Inexpensive (from TechSoup), easy to learn, and no web designer needed for adding content and keeping up to date.

But these days, it’s really a makeover plus. Once you get talking, most folks want more.

You soon cross a threshold where the choice to just update the site conflicts with the things you really want to do, if not now, then soon. Better cataloging of material; “members only” special content; commenting, tags, ratings, news feeds, tell-a-friend, printer friendly pages, and all the rest to make your site easy to use.

And it’s not just click- to-donate anymore. It is event registration; Analytics; blogging; internal planning, discussion and organizing; community calendar; newsletter signup and on.

If you are not doing a lot interactive yet, you can definitely tackle a couple of new things as add-on services for now. There’s lots of great, free or inexpensive pay-as-you go a la carte services for blogging, events, calendars and more. A la carte often means different visual looks and no shared contact information.

Much better to move to a content management system, such as the big Open Source ones frequently mentioned here--Drupal (our favorite), Joomla and sometimes Plone, as well as the pricey commercial ones like Kintera and Convio, and the many lesser commercial ones discussed on idealware and techsoup. Yet the leap to a full installation of one of the content management/web development systems, including a strong visual design “theme,” and all your content, will cost substantially costly than just updating the site in Dreamweaver.

It is truly worth it because you will now be on a modern platform that can and will continue to evolve as your needs evolve. What’s tough and unexpected for many small organizations is justifying the additional cost to get there, if you haven’t planned on it. These are hard choices for folks with small budgets.

When I have these conversations and it looks like it’s going to go in the direction of a traditional Dreamweaver facelift, I find myself musing on Rick’s words to Ilsa in the final scene in Casablanca. I think to myself, if your new web site takes flight in 2008 or 09, and it’s not on a CMS, then “you’ll regret it, maybe not today, maybe not tomorrow, but soon, and for the rest of your life.” Well, maybe not the rest of your life, but Bogart’s Rick is a lot tougher than me.

It’s hard telling people they should wait. There’s certainly lots to do to prepare for a full blown web upgrade. Focus on your email newsletter so you know your constituents; see how hard or easy its going to be to get new stories on your home page regularly; start a linked blog; study your Analytics; focus on evaluating your contact management.

And there are ways to experiment. Google Sites, Wordpress, wikis and Ning all come up for us as alternative to full blown CMS-driven systems. These are easy, lively, even fun. And they can be done with not just less budget, but less planning time from organizations than building a full Drupal or Joomla site. They may suffice or they could be experimental before committing to bigger project. There’s no universal truth on this matter, and it’s a great time to move forward.

Syndicate content