How do you handle difficult team members?

I determine the size of the defect by working with the developer to get a ballpark idea of how long it will take him to fix it. The answer is always going to be a guess since, in my industry, IT, you never know exactly how long it will take to fix a defect until you're in there.

As for how I can help the developer, sometimes, I do have additional resources added to the project. Maybe there are some smaller, simpler fixes that someone else can work on. We can also work as a team to prioritize the open defects. We can talk to the customers to determine if there are any defects that can be fixed after deployment, for example. And finally, I can find ways to minimize distractions. I can talk to the developer's supervisor and get him excused from non-critical meetings. If he's working on other projects besides mine, perhaps I can de-prioritize those other projects.

Don't know if you will find this helpful but here is my experience.

I have had many "difficult" team members but the worst was a gentleman that was both lazy and a pathological lair. Since I had moved up the organization I had a lot of the same skills that he had so I was really good at knowing when he was blowing smoke. I find the best way of coping in this type of situation is to stay alert and educated at least on a basic level on what tasks the individual is delivering. Sometimes I find people will actually be testing your knowledge either to see what they can get away with or they feel they don't have to respond because they do not value the PM role. I know this is not optimum and I was lucky to have the technical experience to be able to call him out on his lies but I learned on that project to at least have base understanding on the vocabulary needed to discuss their portion of the project. Often I find if they think you know and value what they are doing they snap in line.

Some other tactics I use are to have project management meetings with difficult projects on Thursdays. I send out the project status on Wednesday and have an early Thursday call. Then on the folks that are off target I discuss what is in jeopardy. I ask them what portion they can accomplish by Monday and note their response. On Friday I reach out and ask how the activities are moving along. I have found often if they know I am going to be checking and rechecking it is easier for them to stay on track than deal with me, I always find people always take the easiest route. So, make staying on tasks the easiest route.

Thank you Betsy.

The reason I asked was because I also worked as a developer on bug fixing and estimating the time needed to fix the defect in most cases was not possible. Apparently you already know this. :P

Because of the above you can't really tell a developer that he is behind schedule on his defect fixing since you can't accurately estimate the time needed to fix the defects and more importantly you can't predict how many defects are going to be reported by the testers/users.

When a developer is struggling to find the problem for a defect and someone else keeps asking him why he hasn't finished yet then such a developer may turn into a so called difficult team member. The developer may think that there is no point to keep reporting the progress since he hasn't managed to fix the bug yet. When he fixes the defect(s) he will report this. Also you don't feel to well when you have to report that there was no progress.

If there are too many defects and they can't be handled by the project or maintenance/support team then you should adjust the dead-lines or add more people to help. Aggressively asking for status report doesn't help too much.

In my experience, one of the biggest reasons people inaccurately report their status is because they think they need to tell me what I want to hear and that they can't just be honest and say they're behind.

There are two ways to address is. One is that I work to create an honest and transparent environment, that gives my team members the comfort level to tell me, "No, I can't make that deadline."

The other is that I don't rely on that team member's word for it. For example, if I need to evaluate how a developer is doing in getting his defects completed, I don't just ask him how it's going. I look at how many defects are open, their size, and the amount of time we have left. Then I can talk to him and say, "It looks like we're behind schedule. Is that right, and how can I help you get back on track?"

In my experience, one of the biggest reasons people inaccurately report their status is because they think they need to tell me what I want to hear and that they can't just be honest and say they're behind.

There are two ways to address is. One is that I work to create an honest and transparent environment, that gives my team members the comfort level to tell me, "No, I can't make that deadline."

The other is that I don't rely on that team member's word for it. For example, if I need to evaluate how a developer is doing in getting his defects completed, I don't just ask him how it's going. I look at how many defects are open, their size, and the amount of time we have left. Then I can talk to him and say, "It looks like we're behind schedule. Is that right, and how can I help you get back on track?"

