Overcommunication is a symptom of lack of clarity over power.  If you want better communication, clarify the following:

• Who is the single person who has decision making authority for decision X
• Who should have input into that decision
• Who should be informed when the decision has been made

What Scott’s points address, really, is people’s tendency to defer.  It’s a proven theory that if a person is lying helpless on the street, the more people are present, the fewer are willing to do anything- and so it goes with meetings and projects.  You *have* to do something, it’s your job, so you do- but what people do is the path of least commitment.  They talk about things, rather than make decisions and take action.  The act of clarifying what has to be done and who must do it immediately removes that ambiguity for everyone and gets the team moving.

This leads to how to improve your meetings and projects- always make certain that actions that need to be taken are captured, including decisions to be made.  Make sure that the person responsible for the action is declared.  Doing so is a basic principle in project management, but it often gets lost in the communication aspects.  Calling a meeting to clear a roadblock or make an important decision is not enough; who has authority to solve the problem needs to be decided as well.

Transparency can be a double-edged sword.  There are aspects of any process that may be par for the course, but to an outsider, look like unmanaged, undisciplined chaos.  Watch any of the “reality show” series like Mythbusters or Junkyard Wars, where people build very complex things very quickly, and you’ll see what I mean.  The team that looks under control sometimes is not, and vice versa.

This is particularly true in software development, where developers often debate the hows of solving a problem until just the right detail shows up; where it’s hard to commit to a final deadline or even an order in which you will do things until the last detail shows up, where what appears to be small detail changes to the outsider can lead to huge changes in the software.  A good friend of mine refers to this process as “making the sausage”.  Most people love sausage; if they saw how it was made or what went into it, they wouldn’t be able to eat it.

So if transparency is so dangerous, why is everyone doing it?  Why shouldn’t we run from it?  Why aren’t projects falling apart all over the business world globally because of it?  The truth is that some are.  Like all tools, before you can use Transparency to its fullest potential, you need to understand what it’s for and what you are trying to do with it.  if you use it incorrectly, it will hinder rather than help.

Transparency lends value in two important ways:  it spreads useful information, and it builds trust between groups.  There are two key words there:  useful information, and trust.  These are actually very easy to apply here if you think about it:  information people do not understand is not useful.  People do not trust things that they do not understand.  Also, in the category of trust, no one trusts anything or anyone that surprises them in a negative way.

Drawing from this, we can apply a set of simple do’s and don’t's to Transparency to make it work better:

• Do share anything that is a roadblock.  Never let people get surprised when your team runs into trouble.
• Do summarize wherever possible.  Keep things in terms that all teams understand.  Ditch jargon.
• Do be prepared to explain details, especially related to roadblocks.
• Do be prepared to rate the amount of trouble the roadblock really is- people fear the unknown; quantify it where possible.
• Do not share details for the sake of sharing them, unless you’re specifically having some type of true learning session.  Respect people’s limits in how much data that they can take on a time.  If you bury people in information, they’ll miss the important parts you share.  Make sure the most important details are always at the top.
• Do be prepared for that there will be times that too much detail comes out, and you’ll have to handle it.  A lot of people are problem-solvers in the business world.  That’s what we all do.  If you get too much detail in front of them related to a problem, they will want to dig into it.  This is a delicate balance, because often the time you take explaining what’s going on just contributes to delaying the solution and contributes to your frustration.  On the other hand, not explaining enough frustrates the people you are sharing with- and it can make them feel you’re hiding things from them.  This is one of the slippery slopes of Transparency where you can build stronger trust, or you can do a lot of damage.
• Do not make shared decisions in a vacuum unless you have no choice.  Once you open things up, you hurt trust when you start leaving people out.

There’s a lot of other things to consider, but the bottom line is Transparency is about building Trust.  Follow your instincts around building Trust and respecting people’s time.

Something my company has been struggling with for years has been how much detail is enough for project reporting.  This has been even more complicated by the founding of our PMO.  Here’s a few of the issues you run into when the business folks look too deep into the project details:

