Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

I am currently a Project Manager at web development company working on always more than one project (rarely big project for more than 3 months and most often small project up to 1 month). As we open projects all the time it is essential for my resources to close them quickly, however I have a problem with the clients -- they do not respond and do not provide the required information on time.

My question is how to make them respond quickly and on time so there are no interruptions in the working process?

I've discussed an idea with the director to sign a contract with clause which will make them pay for each delay, however we both agreed that to punish your clients this way will affect the overall client satisfaction (which is very high currently).

I would highly appreciate every idea as I am currently running 14 project and 6 of them are On Hold...

share|improve this question
1  
"running 14 projects" sounds scary.. –  yegor256 May 4 '11 at 18:44
1  
I agree, especially if you have 3 programmers and 1 designer in total. :D –  Doctor Web May 5 '11 at 9:06
add comment

10 Answers 10

up vote 13 down vote accepted

There are two ways I deal with non-response:

  • default position which allow you to continue.
  • meeting with a goal (default position)

This is because there are two main reasons they don't respond.

Fear and lack of understanding.

Fear of commitment or more fear of making the wrong choice ... Especially if their job is hanging in the balance, they will put it off as long as possible... Giving a default which is to continue forces them to focus and move on.

Lack of understanding ... Most people aren't developers, they can't imagine the end result ... So you have to help them through it.

Addition: Default position that allows you to continue

When ever you hand over a "please make a decision" document, you phase it more like:

"Here is the list of options (A, B, C), we are heading down path B, please let us know by Friday if this is incorrect".

You can justify this by saying something like "in order to keep on the critical path we are going to make this assumption ..."

share|improve this answer
    
Hi Rob, Many thanks for the comment - would you please describe more about the "default position which allow you to continue"? The second one is completely clear. I also think that my issue is more like the clients is not interested enough in the project (sometimes the dedicated person is not the owner of the business and is simply fine with whatever/whenever happens with teh project) + the fear part. –  Doctor Web May 4 '11 at 12:58
    
+1, I have actually started taking this approach not so long ago and the differences are noticeable! Taking assumptions and notifying the client with the chance of going back lets them know that you can work on your own, when making good choices they feel confident that you understand their business, and when making wrong choices, they know that you are not sitting still. –  Alpha Nov 20 '11 at 0:36
add comment

Have you thought about rewarding your customers if they provide you with feedback promptly?

I have come across this issue several times with clients where they rush us to complete things and risking the project (specially in B2B projects where our clients are also pushed by a final customer). However when the project or release has been delivered and we request their agreement to sign it off we never hear back... sometimes, after a sensible period of time, we consider this as their approval.

Based on my experience clients, as any other member of a team, need to be motivated to cooperate. It can seem difficult but you as a service provider can offer some discounts or free maintenance services to your clients if they feedback to you within an agreed time.

For following projects think about adding a clause in the contract about feedback reporting including timing and list rewards to the client for their prompt support. Anything related to additional services gets a lot of attention.

Good luck :)

share|improve this answer
    
Hello M0N4K0, thanks for the suggestion. That sounds like a good idea which we discussed, however the issue here is more with the everyday correspondence. I suppose you will agree that small short term projects need more dynamic correspondence and basically my problem is how (on earth :) ) to take the (damn) company logo in high res so we can proceed with the design or the text for teh About Us page. –  Doctor Web May 4 '11 at 12:20
    
This wouldn't work very well with short iterative cycles. Additionally, it wouldn't be a very good business model. You'd be broke before the End of the project. –  chrisjlee Jun 8 '11 at 18:24
add comment

The customer will be unhappy and unsatisfied if the project is late.

You should put a clause in the contract that says that at least states the project WILL be delayed if you do not get timely feedback. Whether you want to put in monetary penalties or not depends on how much the delays are costing you.

Also, make sure to document the delays, how much time they are taking and how far off you ultimately are from your original schedule. These will help you better estimate costs and deadlines for that client on the next project.

share|improve this answer
add comment

Your idea about mentioning such delays in your contract is actually valid. The question is how exactly you can penalize the customer. I would suggest to allow the developer to push back delivery milestones after every delay caused by the client. Don't think that customer satisfaction is high when you always say "yes".

share|improve this answer
add comment