Great suggestions! I have also noticed that the more you know about the technical area you are managing, the easier it is to call out someone when they are giving you the run around. I have had similar encounters. What I love about your suggestion is the comment: "I always find people always take the easiest route. So, make staying on tasks the easiest route." I really like that, which is one of the reasons why I like using Statdash. It makes it easy for them to update their status and keep me informed without me having to confront them. I think it might be worth using especially in situations where people are intentionally making it difficult.

I've been reading through all these comments and have a few things to add based on what has been said. First, we need to be careful about blaming the project manager when a team member doesn't cooperate. Sometimes people have their own agenda and are not in line with project goals. Sometimes there are personality conflicts. That isn't necessarily anyone's fault, but it is not a good mix and you may need to remove the person from the team. Second, I think it might be helpful to use a tool such as Statdash to handle the communication end of asking team members the status of their tasks. This takes the "emotion" out of the asking and keeps the PM from having to nag people for an update. Since Statdash automates the requests, it can act as a buffer between the pm and the difficult team member. And, because everyone can see the status of the project, it will be plain to everyone which person is not reporting their information correctly. This doesn't remove the necessity of one-on-one communication, but it can be a great tool to remove some of the stressful interactions with difficult people.

Hi Adrian,
Thank you for your thoughts on my comments, as a mid-level manager, it is not hard to do my job but it becomes next to impossible when the folks who bring me on-board decides to start playing games. I choose to be a contractor so that when I see situations like this, i bid everyone adieu and move on to a new project.

To my knowledge, there isn't a profession where someone is being paid to be difficult, why do we tolerate it?

My understanding is that in a projectized environment, the PM is at the top of the food chain subject to senior or executive management. Why should anyone on the project proof difficult? It shouldn't be allowed and the reason this exists is that most people think PMs are oafs that should be grateful for their positions.

We need to start redefining what Project Management stands for. I choose to not work with senior /executive management team who will not back me up if my team is proving difficult especially when I remain professional, personable and polite. I have a job to do, it is to get a project off the ground and close it. I have to work with different people but they are part of the structure to get the project complete.

To quote you Adrian, "This is a delicate situation and the PMs skills must come to play. You have to be able to get the information you need without irritating the team members. The best way to do this is to establish very good (friendly) relationships with them"

The fact you assume a PM isn't establishing good relationship with the team is not the right way to approach dealing with difficult team members.

There is nothing delicate about Project Management, this isn't brain surgery. From construction to IT, projects are not new, the scope may be different and the end product. I don't see why anyone shouldn't do their part. If they have issues doing it, inform the PM so they can find a solution. It may mean escalating issues to get approval from the management team but under no circumstance is it ok for anyone to be difficult. It is unacceptable behavior and very unprofessional in the workplace.

Errant children shouldn't be rewarded. Anyone who is less than professional, polite and personal on the project team including the PM shouldn't be rewarded. They need to be removed for promoting bad work environment. PMs are not victims.

I choose to work only with ardent professionals who take what they do seriously and are always working to a positive end.

Hi Edward,

I think I didn't express myself properly, I didn't assume the PM is not establishing good relationship (although this can be true too) what I wanted to say is that the PM must be able to work with difficult people and try to adapt to their ways of working rather then trying to change them. This is true especially for project managers that are contractors. As a matter of fact this is true for all contractors either project managers or not.

From a technical point of view project management may not be too complicated but dealing with difficult people may be complicated and hard.

I've worked a lot as a contractor in IT (not project management) and I have seen that people in organizations establish relationships between them and some of these relations can be complicated and the workers working for these organizations can be difficult to work with. It is extremely important to adapt to the organization's work behavior and people relationships otherwise you are not going to go far no matter how good you are at what you are doing. If you can't take it any longer then the only thing you can do is to leave.

Regarding projectized organizations I don't think they exist in reality since companies in order to deliver projects also require strong functional departments and the experts in a certain function need to stay together and cooperate even when they are working on different projects. A projectized organization could exist only when all the employees are contractors but this means that they also belong to a functional department on their home company.