Ex Machina

“I asked for a systems integration, and for my sins… they gave me one.”

Okay, so integrating a CMS isn’t exactly Apocalypse Now. I’m not going to have to kill Marlon Brando. But the “sins” part is accurate. My employer has used the same, proprietary CMS for nearly six years now. My relationship with it began as a content admin. Later my role evolved into acting as project manager for enhancements to the system (and to the presentation channels it supplies with content). These days, I wear the software business analyst hat most of the time.

My company’s CMS — and the ways it feeds our web, print, and e-mail channels — resulted in part from choices made by our internal stakeholders and software vendors, but also from my stewardship. And now I’m part of a team that’s been sent to kill it, and replace it with something better. Our old CMS is my Marlon Brando.

This mission is still in the secret phase. But I can say a bit.

Background, then. Our current CMS is an octopus. It started out as an SQL database connected to a .NET web site. The travel industry operates in a complex regulatory environment. Our customers need a lot of information, and our products have a lot of moving parts. Hence it’s 100% proprietary.

As time went by, we began to build hooks into the company’s AS/400 customer and inventory database. Later, we began using it to feed content to two other applications — a .NET customer service web app, and an online booking app written in IBM Websphere eCommerce. At the same time, we built feeds to share its content with our e-mail marketing provider. And finally, we integrated it to share content data with our print CMS, Quad Systems Catalog Studio.

Six years of learning later, it’s clearly time to move on. Our CMS is a system of impressive scope and an important tool for our organization. But organizational change and rapidly shifting priorities have meant that some of the design choices we made were just the lesser of two evils.

The good news is that the amassed knowledge of how to map our business rules to our software is relatively portable. Riding herd on the business requirements and seeing that the transition is a seamless one for stakeholders will be my primary responsibility during the project. As I go, I’ll be blogging, inasmuch as I can without publicizing my employer’s internal processes, about the project, its challenges, and our solutions.

We’ll be moving to a single, unified CMS for all digital. It’s an off the shelf solution produced by a major player in the CMS game, but we expect their integration team to customize it very heavily for our use. As it always goes with such projects, our timeline is an ambitious one. And there won’t be any interoperability between new and old systems, since we’re moving from SQL to a very different storage model — meaning challenges in migrating our current content data.

All that said, I’m looking forward to it. Sorry, Marlon Brando. Been nice knowing you.

I realized today that it’s been several years now since that last time I worked on a major project that didn’t use Basecamp. This isn’t just because we’ve come to favor it where I work now. I’ve done a few side jobs in the games industry and found that my collaborators were already using Basecamp. Vendors I work with regularly suggest it, too. Some even look a little downcast when they find out they don’t get to initiate me into its many joys.

Still, there are people out there who still think Gantt charts painstakingly rendered in Microsoft Excel are the only way to do things. Old school project documentation has its place, to be sure, but it can’t touch some of the ways I’ve used Basecamp. A few examples of these uses will explain why I’m a huge fan of 37signals.

• E-mail Papertrail. “I said, and then the vendor said, and then I said…” …and then there’s a gap in the correspondence right where you thought the vendor had agreed a given feature was in scope. Oops. Even with modern e-mail clients, keeping track of all of the conversations that fly around during a project can be nigh impossible. My solution for a while now has been to have these conversations in Basecamp, and if they don’t start there, to move them there as soon as they look  important. Having important discussions in a threaded, searchable repository is much better than keeping them in e-mail, especially when you go looking for them two years later.
• Bug Tracker. For some projects, there’s no substitute for an industrial strength bug tracker like Bugzilla or Mantis, but sometimes you don’t need the level of detail provided by Bugzilla. It can even make the QA process more cumbersome. Basecamp can be a nice alternative. My approach is to create a new project specifically for tracking bugs, then create categories corresponding to bug status.
  For example, on a recent project where I was tracking issues in a large batch of e-mail campaigns, I created one category for “open” and another for “resolved.” I further divided them by the subject matter of the e-mails, and I ended up with something like this:
  • Finance e-mails/open issue
  • Finance e-mails/resolved
  • Call Center e-mails/open issue
  • Call Center e-mails/resolved
  • etc…

  I then opened a message thread in the relevant category each time a new bug needed to be addressed. The beauty of Basecamp in this role is that you can change the category of a message thread. So once I had an issue resolved, I just re-categorized the thread to the relevant “resolved” bucket.

• Face Book. The “People” feature in Basecamp does something awesomely simple that you don’t get from e-mail or business cards: it lets you put in your picture. I love this feature, and I wish everyone would use it. On big projects where one company or both might be quickly introducing large teams to each other, you’ll probably remember the people from the other side whose roles dovetail with yours. But it can be hard keeping track of everyone else, and it’s not as if people automatically exchange LinkedIn profiles. I’m good at remembering people, but I’m sure this feature has helped people remember me a few times.

Finally, I love 37signals’ commitment to keeping this product simple. If I need a Gantt chart, a list of resources with billable hours, or some other feature Basecamp lacks, it’s easy enough to supplement what it does with documents produced in other products. Meanwhile, the core app remains fast and easy to use.

Basecamp isn’t just a tool. I’d say it’s more like a secret weapon, but most smart people with big projects know about it by now… and that is all to the good.