• Reporting overhead:  the deeper you look, the more effort is put into telling others what’s going on by the managers who are supposed to be spending time getting things done.  If you pull away too much of their time, the project actually starts to fall behind- because you so busy looking at it that you monitor it to death.  At some point, you have to trust the project workers to handle the details that they gloss over in meetings.
• Knowledge transfer overhead:  this goes in part with reporting overhead.  The deeper a detail you look at, the more explanation goes along with it.  This is especially true in the IT world.  Some tasks and problems require a very in-depth technical knowledge to understand.  The deeper you look into them, the more background information and technical detail that has to go along with it.  All of that communication overhead pulls people away from the real work.  They are talking about doing rather than doing.
• Executive attention syndrome:  if the reporting goes deep enough down the rabbit hole on every project, your company’s leaders soon find themselves spending all their time drinking from the information firehose and not enough time actually leading.

A key task in the critical path of your project is completely out of control.  It’s not getting done, what is done is all wrong, and everything is late.  You go and talk to the person who is in charge of it, and you hear those fateful words, “I didn’t know X, Y, and Z about this project.  When was that said?”  You immediately go back to your desk and add that person to every project meeting to ensure it doesn’t happen again.  In your next project, you vow to not leave anyone off any meetings, because lack of communication causes problems.

Sound familiar?  It’s common in project management- and it’s also the wrong reaction.

How much homework do you do on who should be in each meeting of your project?  I’m going to suggest something that may be sacrilege to many folks:  overcommunication through meetings can damage your project.

Think about it:

• By including people in a given meeting who didn’t need to be there, you are wasting company resources and robbing other projects of available resources.
• By including people in a meeting who doesn’t need to be there, you reduce how engaged that they are in your project.  A few meetings like this, and you will completely loose their attention- which means that they’ll miss details later that you can’t afford them to miss.
• Worse, if they perceive your meetings to waste their time, they will stop coming.
• Even worse than that, their manager might pull *all his resources* out of your meetings rather than waste their time.
• People sitting in the meetings not paying attention will naturally set a bad example to others.  If others in the room are not engaged, your other team members will also become less engaged. 

What can you do to avoid these problems?  Simple:  do your homework before you hold a meeting.  If certain people do not need to be there, be sure to leave them out.  If they missed something that they need to hear, DO NOT tell them through sending out a project status report to the whole team- take the time to send them a note directly.  Trust me, your status report suffers from the same attention problem as your meetings.  Sending a direct note will better draw the team member’s attention.

You give a long report about what’s going on with the project, what the current status looks like, when you expect to deliver.  After you finish, you open the room up to questions.  No one has any.  At all.  After the meeting, you check with the sponsor- it’s an important sponsor – and he says he understands and is impatient for completion of the project.  After engaging him in conversation about the deliverables you are wrapping up, he asks some odd questions, you probe more… and realize he doesn’t understand what you’re about to deliver to him at all.  He’s working off assumptions.

This is (unfortunately) not an uncommon experience in the workplace.  The part of this situation I want to illustrate is how you learned what was truly going on:  by what the person asked.  Most people believe that they understand what’s going on- otherwise, they will voluntarily ask questions.  They don’t dodge asking questions out of any insistence on not knowing what’s going on.  You must seek what they don’t know- what they do ask questions about- if you want to know what they believe is going on.  Seeking inquiries and digging into details with someone will invariably lead you to their view on things.

It’s an old mantra, but it’s true:  Judge people not by what they say, but by what they ask.  Use this to your advantage.  Never be satisfied with just what they say.  Seek their questions.

1. Have an itemized plan of things to accomplish and talk about in the meeting.  Don’t leave without at least talking about each item constructively.
2. Create a parking lot.  Use it.  When things get off track, push things (tactfully) onto the parking lot.  Keep on target.
3. Never end a meeting with hanging tasks.  If tasks or action items come out of your meeting, make certain to review who is responsible for carrying out that task and when it is due.  This is the worst kind of dangling meeting participle- everyone agrees that something must be done, but no one owns the item when they leave, no due date is due, etc, and thus nothing gets done.  The result?  The meeting is a waste.

Follow these simple points, and you’ll never waste another meeting.

Where this led next is the interesting thing- my team assumed that it was a bad thing and started trying to solve the “problem”, not be excited about the opportunity.  At first, I thougth there were some terrible implications of the idea that I had not thought of, and so I started digging in, trying to figure out what the problem was.  All in all, it took us all about ten minutes to arrive at the fact that I trying to communicate something positive to them, not a problem.

