You're a project manager and set some rules how you expect the project team to behave, e.g. you want summary of the daily work in your inbox at the end of the day from each of project team members.

Now, everyone in the team seems to follow these rules except of one person who is just ignoring them. He also ignores your requests to adjust and escalation to his team manager doesn't seem to work either -- he just take the blame on his chest but nothing changes.

What should PM do in such situation?

UPDATE: As some put the rule I used as an example into question, some more background. The team is spread over a couple of different locations so PM can hardly get all the data by walking around. Daily reporting isn't extensive -- it should take just a couple of minutes at most. Also team members working hours are different and last ones leave the office much later than PM. PM has to report status daily to the customer every morning, as the project is challenged.

Discussed person is working at the same office as PM and leaves at similar time.

Anyway, the rule was only the example and it wasn't really the point of the question. If you don't like it you can pretty much imagine any other rule which is generally accepted by the whole team with the exception of a single person.

  • Even with your update, I think my first answer still stands. 1/ understand, 2/ challenge yourself to come up with a compelling argument for change and bring them on board, 3/ keep track of everything to do with that person. 4/ make sure your grounds are solid (and people above you are aware of and on board with your actions). Only after individual face to face meetings fail to deliver can you build your case, then talk some more with their line-manager or go up a level if you don't get resolution. If this persists and the situation warrants the "serious" tag, it needs to go formal. – asoundmove Apr 19 '11 at 22:12
  • 1
    Why don't you follow the progress via tickets in some ticket system instead of requiring a possibly-humiliating progress report that preys on the mind of each developer throughout the day? – Ricky Clarkson May 15 '11 at 14:26
  • @Pawel: Have you tried any of the proposed solutions? This is really a good question - and it's could be more helpful if we can have feedbacks from life application. – Hoàng Long Jan 8 '12 at 0:07

14 Answers 14

Know the reasons

If someone is absolutely not changing their ways, that person has a reason that justifies their choice of behaviour. Your first port of call is not to judge. Judging will only make matters worse, distance yourself from them and reduce your credibility in their eyes. Do not start thinking that person has a problem, and do not start asking them about any problem they may have - that is almost a sure-fire way of getting nowhere fast.

Find out (genuinely positively) what their reasons are for their choices before you can do anything about them. You must understand before you can act.

They may be good reasons or bad reasons, that is a judgement, but if you actually want to know and reach that person, you must not judge to start with, and you must make sure they think you are genuine when you ask for their reasons. There is plenty of time to judge afterwards. If for any reason you have lost their trust (such as pushing to their manager), then there is very little you can do other than try and regain trust. Anything else will fail. Could be slow.

When you have established the reasons, then you have to respect those reasons and somehow use them to your advantage, if you can. It may be the case that you need to treat this person differently because they are otherwise valuable to the company - despite falling below par in your terms (not in their own of course).

Challenge your own rules

Personally I would never agree again (I have in the recent past) to any daily report of my activities or my team's, unless it can be done in less than five minutes. My personal experience is that any more than five minutes per day on status reporting is a huge waste of anyone's time. Who reads that? What benefits does it bring? What is the associated cost?

So before you dare 'sell' your rules to that person again, challenge yourself one more time. Pick holes in your rules and find suitable arguments to justify their value as objectively as possible, clearly state the benefits and who benefits, and identify the cost each person following those rules must pay. You may (or may not) find that your rules need changing, amending, or some flexibility in some cases.

The likelihood is that the 'recalcitrant' person is quite clever. You must share transparently the whole purpose, benefits (including who benefits) and costs with them so they can come up with their own reason to follow your rules, or, maybe offer you an alternative that could satisfy you both. Maybe you could suggest that they come up with an alternative that could satisfy your requirements, or let them negotiate which ones of your requirements are acceptable to them - if that helps in any way achieve your goals.

Different people have different needs and reactions. Those differences are often for the better. That said, you may also find with this exercise that you can no longer have this person in your team. That is a definite possibility, but without actually knowing why, you'd be setting yourself up for trouble.

Keep a record of discussions

Lastly, if this story looks like it might turn sour - you be the judge - document everything. Make sure you keep a solid history with dates and times of what you say, what you write, verbal and written answers, formal or informal, situations, witnesses, the lot.

This is double edged, but if you do your job the right way around it will serve you in good stead.

Breaking the rules

Some people believe that rules must be broken - they are right, just not all the time. It can be tricky deciding when it is time or not. Of course this is subjective and everyone will see this differently.

It looks to me that you are searching for justification to discipline the person and have already made up your mind.

