Writer's block - handling clients who struggle with their content
A few months ago, I penned overcoming the dreaded 'content block', which was an acknowledgement of the many occasions where I've seen web projects held up for launch, simply due to the lack of content. Generally, this is due to an inability of the client to either find the time to write it, or more likely, that they are daunted by the task and thus begins a lengthy routine of procrastination, often leading to an inability to focus and indecision on where to begin. It is a frustrating position for both the client and agency, and one that an experienced web producer / project will try to head off by incorporating content provision milestones and risks into their project plan at the earliest possible moment.
WRITER'S BLOCK: A condition, primarily associated with writing, in which an author loses the ability to produce new work or experiences a creative slowdown.
I don't feel the need to repeat the lessons of my previous blog, read it in your own time. The purpose of the former article was to give thought to ways of assisting the client in creating their content, including:
- New ways to look at content creation
- The theory of progressive disclosure
- Benefits of having a sitemap
- Telling a story
- Bringing in the cavalry - i.e. hiring a copy writer
Assuming the client is motivated (has the time and inclination, and/or budget to hire a copy writer) then everything should be hunky dory. But what if - despite all efforts - there is simply no content forthcoming and the project continues to drag out? What do you do when despite regular contact, and the best of intentions, the client still doesn't provide the final pieces to complete the jigsaw puzzle that is their new website?
The Web Producers' dilemma
As the project manager, it's no fun having a fully designed and developed website - i.e. technically and functionally ready for launch - when it's still full of gaping holes where content is supposed to be. I don't know about you, but at Wiliam we work on the basis that we get paid when there is clear evidence of client satisfaction (preferably written). And in my experience, despite what any contract says, a client is not likely to pay a cent towards the final billing milestone, if their site is not launched. And if it's not launched, then normally it's due to a level of dissatisfaction with the final product.
It's all good and well to say "job's done, here are the keys to the content management system (CMS), all yours..." but the reality is unless you're particularly well organised and open with your client about delivery expectations, you're not going to get paid until the site is live. And even if you are lucky enough to have a water-tight agreement (or a trusting client!) and you end up being paid upon completion of development... it's almost a foregone conclusion that you'll end up being dragged back in for more work, just when you think everything is done and dusted. For starters, there will be questions around how to use the CMS, because no matter how much 'training' you give the web manager, it's not until they actually start using the system that they are actually paying attention, trying to accomplish things 'for real'. Next there will be tickets raised in order to resolve further QA issues (of course, these are issues that only surfaced once content population commenced). Or worse... there are the requests for 'fixes' which are actually scope creep. It always happens when you give the client the opportunity to think about their site for too long. Get it closed, signed off, and the sooner you do this, the easier it is to push any scope creep and additional work into a new phase or release, covered neatly by a new quotation / cost estimate.
Never try to cheat your way out, leaving the client to 'finish the job' of content population, in their own time, with free reign of the CMS
Mark my word, these scenarios are all too likely to happen. Never try to cheat your way out, leaving the client to 'finish the job' of content population, in their own time, with free reign of the CMS. You should NEVER consider a project complete until the site is launched. Billing upfront provides a false sense of satisfaction that a job is delivered and that the client is satisfied. Do you really want to be paid, and then have to deal with more tidy-up crap and loose ends? Many producers - including myself - have been there, and all it does is three things:
- Makes you feel like you're now working for free, which is a psychological barrier.
- Strains the relationship between you and the client, as they feel that the job was never delivered properly in the first place.
- Gets in the way of your actual 'paid' work - i.e. other billable projects you'd rather be working on.
Plus, at the end of the day, projects that fail to close are costing you (or your business) money. I want to ram this point home, because it's important to realise this, and unfortunately not enough people take the time to properly realise the financial implications of a project that drags out, whether that be because of a lack of content, or other issues that ultimately contribute to an inability to launch and close.
I could go into MUCH more detail about direct versus indirect costs, and how they can be subjecting you a great deal of lost profitability. However, there's another entire blog article to be written about that subject (for another day!). For now, let's settle on the fact that it's definitely in your best interests to close a project ASAP, to avoid the above issues, and to ultimately keep your job profitable - on paper, as well as in terms of the 'real' cost of doing business.
OK, I get it... so what about my missing content?
So you've helped your client along the way as much as possible, sharing insights and ideas and thoughts on structure and form. You've pointed them in the direction of a good copy-writer and forced them into their services. Development is complete, and you still have no content. You've prodded, poked, harassed, tried incentives and bribes and you've stretched emotionally from angry frustration to forlorn hopelessness. You should be a little angry, to be fair. This is a team effort, and one side is letting the team down.
Now its time to get real, and never let this happen again. What you need is a good, proactive game plan that can be deployed in advance of future projects to head off this situation in the first place. You also need some hard ball strategies to deal with any legacy situations. Closure of your job can't - and shouldn't - be held to ransom, just because a client is not interested in closing quickly, or is too disorganised or unable to supply effective content.
Some of the ideas below are a little more confrontational than others, and you need to be able to have earnest discussion and negotiation with your client. You may not like - or need - each and every approach, but how far you need to go will vary depending on the status of each job, and how desperate you are to receive that elusive content.
You want to get paid, right?
Set expectations early
Your client probably had every intention of getting you content in good time, but may have underestimated the size of the task. This is a very common problem, and you need to be pro-active on this front, because if you're not thinking ahead about content provision, and the amount of work required, then there's a good chance that your client isn't either. As an experienced web producer, you are probably in a better position than most to give an understanding of the effort that will be required to write the content, given the size of the project at hand. Guide accordingly.
Expectations for content delivery should also be set as close to the start of the project as possible. For good reason too, as many designers - both UX and creative - will be thrilled to have actual (draft, if not final) copy to work with. It can make a huge difference to the design of a website, when you have discussions around the type (media), volume and purpose of content during the design phase. The end result will be a website that incorporates content much more appropriately than anything designed with placeholder (e.g. Lorem Ipsum) text, or temporary imagery that was ripped off some stock library, watermarks and all. Thus it makes no sense to starve the designers of content, if that is something you can potentially have the client accelerate. It would have to be better to at least aim for this, and then miss, knowing that know (at least) there's a higher chance of content being ready before completion of development.
Given the advantages of having copy early in the design phase, it makes no sense that we regularly still see situations where content is an after thought, relegated to the back of a project plan. Content provision is probably the largest single task that a client needs to complete, and you need to give them as much time as possible. Waiting until the end to raise this important task is a sure-fire way to derail your project.
Track, tie and manage content delivery
In saying this, just because you have raised the topic of content early on, doesn't mean the client will move on it quickly. I've seen projects where copy was discussed early in the design stages, a copywriter was consulted and the pretence of content provision was under way. Yet STILL, the copy wasn't ready - nearly twelve months later - when development was complete! Not even a single page was ready or signed off. The client was very busy, understood the importance of copy but wanted to own it, effectively micro-manage it. Eventually they saw the light and handed full control of copy over to the copywriter but this was something they should have done months earlier. It was a classic situation whereby the client figured 'final and approved' content wasn't important until development work was complete, and this attitude (by the client) led to the project team literally twiddling their thumbs for months, not able to sign-off, not able to launch the site, and not able to bill the project. Uagh...
In this case, could we have done more? Absolutely, and there are still things we can do (we'll get to that). A better project plan would have tracked the client's content delivery alongside the agencies' deliverables (UX, design, slicing and development) and therefore held the client more accountable. Setting specific content delivery milestones is the only real way to do this, and you MUST hold clients accountable. This is because content delivery is often seen as non-critical to holding up a project, at least in the early stages. Unlike prototype or visual design feedback, which is absolutely necessary before a project can continue to the next phase, content delivery is often not tied to anything. And this way of thinking is the biggest mistake people normally make, because it consistently leaves you with no dependencies on content apart from 'launch'.
Ask for your content up-front, at least in draft form. Argue that this is essential to ensure the designs are relevant to the content, and if you can, tie early milestones to content delivery. Design is hard, arguably some clients can't visualise the content requirements until they see something out of design first. If this is the case, perhaps tie content to slicing? Your ability to do this will depend on the client and the project, but it's definitely worth trying.
Set a payment deadline
A slightly different, and arguably more hardcore approach than setting a 'content delivery' deadline, is to instead set payment deadlines. Now, payments should realistically be tied to successful delivery of milestones, this can't be disputed. However, towards the end of the project it's not uncommon for an agency to hold out invoice - or the client to withhold the final payment - until the project is live. Understandable, as clients always feel more in control of the situation when there is still money owed to the supplier. It's like holding out that final carrot to complete the work to satisfaction. But what if it's the client who is dragging out closureof the job? This is where the idea of a payment deadline comes into play.
The most common 'best practice' method is to ensure that your final billing milestone is always set to 'completion of development' and not to launch (or 'go-live') of the site. Personally, I don't think this always gets you out of the woods, because you can still end up in the same situation as I described above, where you have in theory been paid for the work, but just handed over the keys to the CMS and left yourself open to be required for further contributions with no further billing opportunities available. A false sense of completion and bad economy.
A more rigid approach (the opposite end of the spectrum) would be to write extra stipulations into the contract. There have been instances where agencies or contractors have clauses which state, "if a project stalls for a period of 'X' weeks due to client delays, the contract expires and must be re-issued before re-commencement of any further work. In addition, the client owes all outstanding money, due with immediate effect." Now, this is probably a bit too extreme for most, but for contractors who are exceptionally busy, problems like these can lead to huge losses of income when added up over time. It's not in the contractor's interests to put up with clients who don't take their project seriously, when they are knocking back other work.
Somewhere in the middle might be more reasonable ground, where an 'unresponsive' clause can be enacted, which gives you a legal right to bill for all works completed to date, if the client goes MIA, is too busy to deal with you, or whatever the case may be for their disappearing act. Setting a period for unresponsiveness (say, 4-6 weeks?) is good practise, as after all, web designers need to eat too, and it's scary when you know you haven't been paid for work because the client isn't keeping their end of the bargain. A clause like this could easily be invoked in a situation where a lack of content is holding up the launch of the project.
The best part of having some control over a client - forcing their hand to pay their bill - is that nobody likes having paid in full for something, yet not getting the benefit from it. So imagine a client sitting there, knowing full well they have paid 100% of the costs of their website, yet not getting any benefit from it? That's more likely than not to motivate them to get their act together. And if it doesn't? Next tactic...
Implement a fee system
This is the next logical step, whereby you are stating to the client that if they fail to provide reasonable and approved content for their site within the set schedule, then they may face additional financial penalties. Now, I'm not talking about unjust fees (like the silly charge for using a foreign ATM, which is a completely unnecessary money grab). I'm talking about setting legitimate fees to cover the costs of pausing and/or interrupting a project, which can be related and justified to the client. Fees which are entirely avoidable if they play nice.
The most obvious is a 'late fee'. Not everyone's cup of tea, as this can sour relations with a good client, and really, really shit off a bad client. And if applied, it needs to be done with rationale and reason. A client may have a very good reason for delays in providing content, things outside their control. Asking for such an allowance in a contract also has the potential to raise the ire of a new client before they've even signed on the dotted line, and it may cost you work if the client doesn't agree that they could be charged for their own tardiness.
A better way forward might be to raise the fee as a 'switching fee' or a 'suspension fee'. This operates in the sense that where the client has delayed delivery of content (or other collateral / assets) required for the continuation of any given project, then after X days where no further progress can be made, the agency or contractor is entitled to 'suspend' the project. It's only fair that if there are other projects to go on with, we can't expect billable resources to twiddle their thumbs waiting for the client. Now the catch here is that it's widely recognised that one of the biggest gripes of developers - and a significant contributor to loss of productivity - is project switching. Every time you need to move projects, you need to re-open the appropriate files, re-familiarise yourself with correspondence and project status, check recent emails and - if it's been a particularly long break - possibly even re-acquaint yourself with your own work or go over conversations already had, because nobody remembers what was discussed all those weeks/months ago.
This second approach to fees is likely to be much more easily justified, and it sounds fairer. A client will understand if you take the approach that for every pause in the project, there are switching and setup fees to account for, which are avoided during a continuous run of work. This doesn't have to be a large fee - charge a few hours work, a nominal fee only. It's the principle of the thing that will hopefully spur the client into action, to avoid paying it. And if they do, at least they will recognise the inconvenience they have caused you through paying the switching fee.
Sell the content - ensure it is not undervalued!
The final point is nothing controversial. Ensure the client knows the value of good content!
Communication is the very reason websites exist. As such, I find it phenomenal that a client is willing to spend up big on the design and technology, yet does not seek to invest in their content with the same enthusiasm. I'll go further and put it out there, that many companies probably spend more money (or are more willing to spend money) on services such as SEO, SEM, analytics, cart abandonment, user testing and the like... with much more gusto than they do with their spending on content.
I've seen clients flinch at the thought of paying money to generate good content, as if it was a given that they would write it themselves and wouldn't see it any other way! This is a problem when the client thinks that nobody understands their business better than themselves. This can be far from ideal, as the client is often too close to the business and gets caught up and lost as to where to begin, or just ends up writing reams and reams of copy - way too much information for display on a website. In actual fat somebody who is distanced from the business can often be the perfect person to write the content, and this needs to be explained to the client.
Emphasising the size of the task ahead will often see a client come around, and humour (agree to) the idea of hiring a copywriter. After all, isn't their time better spent running their business and serving their own customers or clients? Remind them also, that just because they may be able to write well, doesn't mean they are good at 'writing for the web'. That is nearly an art upon itself.
Finally, I would avoid using dummy text also for the reason that it shows the client that we don't necessarily value the content above the visual design and layout of the site. When this can't be further from the truth. As previously mentioned, content is key to creating better, more marketable designs. We want to come up with designs that suit the content, rather than having to create content to fit the designs. Incorporating Lorem Ipsum into the designs does not give off the right impression and does nothing to encourage the client to progress content, if they are not already inclined to. Even copy written by the designers, or the project manager, or even the cleaner for that matter (!) will be better to inspire and encourage the client to pull their finger out.
Good luck, and hopefully between encouragement, helpfulness, better management and ruthless incentive, we can work towards shifting the client's understanding of content, and their ability to provide it in a timely manner, for the better!
