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

Project and Operational teams work like this.  I think we’ve all experienced a “bad apple” on a team.  Dealing with the one person who, for whatever reason, is doing a bad job, invariably seems to drag everyone down.  Your best performers will vary as to why they get worse at what they do- resentment over everyone not pulling their own weight, frustration at obvious incompetence, impatience with poor communication skills… the list goes on and on, but it always happens.  Not only does the poor performer not do well, but they drag down the team.

This is not just random observation, although it’s likely many of us have seen it, but it’s shown up in research.  Here’s an interview from This American Life Of Will Felps.  Felps is a researcher and professor at the Rotterdam School of Management.  His experiments with inserting bad apples into work teams showed that not only did bad apples damage work teams, within 45 minutes other team members would begin to take on the characteristics of the bad apple.  Everyone on the team’s work would degrade.

Another effect of a bad apple is that their presence is often seen as a challenge to your leadership.  Your failure to do something about bad performers reduces both the trust and respect of the rest of your team in you.  I’ve heard this said to me and of my colleagues more than once in my career: “If you/mangement/whoever can’t see that (insert bad apple here) is wrecking this project, you/they are an idiot.  If everyone else can see it, why can’t you/them?  If you can, why don’t you fix it?”  Or, here’s the worst one of all:  ”If you/they don’t care that (bad apple) is wrecking the project, then obviously you don’t care.  Why should I?”

I’m not saying can everyone who does a bad job on something, but the one thing you must do is take action quickly. Correct the behavior if you can; if you can’t, get that person off the team they’re screwing up and get them on to something else- either in your company or not, but get them out of there.  Too many times companies sit on their poor performers.  I myself have been guilty of this before.  The instinct is to give people a fair chance, but ‘fair chance’ does not get the job done.  Action does.  Take action to rehabilitate or remove your bad apples.  Don’t drop the performance of your entire team.

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.

In the summer after high school is when I truly became immersed.  I got a summer job before college at my father’s company.  I got first-hand experience with business and all the strange things that seemed to go wrong.  Through conversations with my father, my boss, and other folks, I started piecing together how management really worked.  By this time, Dad was starting to specialize- he was working in Tooling management.  If you don’t know what tooling is, that’s the specialists who build the special tools and fittings and whatnot that factories use to make things.  It’s that special part of manufacturing that fits in the same place that developers do for business.  Every fall and spring I went to college and learned… well, mostly about women, but nearly every summer I went to work in the factories where my father worked and gathered the education that put me where I am today.

I never really realized it until the past few years just how much what I learned from my father really mattered.  So much of what he said and did and taught me applies directly to what I do today.  Even the things he didn’t teach me directly, he still originated.  I still remember the first time I finally cracked open one of Tom Peters’ books.  I picked the book up at a yard sale after remembering having seen it in Dad’s books; I read it on a trip to Seattle, and it changed my worldview.

Today is my father’s birthday.  He’s getting closer and closer to retirement by the year.  Last year was the first year I finally caught up with him careerwise.  My father’s position in his company is on par with mine, but the title is different.  He could have climbed higher if he wanted; Dad stuck with the level he felt was right for him.  If it weren’t for him, I’m sure I would still be learning my way up the ladder at a pace that, with my famed impatience, would probably be hurting my career more than helping.

Over the last year in my new job I’ve had somewhat of a new mentor in my career.  It’s the second mentor in my life, and I am still feeling my way.  I still rely on my first mentor for advice here and there (especially when I need guidance on how to deal with my second mentor).  I find as I get older that I grow impatient and frustrated with Dad’s advice more often somehow, that in what I’ve learned on my own I have more trouble stepping back and looking at it from the right perspective to understand.  Perhaps I grow set in my ways as I grow old.  Still, when I finally can step back and see things without letting emotion get in the way, the advice always seems to fit and help and guide me.

I find myself now quoting my father more and more.  I also find myself starting to mentor others in their careers.  It’s amazing the people who become interested in management and leadership when you put the right guidance in front of them and offer up a bit of responsibility.

