Earlier this week, if you happened to read any of my research on our site, you might have been scratching your head at my “new” photo, as seen below.

You might have asked yourself, “What has happened to one of my favorite Forrester analysts?” Was it the result of a) a face lift; b) gender reassignment surgery; c) successful prayers to the patron saint of the un-photogenic (when a good friend first saw my original photo last year, she asked in her typical blunt fashion, “Why do you look so puffy and awful?”)

Actually, what happened was: a bug in a recent code release for our Web content management system resulted in my colleague Lisa Pierce’s photo displaying on my documents, instead of my own. OK – not exactly an earthshaking problem (and Lisa is much more photogenic than I am). But it was kind of a glaring error, and the ribbing I had to take from my colleagues wasn’t exactly a bonus, either. And because of the timing of the error, “the new me” was on our site for almost 24 hours.

So, I thought I’d take the opportunity to put on my practitioner’s hat (the one I wore for 15 years before joining Forrester) and remind everyone of some basics for publishing Web content:

  • Technology is no substitute for QA. It doesn’t matter how good your WCM technology is, there is no substitution for good, old-fashioned quality assurance. Many enterprises, particularly those that have implemented complex Web site customer experiences, now treat their WCM code and content releases similar to traditional software releases, bundling changes together and doing a full cycle of QA on a separate server (this is where your vendor’s multistage deployment support takes on added significance).
  • Avoid, if possible, late-day code releases. Some organizations have high-volume publishing needs, and can’t avoid late-day code releases. But others don’t have this requirement, and publish anyway, leading to costly after-hours or weekend support calls. Enterprises with successful WCM projects understand the need for disciplined release schedules and set expectations accordingly.
  • Don’t forget the documentation. Documentation tends to get the short shrift in a WCM project, but remember that good documentation leads to fewer support calls. And make sure that you have clearly documented a bug reporting and escalation plan so that when critical errors do occur (and they inevitably will), members of your organization know how to report them.

It’s easy to forget the fundamentals when in the midst of major content deployments or code fixes. Being disciplined requires effort, but it can be well worth it. At the very least, it can help you avoid or shorten the length of mix-ups, like my temporary gender change this week.