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”.

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.

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.

How many of you have heard a developer say this at one point or another:

“Why on earth would they want it to do that?”

Modern requirements gathering has become a very sterile task- identify what must be done.  Don’t get into the weeds.  Describe the problem.  Let the developer solve the problem.  Where this goes astray is that, like the worker on the assembly line who inserts tab A into slot B and passes the item down the line, the developer is simply pulling a lever to make it exactly as described.  They have no idea what the goal is, so they can’t troubleshoot, they can’t add value, they can’t even tell if it does what the user intended- which is often different to what the user said to the business analyst.

A good business analyst can get at what the user’s intentions are.  The problem that I’ve found is that often the business analyst may know what the user’s intentions are, but he has no idea how the existing system is solving the user’s problems.  What the business analyst usually has is how the user thinks the software solves the user’s problems.  There may be large, significant chunks of logic hidden deep in the system that have broad implications, none of which the user or the business analyst is aware of.

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!

Let’s say the business writes up a project proposal. They research their business process, identify key problems with it, define good goals for the project and turn a beautiful proposal over to you. Let’s say they spend a good, solid 6 months putting it together. They’ve done their homework. All you have to do is implement it.

But wait, it’s not that simple, is it? The proposal has to go to IT management (and possibly some sort of advisory committee) for approval. IT has, after all, dozens of projects on its plate, in most companies, and can only do so much. IT probably already has tons of projects started that are ahead of the proposal. Let’s say it takes 2 months to get it sold to management and approved.

Now it needs a budget. You can’t buy hardware and software without a budget, right? This is capital expenditures. It has to go through financial planning. Let’s say it passes their eyes with flying colors, again in only two months. That means that money is approved for it- starting next fiscal year.

Now that the project has a budget, it has to wait for staff to manage it. You can’t start the project without a project team. If you want to do the project effectively and efficiently, you have to take the time to search for and find quality team members. The hiring process of finding quality employees can take months.

Now work can begin, right? Wrong! You have a project proposal in hand, a budget, and staff. You need a project plan, project scope, requirements… you can’t build something corretly until you’ve defined exactly what you’re building.

As you can see, the list goes on and on. The business is impatient for a reason, and it is a good one. They need what they need now. They’ve asked for it, they’ve done their work, and now they’ve nothing to do but wait. And wait. And wait.

The business must recognize though that if they want IT to do a good job, they have to give them the time to do it. In today’s world, you must plan ahead. IT can give a business agility, but only with a lot of planning ahead to be sure the right things are in place at the right time. If you plan perfectly, sometimes you can just hand over a proposal and get a solution immediately, but odds are, it is going to take time.

Even if the solution is coming ‘off the shelf’ from a vendor, there has to be someone in IT who understands and can support the product. There has to be a server for it to go on. That server needs to be built, secured, put into the backup plan, disaster recovery plan… the list goes on and on. Solutions take time if they are to be done well.

You must also remember that it takes time for a good reason. If the business is going to use any tool, it *must* be reliable. There can be no excuses. Any unreliability is cutting into the way business is done. Cutting corners on implementation will always, always cut into reliability sooner or later with software.

The other side of this is that IT has to learn to be more flexible. More and more IT departments nowadays hide behind the project scope and requirements gathered at the beginning of a project instead of being guided by them. Business needs change over time. If they didn’t, IT would not be as valuable to the company as it is.
On the other hand, business changes. If it takes IT a year to get the project going, don’t be shocked if the business’ needs have changed already.

Be ready to adapt to the changing needs of the business, even during the middle of a project. Yes, these changes are expensive. Yes, they are a risk to the project success. Yes, scope creep can keep you from ever getting your project done. Scope creep happens, however, because business changes. If it isn’t changing, then you better be worried about your business, because it isn’t growing and evolving.

The bottom line for IT is this: building software for the business that they don’t need anymore doesn’t do anyone any good. Keep up with changing times and changing business.

The bottom line for business is this: Plan ahead. Don’t expect overnight solutions. Find the best solution to the problem at hand and learn to forecast problems in the future so that you can have what you need in place at the right time.

Here’s some advice: if you don’t know why things are the way they are, ask questions. If you don’t agree with the answers you receive, don’t be afraid to challenge the policy. Challenge it until you either get a good answer or get the changes needed for the business.

The rules that make up your company’s policies were written by and are owned by employees of your company, employees just like you. If confronted with good reasons and solid evidence why the rules should be different than they are, it is very possible that whoever is responsible for making that policy will rewrite and improve it. It’s possible that there may not even be an owner anymore; sometimes “We’ve always done it this way” is a terrible enemy. Even if you don’t get the change you seek, you may get it waived in certain cases where it no longer makes sense and get your work through faster. The change to the rules that you spark may improve the company overall.

What if you find out that the rule had a good point? Did you waste your time bucking against bureaucracy? Not at all. The explanation of the rule will teach you more about the business. It may explain processes in a context that you’ve never considered. They may teach you something about the company and about business that explains why the rules are the way they are. The change in your work as a result of this new understanding will be worth the effort.

Never be afraid to challenge. One way or another, you have everything to gain.

Just as you don’t want a car fixed by a disgruntled mechanic, your customers will not want a product built by disgruntled employees. Unhappy people tend to focus on their unhappiness and fail to focus well on the task at hand. Worse, sometimes they focus their unhappiness on that task, messing it up on purpose. Even when they mean well, they work slowly, and they make mistakes.

What does all this add up to for you as a manager? Morale matters. One of your jobs as a manager is to lead people in performing activities quickly, effectively, and efficiently. Unhappy employees do none of these things. You should take an active role in motivating your team. When problems arise, take an active role in solving them. When an employee is beyond your help, though, you must recognize this and react to it. This may involve shifting responsibilities temporarily, or it may involve taking more permanent action. Either way, morale matters. Raise it when you can, deal with it when you cannot.

1) All leaders in the project give the appearance of being of one mind and that the project is in good hands. This inspires confidence from the team

2) It insures that new issues are held on to until they can be discussed thoroughly, before public dissension is created through knee-jerk responses

3) If other staff in the meeting bring up important info about the decisions you have arrived at previously that should influence your decision, treat it as a new issue. Talk to that staff, gather your facts at that meeting. You can now take that info away, discuss it at length, and revise decisions as needed. You can always release your final decision at the next meeting, again with a united front.

4) All disputes are held behind closed doors with the minimum number of participants.

This may seem like you are leaving a lot of people out of decisions, but remember this: if your project is moving at a realistic pace, you are always making decisions with the minimum amount of people involved. A working meeting is six people or less for a reason. This is the absolute maximum number of people who can hold a reasonably short discussion about anything and reach a firm conclusion. Anything more than that is simply information transfer.