My main point here, besides honoring my father’s birthday, is that you should honor your mentors in life, give them credit, and when you are struggling with their advice, be patient, be patient, and think it through one more time.  Pass on the knowledge and, when the time is right, be a mentor to others.  Most but not least, don’t forget to thank them.

Thanks Pop.

1. The company needs more manpower or expertise in some area
2. They have a brilliant idea:  Hire consultants!
3. Consultants come in to help.  Since the company either hasn’t the manpower or expertise to do the project, they hand the consultants what they know and have, which isn’t much.
4. Consultants start trying to do the job right (you hope).  They hold meetings, ask questions, gather requirements, start work…
5. Company loses patience.  Needs product quickly, doesn’t want to spend money.
6. Consultants give up on being allowed to do this right.  They hurry.  Requirements gathering sometimes suffers; writing documentation reduces drastically.
7. Consultants hit company’s deadline (if you’re lucky).  Company asks consultants to turn over documentation and do a knowledge transfer to internal staff.  Company gives consultants a meeting (usually a couple of hours) to transfer everything the company’s needs to know about multi-month project to poor guy who may never have even heard of the consultant’s project.
8. Consultant does so and leaves.  Company struggles to maintain what the consultant has done.  Company swears never to hire consultants again.
9. Six months later, more consultants are engaged to redo what the last consultants did.

Sound familiar?  Some of this may sound extreme (or maybe not extreme enough, depending on your experience).  It happens all the time though.  Consultants are a double-edged sword.

A double-edged sword, though, in the right hands, is a very powerful weapon.  So how do you transition from an accident waiting to happen to a grand swordmaster?

The secret, as with most things in life, is practice and discipline.  Here’s tips for succeeding with Consultants:

Plan ahead:  You should have a plan in place as to what activities you believe the consultants need to do when they arrive and for the early period of the engagement at least.  You should go over this plan with the consultants beforehand and gain buy-in, adjust as needed, etc.  Frankly, if you don’t know what you’re going to do with them before they arrive, you shouldn’t be bringing them in yet.

Share Expectations:  First thing when you bring consultants in, give them a quantifiable, measurable explanation of what you need and what you expect of them.  Leave as few things vague as possible.  This will save time on both sides, as it should answer a lot of their questions, and if they weren’t going to ask questions, it will save you the pain of any incorrect assumptions they might have made.

Set the Standard:  Create a system of standards for the type of work the consultants will be doing- coding standards, database standards, data analysis standards, business analysis standards, etc.  You should already have these in place for your existing staff (and if not, you should really be correcting that).  Give these standards to the consultants when they come in-house as part of your expectations.  Just tell them up front:  “This is the way we do things here.  Consistency is important to us, as it helps us manage things long-term.  We appreciate any improvements you can suggest and will consider adding them to our standards, but we do expect you to follow the standards.”  Your people really will appreciate the consistency later, as it will help make the consultant’s work more familiar right away.

Review, Review, Review:  Conduct very regular reviews- code reviews, if they’re developers, document reviews, whatever is appropriate to the work at hand.  It may seem tedious, but a one hour review every week will help save you weeks of work later.  It will help keep the consultant on track with your expectations, assure they do stay within your standards, and the reviews will help you have a better grasp of what they’ve done later.

Feedback is everything:  Don’t review to grade.  Review to provide feedback.  Your consultants want to do the right work.  Regular checking in and providing constructive feedback will help them go in the right direction- and again, it will help you be more familiar with what they’ve done later, when you have to maintain it yourself.

Participation is encouraged:  Some people don’t like consultants to spend too much time chatting with the existing staff, coming to meetings, etc.  After all, they’re (usually) paid by the hour.  The more you can involve the consultants with your culture, though, and let them participate in informal sharing of information, the more they will learn to help them produce better products for you.  The information that they share in turn will help your staff better maintain their work after they’re gone as well.  There’s also countless little things that your staff can learn from the consultant- a quick infusion of new “tricks of the trade” is always good for the shop.

Do you have other useful tips for managing consultants?  Drop them in the comments!

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!

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.