Hypothetical situation: You are doing a software/web development project for a client, but you know that you will not be able to make the deadline.
As the deadline approaches, you can clearly see that you will not be able to make it. How do you tell your client this, in a professional way, without upsetting the client too much.
Do you invent technical excuses? Do you be open and honest, and tell them you are late, and don't have an excuse? What has worked for you in the past?
1) Contact them first, and let them know, that way you're seen as proactive and upfront. Rather than trying to hide the fact. Let them know ASAP. That way if they have plans based around the deadline they can re-adjust with less pain.
2) Don't offer an excuse unless asked for one. If asked for one, either tell them the truth, or if you must invent an excuse be sure to PASS IT ALONG to your team. You don't want the client being told a million different things (especially if they're all lies.) And it's better to have one ready if you're going to invent one, it's painfully obvious when someone's making something up on the spot, and it's less likely to make sense to a knowledgeable person.
3) Sincerely apologize about the inconvenience and be as charming as possible.
4) The client is going to react the way he or she will react and there is little to nothing you can do to change it, if the client reacts badly, well, the situation was unavoidable, you were going to be late either way. I'll leave it up to your professional judgment on how to make it right if you want or need to.
This shouldn't be an issue. If you had been doing proper reporting, it should have been obvious early on that slippage was occurring.
The whole point of reporting progress is that issues like this don't come as a surprise.
If it has come as a surprise, that is most definitely a failure on your part (you should know better). In that case, act accordingly. Be honest and be prepared for an upset customer.
I will give one piece of advice that's been invaluable to me. If you come straight out and say you stuffed up, that will disarm all but the most obnoxious client (and you can't disarm those ones anyway so don't worry about it).
It will also be helpful to present some options to the client, such as extending the deadline, dropping functionality to make up time, and so on. That way, you're not seen as a defeatist. Bring them solutions rather than problems.
I answered an earlier question about a failed academic project which may be of some interest to you.
This is not as much about excuses but about real reasons.
Explain the actual reasons why deadline hasn't been met, and provide solution as well. It will make you at least more credible.
Reasons you'll provide may as well be some that were known for a longer time, client may be angry why haven't they been informed of them earlier, so prepare for that as well.
Serious impediments are similar to bugs. The earlier they are discovered, the cheaper (simpler) they are to solve. The longer you linger to explain them, the more complicated it will be for you to stay professional and trustworthy.
Take the client out to lunch and tell him/her then, after a couple of bottles of wine.
First and foremost tell them as soon as possible that you will be late. It is very annoying to a client to think everything is fine until the day of the deadline and then find out there are three more weeks of work left. How could you not know that earlier? This loses client trust faster than anything. Never make the assumption that if I ignore it, the lateness will go away and I won't have to tell the client. Never assume you will be able to throw more people or more overtime hours at it and make up for the lateness and not have to tell the client.
If you are going to be late there are always reasons. Tell them. If it is was process problem on your end, then address how you have fixed that. If it slipped because one of your main programmers got called to jury duty or went on bereavement leave, tell them that. If we ran into an unexpected technical problem that took longer to solve than we expected, then tell them.
If it was because they didn't provide something to you on time. (It's hard to import those million customer records if you don't give us the file until the day the project goes live and then we find out it isn't the structure we thought it would be and the data indicates some things that need to different in the user interface, etc.) Make sure they know that every day they are late is an extra day slippage in the schedule. Do this for any task that slips but be espcially viligant about bringing this up for anything in the critical path. If ten other tasks can't be done until this one is done, then their delay will always affect the end date. If it is something minor and the person can work on something else instead, it may not be necessary to delay the project, but it's good to get them in the habit of seeing that their delays affect the end date. Don't let them get away with providing things late and having it not affect the schedule. Start noting the schedule slippage the first day they miss one of their deadlines. If you are waiting for requirements clarification, slip the schedule. If the requirements change and add more work that was orginally not in the plan (or should I say when the requirements change), then tell them the schedule will either slip by the X hours to do the new task or you will have to eliminate some other task and which ones did you want to eliminate?
Do you invent technical excuses? Do you be open and honest, and tell them you are late, and don't have an excuse? What has worked for you in the past?
Do not invent excuses.
You should be open and honest.
Tell them as soon as you know, and tell them as much as you know about what has slipped and how far.
Collaborate with the client to determine whether a useful partial project can be delivered on the original schedule with a later delivery of the rest, and to build a plan for accomplishing that.
If you've worked on the most important parts of the code first, such a partial delivery may be possible. If you haven't done that, and can't deliver anything, then you should be rethinking your entire process.