There’s a line from the animated Comedy Central show Dr. Katz that used to run in the 90s … a patient wonders aloud to the psychiatrist (the aforementioned Dr. Katz) why he’s paying exorbitant hourly fees for weekly sessions when he feels like he’s doing pretty good on his own. The doctor explains there are times when he’s overqualified and suggests all the patient really needs is just a “smart aunt”. It’s always reminded me of technical consulting – some clients need ongoing sessions with trained experts, and some just need the equivalent of smart aunt to dispense advice and nudge them along (and some need pretty intense psychotherapy, but that’s neither here nor there…)

Psychiatrist, non-profit consultant. We have similar goals – help the client to help themselves, to the point where they don’t need us anymore. Sounds like planned obsolescence… but don’t worry about us, “plenty more patients where those came from” and all that, ha-ha. The more we get to play the smart aunt role, the more clients we help. Personally, I love the smart aunt role. Don’t get me wrong, if a client needs to lay on the couch while we guide them to a successful project, then that’s what they need. But they’re paying for the privilege. And I’d really rather they spent their money on saving the world. To that end, here is some advice on making consultants work for you.

Is This a Website or a Data Integration Project?

You want a new website and a checklist of features. Forums? Check. Events calendar? Check. RSS? Check. Single sign-on with your AMS and Active Directory? Che… Wait a second, see what you did there? You just started a new project, whether you knew it or not, and whether the PM calls it one or not, and it isn’t part of your website. No, your website is part of it – a data integration project that extends to several of your systems of which the website is one. It might be a mini project or a major project, but it and your website are separate initiatives, initiatives that require their own planning, own meetings and own set of core team members that may or may not overlap. Get that new project started right or kick it out to another phase, or you’ll be spinning your wheels and burning hours.

More after the jump…

(more…)

Editor’s note: With the busy holiday season upon us, the Beaconfire Staff has had no time for blogging (as you may have noticed!). But to make up for it, we’re “reprinting” some of our most popular posts of the last couple years. Hopefully we’ll be back to generating new content soon, but for now, please enjoy Tim’s post for anyone who’s had to cut emails with the new Outlook.

There has been much discussion lately about Microsoft’s decision to abandon IE as the rendering engine for HTML emails in Outlook 2007. It’s hard to conduct a level-headed exchange on this topic because of strong feelings about HTML vs. TXT emails, and personal, professional, philosophical, or theological issues with Microsoft. Putting aside the endlessly repetitive and unproductive argument about whether Microsoft has any idea what they are doing, and whether or not it is a good idea to send HTML-formatted email messages, let’s look at the facts.

Molly Holzschlag’s (molly.com) post on the subject says that the impetus for this change was the unacceptable differences that MS Outlook users were seeing between what they saw in their inbox (rendered by IE engine) and what their friends saw when they forwarded those messages on to them (Composed by Word engine). Or when they composed messages from scratch (Word in Outlook) and their friends tried to read them (IE engine again). So it makes sense that you’d want the same engine to create a message that you use to view it. But Word? Really?

The problems enter in when you consider Word’s HTML engine: It’s inarguably sub-par. Already, those of us who create the HTML for use in client’s campaigns are forced to utilize a mish-mash of HTML coding techniques, some of which we’ve long left behind in building web pages. This isn’t just Microsoft’s fault; ALL of the email clients we test in have slightly different quirks and shortcomings. As a result, we are still using tables, spacer gifs, and (in many cases) font tags to layout our templates. So this is a situation of something broken being broken in a different (and perhaps worse) way when it really could have been a step toward fixing it.

So what do we do? Test about a bazillion times. This has always been the case. We have always had to test the rendering of our HTML messages in (at least) Gmail, Hotmail, AOL, Yahoo, Outlook, Outlook Express, Thunderbird, Mac Mail, Entourage and — if we can, and depending on the client — Eudora, Pegasus, Lotus Notes, or Groupwise. The testing required for Outlook 2007 adds a new wrinkle to the Shar-Pei, but regardless of Microsoft’s decisions regarding rendering engines, did anyone really think that 2007 would render the same as previous versions? Not likely. However, most of us thought that we might see an improvement due to IE7s increased support for CSS.

Anyone using email newsletters as a mode of communication urgently need to have their templates reviewed in order to ensure that future messaging remains successful. Many existing templates will not be Outlook 2007 compatible, and can almost be counted on to break when viewed. After all, nobody in their right mind has been designing email or web pages to be viewed in MS Word! It just wasn’t ever something we dreamed we’d have to test.

Were not entirely in the dark, however. Microsoft is supplying us with some information on Outlook 2007 HTML and CSS support, as well as a validation tool. Read up, test twice as much and we’ll all pull through. If we just stick together.

Microsoft Tools:

• 2007 Office System Tool: Outlook HTML and CSS Validator
• Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2)
• Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2)

Other articles and discussions:

• Excellent article by Dave Greiner of Campaign Monitor
• SitePoint post by Kevin Yank
• Arstechnica post by Jeremy Reimer