We all know that in management, the communication with the client (product owner or sponsor) is one of the key factors. It's good when both sides understand the communication aspect. However, from time to time, you have a client that just doesn't pay attention to you emails. In a time and materials model, the team gets frustrated. In a fixed price model, you lose time and money.

I know that Skype would be better than emails; face 2 face meetings would be better than Skype, but my question is about formal agreements.

I'm considering adding a point to my formal agreement that states something like "both sides are obligated to answer emails within one day." Will this make any difference?

5 Answers 5


I don't think a clause like that would be beneficial. It works both ways. You could end up answering e-mails all day long ...

Regarding communication I have used clauses for

  • Change management: how the change process is supposed to run and how many days before the contracting partner should react on them
  • warranty period (more like an SLA for support: resolving of bugs etc.)
  • Scheduled Steering Committee meetings (and how the minutes (incl. status reporting) are distributed): when they are contractually binding it makes sure that they occur regularly and that you have a formal forum to address your (partner-) issues. No excuses like "he's travelling" or "he's on holiday": if that happens, a representative with equal decision authority must attend.
  • Escalation procedure when the SteerCo is unable to come to an agreement: it is something like the final step where the CEO's of both parties try to resolve the issue between them before the Lawyers come in

If you cannot resolve this communication issue directly with the persons concerned, I think you have to address it with your Steering Committee and get it formerly resolved and documented asap. Not discussed; resolved and agreed upon.


I doubt it will work (although I don't have any data points). My gut feeling is that people who wont respond without it, will do the same with such a clause (or, if forced, will not actually pay attention too much). What I usually do is having a sentence indicating that any milestone and delivery date is subject to change if it's blocked by certain artifacts (and communication is part of that) not being made available in a timely manner.

Overall though, those are things you never want to use, but rather keep pushing when you feel the project is going down that road to avoid it. Maybe it's my lack of really bad experience, but I would think if I ever need to call out on things like that, the project has bigger problems than just an email not being answered.

Stephan's comments are really good, I can second to describe a Change Management process (and maybe the escalation stuff can be in a simple process like that).


I disagree with Thomas - communication problems are able to pull the project down very drastically. No solution to this problem can lead to serious delays, caused not only by the time of waiting for a reply. The answer may not be accurate as well, or not everyone got it.

Very often in offers for the customer I include a chapter about communication channels. There are clearly described methods of communication, which will be used during the project, and under what circumstances you should use them. There is no information about response time, but are described procedures about how to change the channel of communication, if given (eg e-mail) starts to be problematic.

Records about the time appear in the maintenance or development agreeament. If the information is incopllete and you sent request to the client, the response time (specified in the contract or SLA) is suspended until the client response to the questions provided. Under this assumption, I have never had a problem with some delay, because date of delivery was dependent on the customer response time.

The contracts often contains information, that when there is no end information about the project (such as end of testing or product acceptance) by the customer, after a certain number of remindes, we can accept them for the customer. Often quoted mobilizes the client to act.

In summary:

  • It's good to create a communication plan (most project management methodologies recommends it). If required you can put there an information about response times. All interested parties should sign below it.

  • If you have SLA, there you can determine response times for both sides, or a statement that the reaction time is dependent on customer response. If the SLA does not exist, such records should be included in a contract.

  • For new orders, or extensions, you can put the information that if there is no response in the context of reception of the work, you can accept work for a customer and demand payment.

All these things you should have on paper, signed by all parties. Then you have something to refer to. If you don't have such rules written anywhere - you can only fight with the customer.


I have never included these topics within a contract/statement of work. However, I do include them in the formal project management plan (and referenced communication plan). This outlines the conduct of the project. I make it standard practice to have sign-off on this document before the conduct of the rest of the project.

  • Hi, can you elaborate on why you don't include these topics? How is this helpful? How is it not? This will greatly improve your answer ;) Good luck!
    – jmort253
    Jul 27, 2012 at 3:24

Within the contract, some of our deliverables will delineate specific requirements related to communication time (i.e. feedback on the prototype will be received within X days, etc.). But it is very specific to the deliverable, and not general in nature.

These requirements are meant to keep the project in motion, and avoid any delays. If we provide a deliverable, and then hear back several weeks later that something is wrong, then our staff have already moved on to something else and may not have bandwidth to re-engage.

  • Hi Kevin, can you tell us why you do this? Just telling us you do it doesn't help us decide if it's the best course of action to take.
    – jmort253
    Jul 27, 2012 at 3:28
  • these requirements are meant to keep the project in motion, and avoid any delays. If we provide a deliverable, and then hear back several weeks later that something is wrong, then our staff have already moved on to something else and may not have bandwidth to re-engage.
    – Kevin
    Nov 27, 2012 at 13:41
  • Hi @Kevin, I added your clarification to your answer. Thanks for explaining, this makes sense. :)
    – jmort253
    Nov 28, 2012 at 2:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.