In addition to the already suggested things, have you already tried to give the clients regular updates by a two-way communication medium like short phone conferences? Many clients might appreciate that you take the time to talk and at the same time feel embarrassed when they have to come up with an excuse for the xth time when you ask them once more for the information you need. Usually, people will have a harder time to ignore you on the phone compared to email. Of course you nave to make sure that you provide valuable information to them at every call, otherwise they will cancel the teleconferences.

share|improve this answer
add comment

When you ask "how can I make my client", I believe you're jumping ahead to a presumption of conflict. In many cases, the challenges are symptoms of a very non-conflicted situation.

There are many tools to help dig into the reasons for the lack of communication, but they all start with one key too: meaningful conversations. Having those conversations will likely reveal something that guides the needed response. I strongly suggest avoiding a one-size-fits-all contract-based "solution" to the problem.

Some outcomes I've seen:

  • Client isn't aware of the impacts, helps seek solutions with you
  • Client trusts your decisions, doesn't actually feel the need to be consulted
  • Client truly is busy, willing to abide by your decisions (or finds corrections easier/cheaper)
  • Client isn't empowered to answer and fails to share that while seeking the answer
  • Client isn't individually invested into the effort and is managing on behalf of another
share|improve this answer
add comment

You can lead a horse to water....

Customer performance--including other external stakeholders--is a source of uncertainty for all projects all over the world. Because it is a rather organic project risk, plus a known issue on your projects based on history, you need to build contingencies in your schedule to allow for this threat.

You likely have mechanisms already in place to communicate in a factual--not emotional or punitive--way what is threatening your schedule. Your baseline schedule will expose the variances that can link back to delays in the tasks/milestones owned by your customer. You report this on a set frequency, I assume, so your customer will be told early and frequently that you are predicting a late finish due to missed milestones.

These risks will be further documented in your risk tool, detailing the cause, the likelihood, impact, and what you are trying to do about it. Again, these are reported to the customer.

Finally, I suspect you have in place an escalation process that allows for these issues and risks to climb as high as the governing body. Use it.

The customer will respond when they respond. All you can do is pull the right levers at the right time, using tools you already have at your disposal. While the customer may be upset for missing deadlines, your documentation will mean they need to hold you harmless for it.

share|improve this answer
add comment

I'd start with naming the real problem. Typically it is one of a couple of options:

  • Either late answers disrupt project team work and as a result project ends up later and client complains about that

  • Or late answers does make it way harder to organize development as project team has to be put on hold until questions are answered

If the former is the case you should probably focus on formalizing communication with the client a bit. If you send a question with a deadline for an answer and information that answering about the deadline would inflict a slip on the whole project the least you have is an argument to the discussion about delivery dates, when you're late. If you're lucky people on client's side would consider their options and decide that actually answering you in timely manner can cost them less than delaying decisions.

Another idea is to monitor progress and react when needed - remind them regularly that you're still waiting for answers. Escalate when it is appropriate. People are afraid of escalation and if you use it wisely it would work very well. However, remember not to overuse it.

If the latter is the case I'd rather plan for such situation than attempt to change the client. A few ideas which comes to my mind:

  • Ask earlier, so they have more time to answer. Usually with a bit of better planning on our side we can bring our doubts much earlier.

  • Inform client that if they're late with answers you can assign other tasks to "their" project team and the delivery date can change more than just their delay with the answer.

  • Plan the work in a project team in a way that allows to fill all the gaps inflicted by late answers. If you have to put a project on hold have some tasks in other projects which can be done.

  • Split work into possibly small tasks so you don't leave big unfinished tasks waiting for client's answers but have some small features completed. This way you can find other tasks to work on much easier whenever you have to stop building one of them.

share|improve this answer
add comment

I always add in the Kick off, the Initiation and the Close Down documents a detailed description of the Communication and Reporting format. I state there a Weekly Project Team Meeting with the main developers and the main customers together. The meetings/calls sometimes can last only 15 minutes but I religiously keep them every week because it makes the developers and the customers feeling very close as a team and always updated both sides. You may have already tried it but it certainly works from my experience.

share|improve this answer
add comment

One of the beauties of clients is that they feel the need to tell us how rushed a project is and then the delay happens on their end.

Often when a client hesitates answering our questions, it's because they are concerned about committing to one direction. Their website is VERY important to them and suddenly, when they're in the process and it isn't theoretical anymore, they are nervous about how final their decisions are.

We find that emailing is not good enough. We must phone clients, talk to them, walk them through the decision-making process. Usually then they're OK.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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