All tools have their strengths and weaknesses. And, in addition, the best tool does nothing without good human project management skills using it. As a shop that practices Agile development (we use an adaptation of scrum methodology that seems to work for a shop that does multiple projects with small teams,) finding a good tool that facilitates instead of hobbles Agile was critical for us.

We found, and have chosen to use Redmine for our project management/ticketing system. You can think of it as a multi-project version of Trac, which is a fabulous ticketing/wiki system that we were initially going to go with. Redmine has the elements of Trac that we liked, with the added ability to track multiple projects. Like Basecamp, Redmine has document storage and messaging systems. It doesn’t have milestones per se, but it does allow you to see tasks in calendar and Gantt views, which is very helpful. Unlike Basecamp, you can add custom fields to tickets, users and other features. Having spent many hours in Basecamp, I actually like Redmine much better. It does even do time tracking, which we won’t use, but is nice to know is there. And the wiki is nice. Basecamp’s Writeboards seem so much more like an add on than integrated.

It’s a Ruby on Rails application, and that was actually kind of fun to finally get to install and play with RoR a tiny bit. And it’s great that it’s free and open source. Although that wasn’t an absolute requirement for us, it is most definitely a plus, given so much of our work is implementing open source web tools. And it’s nice to save a few bucks per month.

Web development trainwrecks are, sadly, far from isolated cases – they happen all the time, even when all of the parties have good intentions. And as someone who is building a business around doing this sort of work, it is of keen interest to me as to why some projects end up in the state that this project is in, and I want to make sure to avoid these kinds of situations. So how do we avoid trainwrecks? Some trainwrecks we can see coming miles away, but yet we are in complete denial about them. Some trainwrecks are like sudden derailments – it’s not at all clear where it comes from. But I think all trainwreck projects have the seed of the wreck somewhere in the history of the project.

The hallmarks of this particular trainwreck were so clear, that in retrospect, they scream out at me:

• Lack of transparency about development process
• Lack of transparency about cost implications of increased scope
• Waterfall development process (well, the vendor said they practiced Agile, but in practice, it’s been waterfall)

As a practitioner of the Agile development process (we use a somewhat modified form of Scrum, in particular,) I’m beginning to really see the value of this kind of process. It makes visible all sorts of things that are often hidden. It seems like the Agile methodology helps in a number of ways:

• Once educated, clients have a window into the development process. They know what small chunks of development are going to happen in a given time interval, and they know what they will get at the end of that time interval
• Things are developed in priority order
• Clients can critique things early
• New functionality becomes a part of the “product backlog” and it is easier to have clarity about what is and is not within scope

Of course, it is theoretically possible to be completely transparent in a traditional waterfall methodology, and completely opaque using Agile, but I do think that the Agile methodology makes it way more difficult to be opaque. But it also takes some work and education of clients unfamiliar with the methodology (as well as making mistakes along the way on our part as developers.)

And I’ve been able to watch this process work well, not only with our own projects, but also with a project I was a strategic lead on. I was pretty skeptical a year or so ago, but now I’m sold. And since transparency has always been something of real importance to me, a development process that encourages transparency is a good thing.

• CiviCRM/Drupal (with Joomla notes)
• Plone/Salesforce.com
• Using varied webforms (like DemocracyInAction, Blackbaud, Network for Good, etc.)
• Drupal/Salesforce.com
• Joomla/Salesforce.com

You’ll notice that only Drupal, Joomla and Plone are represented among CMS. That’s mostly because that’s what I know, and there is a critical enough mass for all three of them that some integration work has been done in a systemic way (the exception to this is Drupal/Salesforce – it’s only half-way systematic.)  I  haven’t included any all-in-one systems (like Kintera), mostly because I don’t think they are a good idea – you might get a halfway decent CRM, but you’ll for sure get a crappy CMS, and there is no good reason for that. Another note: I’ll talk about this in detail later, but Salesforce also includes the new Salesforce.com app, Common Ground, by Convio. From what I can tell (I’m learning a lot more fairly quickly) integrating Common Ground with a CMS should be pretty much the same process as integrating Salesforce.com.

First up, CiviCRM/Drupal. I’m choosing this first because it is a pretty interesting example, and also is an example of what I would call easy and tight integration.