Project Management

Information overload: When to send clients FAQs and when to just do the work

Ken Hardin offers IT consultants guiding principles about how to try to explain technical details or operational minutia to clients.

It's human nature to get sick of something and want to move on. That's certainly true of IT projects for consultants. At some point, you want to transition to the next challenge / payday. And eventually maintenance on a contract can become a distraction (if not a downright irritant), particularly if you find yourself repeatedly addressing the same issues, over and over.

I get that.

But you also have to remember that your client hired you for a reason -- they aren't technologists, or at least they don't share your specific technical expertise. What seems to be the most simple task or tweak to you may well be terrifying to them, and fraught with possible errors that would not occur to you.

Case in point: I recently contracted as project manager on a local news site re-launch that included a re-design of the site's daily, RSS-driven newsletter. We moved from basic Feedburner (run away) to MailChimp, pretty much like everybody else, to support the inclusion of ad server tags and multiple content blocks.

I know exactly nothing about MailChimp's custom templating language, so I went shopping for somebody to convert my GIF mock-ups to a functioning template. We ended up settling on a well-rated, U.S.-based shop we found in a Web marketplace. The whole gig looked to be about $400-$500, and then on we would go.

And then the fun started.

I could (and may) write several pieces about what a nightmare this seemingly innocuous job turned out to be. I ended up teaching myself Yahoo Pipes (remember that?) to parse my client's site feed into the desired content blocks within the template. And don't even get me started on "responsive design" for email.

Some of these frustrations are understandable from the creative shop's point of view -- they simply don't offer the service of setting up client feeds, and it's not their fault MailChimp has never considered that folks might want to start a content block in a newsletter somewhere other than the first item in a feed.

But on issues that were under the services umbrella with this shop, the response was almost invariably a link to an FAQ page on their site. Responses (strained but polite) that we'd really rather prefer that they make the change since a) they are supposed to know what they are doing and b) we were paying them for a functioning deliverable were met with more links to FAQs.

The last straw came when a late-game tweak caused the RSS feed items to stop publishing hyperlinks altogether. (Yeah, you can actually cause that to happen in a custom MailChimp template.) Hurried mails and an offer to pay for the fix resulted in a mail from the PM (who was always polite) with an incorrect variable and no specific instructions on how to implement it. Without the help of my coder -- over a beer, he just guessed out the right variable and we dropped it in a standard HREF, which as far as I know is entirely the wrong approach, but there you go -- I would have been totally screwed.

All on a simple $500 templating project for a site that is not in the business of creating MailChimp templates. My client will never tackle a project like this on its own... basic templates are all they need otherwise, and if they ever do get a hankering for another custom template, they will pay somebody (else) to create it for them.

There was never any usefulness in transmitting us instructions about how to do things we did not intend to do for ourselves.

This is the guiding principle, I think, in trying to explain technical details or operational minutia to clients. If the process is something the client is never going to need to do in operational mode, give them a high-level overview and do the actual work yourself, until you get to final sign-off on the deliverable.

If the process is something the client will need to assume (e.g., scheduling MailChimp campaigns, reading Google Analytics reports), then get your FAQs handy and be prepared to politely decline offers of parcel work to just do it for them -- assuming, of course, you have new clients to chase and are not interested in a maintenance retainer.

Just don't send them instructions on how to do stuff they don't want to do. It tends to make them grumpy.

About

Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRe...

0 comments