This in and of itself is not a bad thing.  If you can help reduce stress by taking on a little extra escalation during hard times, you should.  The real danger in this is, as you see more escalations, more “negative” things will be flowing to you.  Worse, the same thing will go on with your peers.  If you manage shared resources in the company, such as in IT or Marketing, your names will show up to more and more of your peers- and pretty soon, if the same people are mentioned in the same discussions as problems, a dark cloud can start to form around otherwise perfectly normal activity.  Somehow, with all the increased escalations and contention, things that are actually running just fine may become painted in a bad light.  Just like surrounding yourself with negative people, getting surrounded by negative news has a bad effect.

The answer in times like this is simple:  get out of your office.  Bad news (or bad news-like information) will be flowing to you, and in increased amounts.  Get out of your office and go talk to people.  Pick your busiest people, your most productive people, your most honest clients.  Do reality checks.  Yes, more escalations are flowing to you, but are things actually going wrong?  Are your clients still getting good service?  Other than more busy, are your people really having problems?  If there’s positive out there, go find it.  As people get more and more busy, the positive won’t flow to you.  People will get things done, then  move on quickly to the next thing.  Track it down.  Make sure things are okay.  Encourage the same in your peers.  Don’t let “busier” get confused with “out of control”.

Today we’re here to talk about the anti-communication.  Assumptions.  We all have them.  We all make them.  And they are slowly killing your projects on a daily basis.

Okay, so maybe it’s not that bad.  Assumptions are , however, a significant, real danger that you have to watch in your project.  They are big enough that this topic should come up on every project risk assessment.  There are five major types of assumptions you have to watch for:

• Assumptions of understood information:  not everyone in your project knows all the terminology or has the same background on what you’re doing.  Not everyone will say so, however.  It’s sometimes difficult to speak up when you feel like the only one in the room who doesn’t know something.  Level the playing field whenever possible here.  Open up conversations in project meetings and make sure you get folks on the same page whenever possible.
• Assumptions of understood responsibilities:  not everyone will automatically know what their tasks are, or when to start them.  Make sure you follow up with folks often.  Seek clarity when you do, and if someone doesn’t understand what they need to be doing be active on getting it fixed.
• Assumption of dedication:  your project will not stay at the top of everyone’s priority list.  It just won’t happen.  Something will come up.  Keep an eye on your resources to be aware of if they are on task.
• Assumption of interest:  not everyone will support or want your project, no matter how good of an idea it sounds like.  There’s always some people who don’t like change.  Keep an eye out for these folks and work with them where you can.
• Assumption of correctness:  Projects always begin with the premise that this project is the right thing to do.  Anywhere, any time during your project, it might be discovered that this is not the case.  I can’t tell you how many times I’ve seen a project continue on long after it’s discovered that folks are on the wrong track.  Keep an eye out for validation that you’re doing the right thing.

These sound like common sense, but common sense sometimes gets left on the side of the road as projects gain steam.  Keep your eye on these things in your projects.

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.

Here’s another aspect of Capital we don’t always think about.  Physical assets that are Capital cost maintenance over time.  If you buy an office building, it requires maintenance.  If you buy a car, it requires maintenance.  The bigger the thing, the more maintenance it requires over its lifetime.  This is just as true with software.

The larger and complex a software project is, the more you may have in the following costs:

• Hardware: servers, desktops, network equipment, etc all cost money, must be maintained, and have to be replaced.
• Hosting: Hosting internally means costs within your data center- more servers, more cooling, more power, more floor space, more people.
• Code: Greater the size and complexity of the software, the higher the likelihood that you will have ongoing bugs that need to be fixed.  Also, you will have real costs attached to updating for security fixes, changes to the Operating System, to your web server, to the database, etc.  Also, some types of systems will require constant updates.  This is particularly true for software that emulates business or legal processes and evaluations.
• Training: Every new piece of software requires documentation and training for your users.  Adding features means revising training and updating documentation.
• Liability: Software stores data and has to handle data correctly.  Security flaws, calculation errors, data mis-entry, and more are all real areas where you (or worse, your clients) can end up with the wrong data in hand and making bad decisions as a result or receiving private data they were not meant to see.

These are all real costs you have to consider when building a new piece of software for your company.  Sure, you may be able to justify the build based on saved labor for the business, but what about when you add additional costs for maintaining it?  Does the cost still balance?

Another point to consider is are you staffed (and can you afford to be staffed) to support the product.  If you had to bring in consultants to build the software because your existing staff doesn’t have the bandwidth to build it, then you should tread carefully here.  Make sure to measure that your existing staff has the bandwidth to support the new product after the consultants are gone.

The biggest reason to consider this, though, is to keep yourself in reality.  Two of the biggest and most common problems in companies today are rising IT costs and shortages in IT resources.  Failure to consider, plan for, and allocate for the amount of work necessary to support IT projects after the project itself is completed is one of the biggest culprits that can be blamed for these problems.  Be sure you think through these post-development costs before you engage in new software development initiatives.

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.

You simply cannot manage what you don’t understand, nor can you delegate it or request updates on it.  Understand and manage to results, not to line items on a task list.

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.

What about operations?  How does this fit in?

The reality of most companies is that they do not have seperate project-based resources versus operations-based resources.  Major operational initiatives and problems can derail your project quickly.  An over-abundance of projects can rob Operations so thoroughly that needed maintenance is ignored, and your operations deteriorate (just ask the american government about this).  Major operational problems clash with major project initiatives.  Huge political battles can ensue, creating inaction as people who need to do do the work in question instead go sit in meetings waiting for a decision on which work to do.  People end up making decisions on an island at times, just picking a direction based on their own personal knowledge rather than wait on the corporate machine to find a direction.

Rather than get lost in these situations, get a grip on your Operations.  Include them in the resource planning process.  Most importantly, include them in your prioritization process.  Is the most important project in the company more important than maintenance of the most important existing product?  What about the fifth most important product?  The fifteenth?  Which customers’ business is more important than your projects?  Customer problems can just as easily steal resources.  Not all of your customers will be more important than the development of your company’s future either.  You have to count them as part of your prioritization process, and you have to make hard decisions like this.

Doing this type of process is hard.  It is also vital to your company’s ability to react quickly and decisively to the unexpected.  You, and more importantly, your team, need to understand and agree on what comes first.