[davismwfl]

I generally try to make it relatable to them. I have yet to find any other industry that doesn't have similarities where things go wrong no matter how well the plan was at the start. The way I found was best is to ask a lot of questions up front about their industry and typical delays, "issues that comes up etc before anything has even happened. Then when the nearly inevitable delay and inevitable bug comes up it is easier to explain it to them.

In the event you didn't do this up front and don't know their industry well enough, you can use common analogies of building a house, and the delays and cost overruns that are so typical there. Many times caused by clients wanting changes or items which were not spec'ed correctly up front etc.

In the end I have always found it is best to not get defensive, and not be dismissal like this is just normal, but to explain that there are a lot of challenges to engineering anything, whether it is a website or a PCB. Also know your audience. Some people want all the details and that makes them feel better that they understand. Others just want the new date and a reason why it is more solid than the last, or want to know you are handling the bug and it'll be complete by X. Don't try to explain details to the person who just wants to know when it will be fixed, and don't try to dismiss the person who wants to try and understand the details.

One other example I have used for people that are less technical, I will ask them if they ever wrote a multipage term paper or something to the sort in school (everyone has usually). And I'll ask, did you ever make a grammar mistake? How about a spelling error? Ok, now imagine that paper isn't 10 pages long (~600 lines) but instead 100 or 1000 pages long, what do you think the chances are we will find some mistakes when we start proof reading it? What about after we have proof read it 10 times? Do you think there still might be some issues 5 days later when someone else has read it? Usually this helps people.