Who’s really on the team II – who’s actually saying “no” by saying “yes?”

In my previous post (Who's really on the team...? (Introduction)) I pointed out that it’s sometimes hard for a project manager to know who is really supportive of a project’s goals and timelines and who isn’t. In other words, who is in reality saying “no” by saying “yes?”

While this can honestly be about as easy as “sorting fly poop out of black pepper,” it is critically important that a project manager go into the project looking for these folks. Not trying to advocate being pessimistic or paranoid, but if one or more of these kinds of people are involved in your project, it’s at risk. Plain and simple.

So…. How to figure out who these folks might be? Start with those who will be most affected by the change. Case in point; I was once a training manager for an FAA Part 135 air carrier. That’s more or less an airline - the big differences being the class of equipment (i.e., business jets and turboprop twins instead of 777s or Airbus 380s) and lack of a set schedule of routes and times. It was, as the industry terms it, “an on-demand charter operation.”

Most of our pilots were not employees of our charter company. Instead they were employed by someone who owned the business jet that used it in conjunction with their business most of the time but allowed it and their pilots to fly it for our charter company part time. The idea here was the owner got some extra revenue from his airplane through charter to help offset their cost of ownership.

Unfortunately, I saw way more instances than I really care to remember where our salesperson would take the owner and pilots out for a big expensive meal to help woo them into joining our charter ticket. As the wine flowed and the conversation centered around all the wonderful revenues said owner would receive from all these extra charter trips they could fly with their airplane (and their pilots) over and above their normal business trips.

Invariably the owner and his crews would all be saying “Yes, yes, yes. We can do this! Sign us up!” 

By now you’re probably already guessing the end of the story. The level of participation agreed to by these pilots sometimes didn’t live up to that promised.

Why? Picture this; you’re this owner’s pilots. You’ve just flown into home base from a long 4-day, 3-night trip. You’re looking forward to a little relaxation and time with the family. You haven’t been in the same state as your own home 6 hours and you get called from the charter company wanting you to head back out for another long charter trip – for which you’ll receive no extra pay. And this is the 4^th such call you’ve gotten this month. How motivated are you to accept the trip?

So, in this scenario, all these pilots got from their boss enthusiastically adding their aircraft to our charter certificate was what amounted to an extra part-time-plus job…for no money. Is it hard to believe that – despite their enthusiastic support of his signing the charter contract during the wine and steaks dinner - they’d turn down charter trips whenever possible.

Therefore, always keep your eyes open for the reasons why those “on the team” wouldn’t really want to support the team. Maybe it's job insecurity, maybe it's loss of status. Or maybe they just think the project will bring them more hassle. Whatever their objections might be, if possible, remove those objections for the health of the project.

Who's really on the team...? (Introduction)

Have you ever been told to execute on a project wherein the kick-off meeting all parties were smiling, nodding their heads and voicing their enthusiasm about the project? Have you then later experienced some of these same seemingly enthusiastic and approving people seem to be doing everything they can to not support the effort?

Surprisingly, this is not all that uncommon an experience in project management. Hence, it’s critical for any project manager – official or otherwise – to identify who the real supporters are in a project. And, conversely, have contingency plans for working around those who aren’t – regardless of what they may say.

Case in point; a recent project I participated in required the input of a given person. My client – the project’s champion - required me to route any and all things through this one person and kept me dependent on them for any information, materials, access to expertise and so on.  

During the initial consultation with all parties, this person made several statements expressing agreement with the need for this project, the need for an outside consultant to come in (nobody internal had enough time to devote to the project so it would complete) and so on.  However, when it came down to it, despite multiple requests from me, this person gave me next to nothing in any of these areas. And the project stalled as a result. So, was this person truly as “on board” with the project goals as they had seemed to be? Or, is the reality the person is a project saboteur (unintentionally or perhaps otherwise)?

This person is an example of the kinds of barriers to progress that project managers need to identify and quickly so to keep a project moving towards completion. And have a counter to, but that’s a subject for another blog.

It's a training issue! Or...is it really?

As a trainer as well as an instructional designer, I’ve often been brought in on a preliminary training

development project and told “You need to retrain/develop a training program that will solve X problem.”

Let me say right off the bat that because a course sponsor or champion is so hard over that they want a training solution, sometimes trainers/IDs are given marching orders to do something and maybe even in a certain way and all they can do is salute smartly and get to work. But, if there’s any room at all to explore the issue, I’d advocate that perhaps some further information is needed before deciding just what the solution is to X problem.

For example, I would start off evaluating if X issue is a performance problem or not. Certainly if it’s a knowledge problem or skills problem, then, sure; a training solution is likely an effective solution. But what if it’s deeper than that?

Let’s explore a scenario that will illustrate this;

Joe has the highest scrap rate of anyone in the shop. I’d suggest the exploration begin with the “5 Whys.” Hypothetically, let’s explore the Joe scenario with these

a.      The first one is the most obvious, but also the main objective; “Why does he have the highest scrap rate?” Maybe he’s new to the skill and still coming down “the learning curve” to the point that he doesn’t waste so much material. If that’s not it – or you sense that’s not the whole root cause – then ask another why – based on your findings, course.

b.      Second, begin drilling down by asking perhaps “Why is Joe’s output levels the lowest of anyone in that shop?”

c.      Come to find out, he’s also got the most machine maintenance requests of the team. And “Why might that be?”

d.      Apparently his machine needs recalibrated at least twice a shift. “Why?”

e.      Because his machine slips out of tolerance so frequently and easily, you discover. “Why might that be? Because his machine is the oldest, the highest operational time (in other words the most worn out) machine on the floor.

Do you think that any of this could perhaps be contributing to the symptom of the problem of highest scrap rate? Right there, you’ve uncovered at least a major contributor to the scrap rate. Certainly a simple knowledge or skills retraining solution isn’t going to solve Joe’s “worn out machine” problem and hence, not the scrap rate problem either.

You get the idea here. Keep asking why’s – each based on the last findings – until you uncover the root cause. Once you know the root cause, then you can begin crafting a truly effective solution. Otherwise, automatically jumping to the conclusion that someone just needs more training and then things will improve is wasteful of time, resources, morale and personnel.

In the end, you’re best off exploring with the course champion right at the get go if this performance “problem” is really a training issue or not. If it is, great! Create the best one possible and implement it - using best practices, of course. If it isn’t then drill down until you find what the root cause is and then move to address that.

Or, you’ll likely wish you had…. Just sayin’….