Client liaison is a crucial aspect of any web project. For small sites it’s a case of getting an accurate brief, getting concepts approved and signed off, and then the never ending task of chasing the client for content. For bigger projects, especially when there’s a lot of functionality involved, the level of interaction with the client increases exponentially. So important is this task that most teams have a dedicated Account or sometimes Project Manager to handle the task. Fail to listen to the client properly, and, well, fail.
As important as it is to be in regular communication with the client, doing so is also incredibly expensive. Although the project may be number one priority for you and your team, it may be way down on the client’s list – they could be dealing with any number of other projects as well as trying to run their business. Each time you go back for clarification or approval, it might take time to get a response and delay development.
A lot of this can be alleviated by good project management. If every interaction costs the project, then it’s logical to reduce the number of interactions, perhaps attempting to tackle a whole bunch of issues at once rather than flipping back and forth piecemeal. Carefully crafting specification documents at the start of the project is one way to achieve this – possibly the primary method of doing so.
However, I believe there is one skill that should be prized above pretty much all others in the person performing your client liaison. It may sound simple, but it’s this:- having enough knowledge of the practical side of the project to know what information they must extract from the client. (Is that all?!) Take a fictitious example.
We’re halfway through a project and we realise there’s a chunk of content missing – the client need to be contacted to get the content. Here’s how the process goes for Account Manager A:
- Developers request AM gets content from client
- AM phones client and asks for the same; client responds that they have something like that already, and they’ll send it through.
- Client faxes through a page from an old brochure that has some fairly wordy, out-of-context content along the right sort of lines
- AM hands the fax to development
- Development read through it, decide that it’s too wordy and out of context, and errr, it’s fax!
- AM goes back to client and the whole process starts again.
Now, here’s how Account Manager B (with added clue) goes about it.
- Developers request AM gets content from client
- AM phones client and asks for the same; client responds that they have something like that already, and they’ll send it through.
- AM asks where the content was used, and what form it’s in, suggesting that it may need to be reworked a little bit to fit in with the overall tone of the web site. AM suggests client takes some time to look it over and suggests client emails the content through the next morning.
- Client emails content through the next morning. AM proof-reads and then forwards it on to development.
- Development copy & paste the content into the site.
OK, so this sounds pretty obvious, right? Surely no one would hire someone to perform a client liaison job if they didn’t have the amount of clue demonstrated by Account Manager B, right? Well, you’d be surprised. I’ve worked with plenty of them, and it’s amazing what an impact bad client liaison can have on the budget, time scales, team morale and most importantly client satisfaction for any project.
Comments
There are, of course, other factors at play – intelligence, skill, vision (or lack thereof), etc – but meh…
Account Manager A: “But I gave the content to development two weeks ago!”.
The cost of not having a clue is mainly in time, but any team, to work well, has to get on and be able to cooperate. Account Manager A doesn’t usually take long to get on the wrong side of a developer, and that makes work more stressful and often slower. Not good for anyone.
4. Client forgets all about it until reminded at noon the next day by AM B.
5. In a hurry to get to lunch, client skims content briefly, decides it’s ‘good enough’ and faxes it (no time to type before lunch).
6. AM shamefacedly hands content to developer(s)*, who decide(s) that it’s too wordy and out of context, and errr, it’s fax.
7. AM rings up client, who is leaving for holiday and cannot deal with it until (s)he returns. Client helpfully pawns AM off on some Other Individual (OI) in the company whose only experience with computers is watching 2001: A Space Odyssey.
8. OI insists that she cannot possibly email the document, because it only exists on paper. When AM points out that there will be a transcription fee if it is sent in hard copy, OI takes it to the communications/design/tech department, has it scanned and emails a low-res, heavily-artifacted JPEG to AM.
9. MD asks AM what the status is on the project, and makes ominous-sounding reference to AM’s salary and the level of billables completed this month.
10. AM stays late typing up copy.
11. AM browbeats developer into shoehorning the ill-fitting copy onto the site with ominous-sounding references to developer’s salary and the level of billables completed this month.
12. Client returns from holiday, sees ill-fitting copy, rewrites it in toto and sends to AM as ‘a quick change’ along with several ‘graphs about how lovely Ibiza is this time of year and how client ‘hasn’t been sober in a week.’
13. AM requests that developer make changes, but developer reminds AM about other deadline for other client who is spending more money with firm.
14. AM cuts’n’pastes copy into site.
15. Client’s colleague reads copy, mislikes wording and makes several pages of rewrites.
16. Repeat steps 13-14. Twice.
* Actually, at my company I am AM, PM, IA and the primary client-side developer to boot. Theoretically, I have about as much clue as any AM or PM you’re going to find. It doesn’t seem to help all that much.
Not a document telling them “this is what you’re going to do”, but more something along the lines of “We like providing you with the best possible experience, and here’s how you can help us do that:...” Eris has a novel take on it.
Actually, all those problems setmajer accurately stated comes from a lack of awareness from the client.
Many of our client liasons, (as I’m sure yours) are basically admin assistants who have been told “We need our web site updated, so-and-so from x-y-z will be working with you”. Naturally, these people have no idea what goes into a website, and why should they? It’s been thrust upon them. It is the job of the AM or whoever is in contact with the client to try to educate the importance of things like, site purpose, content, and the overall message of the site. These things should be established before any content is written or re-written.
This usually does create quite a delay of deliverables from the client once they “see the forest from the trees”, but in the long run, it decreases (but doesn’t eliminate, unfortunately) the amount of “quick edits” or any other type of “scope creep”.
Knowledge is power my brothers and sisters, and its our job as designers, developers, AMs or whoever to teach.