Honestly, I would question your need to have a written daily progress update. What is it you are trying to accomplish? You are making the assumption that your request is reasonable (possibly) and that everyone who is giving you data is doing so accurately (doubtful). In a case of micromanagement such as this (sorry, that's how I see it with such rigid, arbitrary rules) in an environment where you don't have buy-in because the rules were set top-down by you, some people rebel in inappropriate ways.

Is the developers job to produce work or to produce status? If you don't look to yourself also as a possible cause of this kind of behavior, you're doing everyone involved a disservice. I haven't met a PM yet who didn't think that their requests were reasonable, regardless of how much time it took to comply. I'm sure you have a status report to make, but have you considered other ways of gathering the information? Walking around and asking, for example. If you aren't reporting status every day, why should they? If you are, find a way to get your data that minimizes the efforts others to produce data for you.

  • 1
    +1 - Good point. But I don't think there is anything wrong with daily updates. It's normal for people who work on a project to have to communicate. As much as some people would like to hide from this fact, communication skills are important no matter who you are. However, if the status reports are detailed and still daily, then I second your concerns and think the OP should re-evaluate whether this is really necessary. – jmort253 Apr 19 '11 at 5:20
  • 1
    @jmort253: "communicate" and "daily updates" are two different things. A daily update isn't communication, it's a chore. Instead of requiring a team to send daily reports, talk to them personally. First thing in the morning, walk around and ask how they are doing, or show up to the standups and listen (if they are using scrum) – Bryan Oakley Mar 31 '12 at 15:56
  • I don't think it's unreasonable to ask for a brief update by email. However, I understand where you're coming from and think that the face to face communication should definitely be part of getting updates. – jmort253 Apr 1 '12 at 1:55
  • I think it is BS to ask for daily update by emails. You possibly have other better tasks to do such as actually call the person over the phone / walk to the person and ask. You will get more benefit as a PM> – Hello Universe May 20 '16 at 8:25

I would suggest talking to him individually. I think that it may help figure out what the problem(s) he has are. I would ask if he is having any problems, or if he has a reason for ignoring your requests and the rules put in place. If he has a valid reason, attempt to cope, otherwise, explain that he has to be part of the team, and that his refusal to do such is also a refusal to do his job, and as such, could result in escalation to a higher power (the person that pays him).

It's "Change the person or change the person" situation.

I would fall in like with earlier answers:

  1. Check if your own rules are really that necessary. Are you really sure you need daily report and it should be done manually and in no way you can extract same information from process by-means?
  2. Make sure all in your team talked about your rules and committed to them.
  3. Every being does what he thinks is best for him right at the moment of action. If your team member acts againt rules - there are reasons. Talk about them (in private setup, at least initially). Know them. Act accordingly
  4. If you have no time to solve this situation in a clean way - replace the person. If you can't for whatever reasons (deadlines, special knowledge, etc) - work around him.

Managing extremely distributed software development team, I know such situations very well. In my cases all of them resolved either via:

  1. Action was automated (most frequent)
  2. Person left the team
  3. Person changed behaviour (most rare)

If the person tried to follow the rules and failed, he/she is having a problem : either the rules are not fit with his situation so the process has to be updated, or he is missing something and needs help so he should get training, supervision , support, ... etc till he become on track or may be he is just sloppy person who just keep on missing some details which result that the rules are not applied in the end. In this case you or a reviewer should keep raising the non-compliances he makes and ask him to resolve them till he at the end do it the right way the first time without thinking.

OTOH, if a person never tried so he/she is either not convinced or stubborn. If not convinced then if it's due to prior experience so he may have a point and it may result in process improvements or giving him more information like the first case. If stubborn then you have a people problem more than technical one. According to the personality of this person you should get him/her to try. Tell him/her that he might have a good instinct about this and you might share him the doubts but you need solid evidence to raise to higher level and make enhancements. The problem may not be related to the rules, it might be related to his direct supervisor or senior and the way they communicate so it's good to make both feel important and appreciated and explain the importance that everyone follow the rules and try to solve the communication problem.

The last case is that you are dealing with a lazy person who make up excuses not to do his/her job properly or he is a kind of stubborn that has no point of view at all (I only do it this way and will not do it the other way. That's it) in this case you should express your authority firmly at first and give orders instead of requests making the consequences clear. If still off track, it's time for punishment according to rules defined in the organization. In extreme cases escalation for firing or moving to another team or role may become the best solution.

Finally I want to say all the above actually depends on the kind of rules. If the rule is trivial you may live with it till the employee becomes better and till then make it affect his/her performance evaluation.

If people doesn't follow rules, there can be 2 reasons:

  • They disagree with the rules
  • They have another issue which impact their work, like a lack of motivation

The first possibility should trigger 2 reactions:

  • Question your rule. Is it really useful or is it just a painful loss of time for everybody?
  • If it is useful, you need to convince people it is by explaining the reasons

Unrelated issues leading for example in a lack of motivation must be dealed with properly. I think that's beyond the frame of the question.

If everything else fails, you will have to remove the person from the team and replace him/her.

Unfortunately, I've been in a similar situation several times.

Do a face to face meeting. I understand that you cannot come by and talk to the person, but maybe you can talk to him via phone or video conference. It may work (my girlfriend's boss does it this way, and he is quite successful with it).

The first thing I do that I try to find out the motivation behind the ignorance (prepare with examples, really important). If you can find it, maybe you will understand the person. Even if I got the motivation, I remind the colleague to respect the team and me and follow the rules. Consider this as the first warning.

After the discussion with the "motivation knowledge" in my pocket I try to find a way how to work with him/her, but I always have the team's interest not the person's interest in view.

When nothing changes, then another discussion will come with more examples but with less "democracy". In this case, I make perfectly clear to the person that we really have a problem and the situation needs to be solved. Second warning. In this case I talk to my boss and inform him about the situation, just in case.

At the end comes the third meeting, but this time there are three participants. The person, our boss, and myself. During this meeting the person receives a formal notification about the case and he/she should decide whether he/she would like to work in the current team/workplace otherwise he/she should leave.

I think three notifications are quite fair. I value teams over individuals. If someone is not capable to work with others its better for both of us, when he/she works somewhere else.

Don't waste time and efforts on those who has no respect towards you or towards his/her teammates.

  • +1 that respect and time allocation have to be a two way street -if someone doesn't show you respect or value your time, there's little justification for you to invest in them. – Mark Phillips May 12 '11 at 23:56

Act decisively ... effective PMs don't "shoot from the hip," but they must be "deciders" ... time is of the essence.

You have three choices ... they should be pursued in the following order:

  1. As soon as possible ...convince the person to change behavior OR reach a shared understanding of why change is not going to happen.
  2. Modify the rule in a manner that allows you to achieve true consensus on the rules ... but NEVER "take down a fence until you know why it was put up."
  3. Get rid of the impact of the rule-breaking person ... maybe the person stays on the project or in the organization somewhere else, but in a different role/capacity (e.g. the person is an "adjunct resource" or "consultant" to the project, but not recognized as a full member of the "core team") ... getting rid of the impact is not necessarily getting rid of the person, but that might become an option that someone eventually exercises if the rule-breaking or lack of consideration for others becomes an established pattern.

If your project is important, you do NOT have the choice of being patient, waiting or escalating this through endless bureaucratic wrangling ... situations like this hurt other team members, destroy the morale your project needs, negate chances for success on the entire project.

  • +1 in certain situations "you don't have the choice of being patient." This is particularly true when delivery is critical and higher priority than longer term team development. – Mark Phillips May 12 '11 at 23:55
  • 1
    I don't think those are the only choices. #1 is destined to fail -- you simply can't force programmers to jump through hoops they deem unnecessary. Your job as manager is to remove roadblocks, not put them up. – Bryan Oakley Mar 31 '12 at 16:02

Interesting question. I have a project where the sponsor and I want to have processes in place, we pull the right people together to agree on the process, everyone agrees to use it. Then they ignore it.

I wish it was only one person ;)

I suggest talking to the person, remind them why the process is in place and what happens when people don't use it. Ask what's getting in the way of them doing as other are doing. Then try to come to some kind of accommodation. @Kevdog. There are points in the project where daily - even hourly - check ins become necessary. Usually at key milestones, or post implementation, I need to gather and disseminate up-to-date details on progress.

You're a project manager and set some rules how you expect the project team to behave

The rules are not complete. The rules don't explain what should happen with those who don't do what he/she should do. Get back to the rules definition. Discuss them again with the team, including the "penalization" part. Get everybody's commitments.

As you may see there is a lot of questioning about how resonable your rule is. I am quite sure you considered it twice and that rule is there for some reason, so I will put away that part of the story for now... (by the way nice joke by David Espina :)

First of all, I would do the talking and finding out why is he behaving like this. Then you need to decide if it is the rule you need to change (because it do not fit to reality) or is it a behaviour that needs changing. So maybe it is the second choice, and maybe you did the talking already and did it many times, so it does not work. Sometimes it works when you give him a day off to rethink the situation.

Then I would give him a visible warnings, like two yellow cards in the soccer. Have him do the work which nobody wants to do or (better) a work that is good, needed and valuable but puts him out of his comfort zone. Team should know you don't put maximum punishment on the table at first sign of trouble.

When all the talks, warnings and thinking days are over and you still have the problem it comes to deciding whether you want to work with him or not. Maybe there is a project where drawbacks (as seen in current situation) would became valuable assets?

Well, about that rule again... In agile project I would not want to get status updates by email as well as specifications. If I do not have even a single question about the status report it usually means it is not important to me. And when it comes to questions then it is better to chat about it.

I want to add my humble view about this situation. Like asoundmove's answer implies, I think there is a communication problem.

In my opinion, I think we should

make the information clear

for all the related sides: you and him (and higher management also, but a little later).

First, make sure that the specific person understand WHAT the rule is, WHY you need it accepted, and WHEN, WHERE, HOW you expect it will be performed. This should be an open-talk or a video conference, based on the real condition.

Second, make sure that you understand their REASONS. After you present your view, let him express his motivation. Well, people gather in team so as to complete project goal, but they may also have their own goals.

Third, focus on facts, not the person. I think you may be well-familiared with this, but even the most professional PM sometimes falls on the traps of personal critics.. This can be state simpler: never criticize a person, just get focus on how the problem could be fixed. Here's an example:

  1. Good: I see you don't report daily to me. As a PM, I have the responsibility to guarantee everything go on track. If you don't do this, the result will be...xyz... and the project will be affected. Would you mind explaining to me why?

  2. Bad: You are unreasonable. I requested you follow our team rules, and stop acting like that (focus on person)

  3. Good: I'm worried if we continue like this, it will affect other members.

  4. Bad: I don't agree with your behavior.

I am a big fan of LEAN philosophy. In your special case I beleave, that a daily report from each team member is some kind of micro-management that can and should be avoided. You should trust your team members, that they do their best to get the work done and also show them your respect and your trustfulness.

But of cause, you would like to have a overview over the done work, so here is my suggestion:

  • Your teams should use the same instance of some kind of project management tool (Jira, TFS etc.), where their work and it's state is documented. Software Developers HATE writing anything but the code, but they (normally) LOVE moving features from "in progress" to "done". These tools provide have a dashboard, where you can see a current state of the project whenever you like.
  • Let your team managers do a daily meetings with their team members (max. 15 min) and provide you with daily summary (if needed).

Remove and replace the resource. The damage to the teaming process is unacceptable. The message to the other team resources is compliance is elective, and that is unacceptable. No person is irreplaceable, no matter the skill set with which this resource may present. And the risk you assume by removing this person and replacing with a less competent and capable resource is likely much less than the overt disrespect and sequelae, i.e., risk and issues, cause by keeping him/her on the project.

Update: Clearly my answer is unpopular and I am not understanding why. Many of the other answers are similar. Pawel indicated that he "ignores your requests to adjust and escalation to his team manager doesn't seem to work either...." He then says, "the rules was ONLY THE EXAMPLE", and you can "pretty much imagine any other rule...," which suggests that this guys violates many rules. How long exactly must a PM endure this? How many interventions are required before taking the step of removal? Why is "remove and replace" so unpopular to afford me so many negative points? I am completely at a loss to this. We are project managers. We do temporary work. We do not have the luxury of time to work with a violator who is not responding to interventions. Someone please explain why my answer is so god awful.

  • 1
    -1?? Whoever gave me that score can you provide an explanation? This is a project, not an ongoing operations. It is not the place of a PM to nurture, coach, and coax a resource above a very reasonable amount. I read the OP already talked and escalated this issue to the resource's boss with no result. How much more coddling can the PM do to the detriment of the overall project? – David Espina Apr 19 '11 at 9:09
  • 5
    First I thought it is a joke, but then... your reply appeared. Treating people as "resources" is damaging to "teaming process". Maybe people are repleacable but their experience and work done to teach and coach them isn't. I am sorry to say it, but all the risk I see in such behaviour is risk of becoming an arsehole. – Bartosz Rakowski Apr 19 '11 at 11:53
  • I use "resources" in this forum because that is what they/we are. But treating them as people on the job is very different. A project is a temporary endeavor, not an ongoing concern. You do not have the time, or financial resources, to develop people. The sponsor is NOT interested in paying for people development. You need to develop your team quickly, deliver your scope, and then leave. If someone is not responding to your first and maybe second intervention, you have to cut bait. Else, you are creating more risks. Not a joke. – David Espina Apr 19 '11 at 12:11
  • 4
    Well, things which could happen if you don't treat people well enough: - they will not work with you or your sponsor again, - you and your sponsor will most likely to suffer from black marketing in PR, - they will not deliver as much as they would otherwise - they can introduce intentinal bugs or defects into the product - they can leave you in the middle of the project or even sabotage ... and it can go on and on... I understand rules behind quick, one-time project but if you do not treat people like people you will get the same... – Bartosz Rakowski Apr 19 '11 at 13:00
  • 1
    @David - I think the downvotes may have been because you didn't offer any alternatives like the other answerers did. You just went straight to the gallows. I do agree though that sometimes you do have to remove people. This doesn't mean they are fired from the organization. It just means they are respectfully and promptly moved elsewhere where their skills are more desired/useful. – jmort253 Apr 20 '11 at 5:10

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.