So what went wrong here?  Business speak.  Our company has fallen into the trap of trying to be positive about things.  Business people commonly say “opportunity” when they mean problem.  In fact, I’ve heard them correct each other in meetings to intentionally make the substitution.  What effect has this led to?  Has it made problems truly become opportunities?  No.  Has it made people more optimistic and positive?  No.  What it has done is changed the meaning of the word “opportunity” in our lexicon to mean “problem”, which now leaves everyone in our company with the challenge of how to communicate about real opportunity now, because we can’t use that word anymore.

As humorous as this sounds, the problem is real.  When I related this story to a few of my colleagues in management and said “so what do we say when we want to talk about an opportunity now?”, no one had an answer.  We’ve successfully sabotaged our ability to relate important information within our own company.  We probably are not the only ones.  Try relating this anecdote around your own company and see what kind of conversations you end up having about it.

I’ve written before on the dangers of business jargon before.  This is an honest, serious problem creeping into the business world.  The one thing that businesses cannot afford to do poorly is communicate.  Understanding jargon is important.  Don’t propogate its use.

Anyone else have any similar experiences?  Better yet, anyone know a better way to talk about opportunities? :)

As a project manager, you fundamentally have only four resources to manage:  Time, Money, People, and Quality.  Meetings take up both time and money in the form of man-hours, and they also take people off-task to communicate.  In the process they can either build or harm morale.

Wait, did I say four resources?  Project management is a holy trinity!  Why did I put in the fourth?!?  Because people’s attitudes, motivation, and morale are a hidden variable that can stretch the other three resource types, or they can waste them.  It is therefore arguably the most important thing you can manage.

Useful meetings bolster morale.  They give people what information they need, allow them a voice and participation, and make them feel valued.  Non-useful meetings make people sit through other people’s conversations, don’t allow them to participate, fail to communicate information of value to all of the parties involved, and make you look like you’re wasting people’s time.  As a time waster, you lose credibility, damage people’s morale, and lower your value and the value of your project in people’s eyes.

So if meetings are so important, how do you know when and how to hold ‘good’ meetings?  Here’s a general checklist:

• A working meeting, where people are going to participate and make decisions of value, can be no larger than 5-7 people as a general rule.  Three to five people who contribute value is the ideal amount.  Any more than that, and there’s too many ideas at once.  Things will fall into rhetoric, and you will lose more ground than you gain.
• A meeting to present information and ideas can be as large as needed.  These are generally known/held as presentations.  You should follow good presentation guidelines, of course, such as encouraging questions, keeping good flow, keeping the group on task, etc.  If decisions come up to be made, make note, but get the decision-makers together in a sidebar or another meeting.  Don’t waste everyone else’s time making them sit through the decision-making process unless you think that understanding the discussion behind the decision has real value.
• Project status meetings should never be more than 30 minutes.  Ever.  They should cover a status report that has already been distributed.  They should briefly cover the report contents, make sure that the report is correct, that everyone understands it, and to check to see if there’s new action items.  No more, no less.
• The above-mentioned status report should be written from one-on-one or small group meetings.  Get the right one, two, or however many people are needed to cover a small and related section of the report together and hold brief talks to update.  If the update is simple enough, a phone call or an email will do.  On average, I get invited to at least one meeting per week that could have existed as an email.  Don’t do this to people.
• If the meeting doesn’t have value to someone, don’t invite them.  If you need information from them for the meeting, go get the info beforehand. 
• As a corollary to the above rule:  If in the process of getting that information you learn that they do think the meeting has value, invite them.  That person wants to be involved- don’t shun their interest.
• Whenever possible, talk to decision-makers before a big decision-meeting.  Get consensus and share information where possible and take the temperature of who wants what.  If you can get the decision made or close to made before the formal meeting, you will save a lot of time, present a more united leadership front, and gain confidence and morale within the team.

These are just a few important things to think about when handling meetings.  A meeting is a potentially powerful way to communicate- after all, you have everyone together in one place.  At the same time, you are spending resources.  Count up the salaries in the room and you’ll see.  Make sure those resources count!

On the other hand, how many communications and training challenges have you faced? How many meetings have you had with business folks trying to convince them that a fairly simple technical change is not going to go wrong and wreck their business, or worse, if they don’t embrace it, their business will go down the tubes?

Technology is becoming more and more of a commodity every day. If the people that you have on staff can’t do something, you can always find a sea of consultants that can help. Communication, on the other hand, remains an art in the workplace.

