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.

Here’s a great commentary on how things are done today and a little what if thrown in…

What if the stop sign were designed today?

Enjoy!

A risk to the company and stakeholders of every major project is how to exit out of the project in the event that it fails.  This risk seldom makes it into project plans, though, because all of the project manager’s tasks are typically related to identifying and reconciling risks that might cause the project to end- in other words, to preventing an exit strategy from ever being used.  So where does this fall?

I recommend that this should be worked into any PMO’s processes.  The inability to gracefully shut down one project when it needs to be shut down is a huge risk to your overall portfolio and to the company itself.  Most of the time, the plan may be very simple, but working with your sponsor and stakeholders to identify how to recognize when the project needs to be shut down and what the process is very sensible, holistic risk avoidance for all involved.

PMing on the cheap: TaskBin free online project management

PMS Relief: Guerilla Tactics for Project Management

Is Consulting for You?

Four Things You Can Do to Hire Better and Head Off Resource Issues Early

How not to use Powerpoint