We have all had them. The design stage is hassle free and the build goes to plan but the project stalls when it comes to content population. Until the client has prepared and entered content the website cannot go live and therefore cannot be signed off.
The project is out of your hands. It is officially a limbo project.
Limbo projects cost money
Delays cost money
Any small business lives or dies by it’s cash flow. In the web development game profit comes from turning around quality projects quickly and getting paid.
On a recent e-commerce build the client quite casually informed us they were going on holiday and wouldn’t be able to collate and populate the site for 3-4 weeks. The project had only been 3 weeks in the making so the wait essentially doubled the project time.
We had an invoicing schedule in place which broke the payments into 3×33% invoices which helped but we still couldn’t send the final invoice for another month. Given typical agency payment terms the payment might well not hit our account for a further half month.
A designer I work with recently related similar problems with slow site populations which were disrupting his cash flow.
Limbo projects lead to motivation and productivity losses
Aside from the invoicing problem, limbo projects lead to motivational and productivity losses which affect business efficiency and in turn the bottom line.
Productivity – When one project finishes another begins. The limbo project is however not completely finished. A limbo project looms over you, preventing you from fully immersing yourself in the new project. There are usually CMS queries and the odd bug report. After a couple of weeks the project is no longer fresh in your mind making support harder and slower. On top of this context switching to a limbo project distracts you from your latest project.
Psychological – Morale, motivation and inspiration are so important for knowledge workers. A team gets a nice buzz when a project goes live. If a project sits in limbo for a few weeks before going live this buzz disappears. The momentum has been lost and the achievement is soured.
What can be done to prevent and offset limbo projects?
- All content is agreed and signed off before the build starts.The developers can then do the web build, populate the site and go live in a single push.
- Agree to invoice when the web build is finished, rather than on project signoff.The client is responsible for populating the website in their own time. You tend to find that after receiving and paying an invoice the client is pretty swift to populate their site. The site launch is then charged as a separate item.
- Set your client strict deadlines.Typically we are given deadlines by clients e.g. site must be build finished 2 weeks on Friday, but we seldom set deadlines for clients e.g. this content must be here by Wednesday. Building websites is a collaborative process so it only seems fair that each party holds up their end of the agreement.
- Setup an invoicing schedule.A payment schedule is more like ‘Pay as you go’ and it makes the project more agile. The payment intervals and quantities are project dependent. An typical example is 35% deposit, 20% after design sign off, 40% after web build is complete, 5% on project completion. Based on these figures a content population delay can only hold up 5% of the total project cost.
What solution works best?
Each option has it’s pro’s and cons and are suitable for a specific size of project, and client. Whichever route you take it is important to explain the invoicing and client commitments before any work starts.
Number 1 (signing off all content before build) is only going to work on small builds. You really need to be able to see the site in a browser as a whole to balance the copy and imagery. It is very hard to produce content to fit a pdf design. It also will tend not to be suitable for sites with structured data, e.g. a restaurant review website, as the data fields usually evolve and changes during the build process.
Number 3 (agree deadlines with client) is good for large projects but comes with a management overhead making it unsuitable for small projects. Setting deadlines usually forces work to happen but if a client misses a deadline and there is a delay you still have a limbo project on your hands.
I really like the payment schedule outlined in 4 but again this is would be over the top for a small project.
Fo me number 2 (agreeing to invoice upon build completion, rather than launch) seems to be the best solution for a typical build. Taking the site live is considered an additional cost which is paid when the client is ready to take the site live.