I have posted on this before and cannot emphasize this enough- the ability to communicate, influence, develop and use credibility effectively are vital skills and possibly the most vital skills in IT today. Remember this when you choose what skills to work on. Remember it as well when you make your hiring and promotion decisions. How useful is the best technical specialist you know if he can’t communicate what he knows to anyone? What if, worse, he hacks off users with his rudeness and poor attitude? Make your choices carefully, both as a manager and as a techie deciding how to better your career. Your opinions on Microsoft versus linux may be fascinating lunch conversation for your and other techies, but the end users are not interested- they’re interested in doing their job, and you doing yours. Their jobs often involve specialized knowledge that you do not have. Your job is usually to supply specialized knowledge that they do not have. In the long run, you are both commodities to the company. Your communications skills, tact, judgement, reliability, leadership, ability to take ownership of problems and find solutions for them rather than passing them along the chain… these are the things that make a difference. Remember these skills. Develop them. Use them.

Many project managers worry that they are not going far enough with their plan.  The opposite scenario is just as bad.  How can you tell when you’ve gone too far?  Here’s some criteria I suggest:

1) Client Satisfaction:  If the Sponsor, business owner, and other major stakeholders are happy with the results they are getting, but you are not and the processes that you’re using say you’re way off target, this is a warning sign.  There’s times when the project will get off the schedule you set.  There’s times when scope MUST expand in order for the finished product to meet the business’ needs.  There’s times when you’ll be dragged off schedule simply because (gasp) another project is more important to the company than yours, and you have to wait for resources.

If the team, the stakeholders, and the company are satisfied, and you are not, then something’s wrong.  If your PMO’s policies say that the project is at risk, but the everyone else says it’s not, then you need to re-examine your methods and criteria.  Reality is always more correct than policy.

2) Employee Satisfaction:  Do project team members avoid you when you approach, even if they’re not off-schedule?  Are people skipping your meetings whenever possible?  If so, you need to revisit your methods.  Project Management is about, above and beyond all else, communication.  Consider this:  Person A is an incredible communicator and detailed person, but they know nothing of formal PM process.  Person B is a terrible communicator but can quote the PMBOK in their sleep.  If you give each of them a project with a team of ten people, which one stands the better chance of success?

The truth is of course Person A.  Doubt that if you will, but the fact is that projects were accomplished for thousands of years before formal project management began.  The military carried out campaigns of brilliant coordination, timing and logistics without it.  It can be done without any of the tools.  The tools are useful and can make you more accurate, but they’re tools.  The craft itself is still in your organization, leadership and communication.

If people are avoiding you, there’s two possibilities:  either your tools are offending people, or your personal skills are.  You had the skills before you were a PM for someone to recognize your ability to be a PM, right?  I wouldn’t doubt those skills now.  Examine the methods you are using.  Talk to the people avoiding you and ask what they hate about the process.  Work to make the process work without being a burden.

3) Valid Outcomes:  If someone goes ‘off the reservation’, uses methods that were not part of the original project scope, but they achieve effective results that the business approves of and client is satisfied with, is that a problem?  If your methodologies say yes, then you need to consider your methodologies.  After all, you work for the company.  If the company says the new method is okay and so does the client, why don’t you?  What part of your process prevents it?

4) Over-Communication:  Believe it or not, this is possible.  I have been in a situation before, at more than one company no less, where I devoted more of my time per month communicating with the PMO than I did with two-thirds of the departments or people I managed- and in none of those cases were any of the projects I was involved with actually in trouble.  Any time that happens, the PMO is getting in the way of my effectiveness as a manager.    I’m no longer on my department’s payroll; I’m on theirs.  If we communicate that much, I don’t have time to pass on what’s communicated to my own team so that they can act on it.  How is that effective?  The data flow officially stopped at me- the team members below in the organization never got it.  The hyper-communication of the PMO failed because it choked the bottleneck (in this case, me).

Try to keep your communications, follow-ups, and meetings to what is truly needed.  This can be a balancing act at times.  It involves trusting people.  If you don’t, though, you will not only overwork yourself, you will create a self-fulfilling prophesy of failure- by monitoring closely the process too closely, you break the process.

These are examples of just four things that can go wrong if you go too far.  Choosing the right mix may seem like magic or art, but it’s not- it’s science.  All you need is observation skills.  Watch your team members and stakeholders.  Monitor their attitudes and what’s going on.  If people are unhappy, there’s invariably a reason for it.  Don’t drown the process in your attempt to manage it.