Clients are fibbers.

Hmm. Sorry. Scratch that.

Clients do not understand what they are agreeing to and inadvertently fib to development teams.

Yes. That's better.

To avoid more miscommunication, I will provide further clarification of terms in brackets. After all, this whole article is about the failure of communicating expectations between two parties.

At the start of any project, it is established who on the client's team will be the main contact (read: the one person who is responsible for getting information, documents, files and answers to the development team as needed to meet projected timelines).

This person's availability is vital (read: muy importante) to achieving deliverables by the final release date (read: launching your website on time).

Often, it's the person who will take over as webmaster who gets appointed as the main client contact. This is fine, as long as the webmaster has the authority to make decisions.

The Availability Conversation

In these scripts, DT=Development Team, and CC=Client Contact

Conversation 1: an example of how the conversation usually goes

DT: "What's your availability like?"

CC: "Wide open. I'm completely focused on this project and at your disposal."

DT: "Great."

End scene. That was a nice, simple conversation. The problem is, the concept of being fully available to a development team's questions, requests and review process has not been outlined.

Conversation 2: an example of how this conversation SHOULD have gone

DT: "What's your availability like?"

CC: "Wide open. I'm completely focused on this project and at your disposal."

DT: "Great. So, you're not working on anything else at all?"

CC: "Nope...well, actually, I still have my main duties to perform at work, but I've been told my priority is this website."

DT: "Ok. So if I need you to sign off on a document, you can review it, sign it and send it back before doing other work?"

CC: "Yes. Well, as long as the other work isn't really important."

DT: "That's fine. But I could still get information from you within the hour?"

CC: "Uhhh..."

DT: "By the end of the day?"

CC: "Probably".

That is a very different conversation compared to the first one. It's revealed some possible risks in relation to delivering the project on time. Clients need to understand that when a development team sends information to be agreed or asks a question that needs to be answered, all work on that particular element stops until they get that information. Sometimes, it can bring the whole project to a halt.

Keep in mind, web developers are probably working on more than one project at a time. That means they've set aside a specific amount of hours for you, and another set of hours for someone else. If they don't get the information they need from you in a reasonably quick response, they may have to end work on your project for the day or even the next few days depending on the schedule.

What is the Expectation?

When you agree that you have open availability as the main contact to the development team, this is generally the expectation:

• You can respond to emails and phone calls promptly. Sometimes within an hour or two
• Unless otherwise stated, you are available for meetings as needed
• You can track down and deliver required information for the development team
• Communicating details regarding the website takes priority over other work (barring emergencies)
• You can easily set aside time to review documents, design mockups, and the website as soon as these are ready for you

If you are NOT able to do these things, you need to express the limitations of your availability so it can be planned for. If you don't, and information does not get communicated expeditiously, it will delay your project.