Transparency is a grey area. It's going to vary from culture to culture, company to company, project to project and person to person. There's probably some points of information sharing that are very clearly too much or too little, but much of the time, you'll always have to play it by ear and adjust when you get feedback.
Here's some thoughts:
How little is too little?
A must-have is the bare minimal information that lets other stakeholders make decisions with accurate insights. A good litmus test for must-share information is:
- Will it affect cost?
- Will it affect schedule?
- Will it affect quality?
And, as a corallary - even if what's happening on your end won't impact cost, schedule or quality - what decisions the other stakeholder makes in light of information on you end might cause impact.
For example - you make a certain widget. Painting it red, yellow or blue is the same price, regardless - all paint costs the same, all painting time is the same, the paint is the same quality no matter what color. But... you need 6 weeks to buy paint and book a painter. If they change their mind in paint color after you've committed to the plan, it WILL cost extra money to buy more paint and reschedule the painter. Let the other stakeholders know this, preferably before the commitment date. Or, when talk of a new paint color occurs after the commitment date, bring it up.
A big factor in being correctly transparent is judging the technical knowledge of your audience. My paint example is very simple. Get into tech work, and the difference between gibberish and a clearcut communication has a LOT to do with the audience. The project manager probably isn't going to understand your plain as day detailed tech info, and another technician will think that your very light level project-manager-safe summary is beating around the bush and being vague.
Good transparency is clear to the audience, so you may need to adjust to the listener.
How Much is too Much?
More detail - people can only hold so much detail in their heads - if the detail isn't directly relevant to cost/schedule/quality, leave it out. It's very easy to think that a complete list of all information will help the other stakeholder to reach good insights, but quite often 90% of the details will be irrelevant.
When it's technical work, stick to only those aspects where they need the detail to do their part. If more detail is needed, let the listener drive you to it with questions. Being asked a question and answering promptly isn't holding back. In fact, it's a great technique - people learn by asking questions - seeing a stakeholder ask questions means that they are engaged, not that you left something out.
The detail issue becomes even more relevant when it's your personal life. Particularly when communicating outside of your department or team, keep personal details to a minimum. "I'm not available from date X to date Y" is really all you need to say. Sharing of personal details is largely a gesture of personal trust, and doesn't lend a whole lot to the project communication. Generally I find that the easiest trick is to:
Share more of the good stuff - "I'm out for my sister's weddding!" - is great. Everyone wants to say "congrats!" and they all know that 99% of weddings have a very clear start and end date. You won't have "wedding remission", you won't have "wedding delays" - the worst that can happen is a delayed plane flight.
Share less of the bad stuff - your close colleagues may want to know about you or your family's health conditions, home renovation woes, or other hard life issues... but the stake holders outside of your close personal sphere do not. Because of the uncertainty in difficult personal moments, the first questions can become about the project. That's fine, but 9 times out of 10, this is a case where no one will really know. If you have a good team, these issues get resolved between yourself, your manager and your team... and don't need to go to the customer.
- Babies - I'll note that this is a special one. Babies are both an awesome and wonderful thing in a new parent's life, and a health condition requiring multiple doctor's visits, an unschedulable event and a long outage. Pregnant women are usually protected by law, but often it's hard call on when to share. Sooner or later it becomes self-evident, but if you work with folks remotely, no one sounds pregnant on the phone... and for new dads, the physical manifestation is non-existent. Play it by ear is all I can say.
This also fits into any logistics and work provided by your company - any arrangements where your company is covering a cost or a benefit - keep the discussion between yourself and your company. In a multi-company arrangement (like consulting), the other side of the negotiation doesn't (and shouldn't) care what your company is paying for and what they are paying you. The arrangement is for the work, not the person.
Tricks for Information Sharing
Active Listening - your job in working with a stakeholder is to represent the work you are doing without making the other side responsible for all of the details. The key to knowing which detail to divulge is active listening - if you hear of discussions that impact your work - that's the time to speak up!
Know who is responsible for what - the case you mention is a particularly good example. It sounds like - your company was working on a spouse related travel issue connected to a short term project. They are presumably the ones that are paying - for anything related to your travel or your spouse's. Not the external PM. If the external PM isn't responsible for getting you and your spouse to the location, then there's no reason for him to know the logistic details.
Know when cost and schedule are really impacted - if you are looking for every opportunity to communicate, you'll likely err on the side of "too much" - particularly with home/life/work logistics - don't share with external stakeholders until it's quite certain that project deadlines will be impacted. Give your internal group a chance to address it, first.
Email thread scrubbing - companies will vary, but be cognizant of email threads. As new people are included, their perception of the thread can be dramatically different than the original correspondent intended. As a rule, there's a barrier with external stakeholders, where you shouldn't include the full thread unless you mean the other party to read it as an authoritative quote. Instead, reword the content to limit the details to what really impacts the other party. In particularly tense situations, it can be wise to not include new participants in a thread without the explicit permission of the parties already on the thread. This can seem horribly onerous, but it can really help restrict the amount undesirable transparency.
Start slow - people build their perception of your competency over time. Be particularly aware early in any relationship that what you say and do is building a perception. If your first few communications raise concerns about your competency, you set a bad precedent, even if you were just being helpful. Before you share information at the outset of a relationship, think "what is the worst way the other party could take this?" and reduce/edit as appropriate. As you build trust in any relationship, more information may be OK, and you'll learn the most valuable information to share.
