Individuals in team keep ignoring my advice

Question

Running a team where I am asking individuals to update/move their JIRA tickets, one keeps saying he will do it but never does. This is becoming very frustrating since I have a lack of visibility of his work.

How can I get him to do this?

Answer 1

Perhaps the first question to ask is, "Why is he resistant to doing it?"

I might actually ask that question of him, one on one. "I've noticed that I keep asking you to update your tickets, but it keeps not getting done. What's up with that? Is it something I can help with?"

I think it is always important to presume good will when first addressing something like this. It might be something simple like not having a system to get it done, and you could help suggest things like "always do it at this stage", "put up a sticky note to remind you", "make it the last thing you do before lunch & before leaving", stuff like that.

If the answer is more along the lines of "it's stupid and a waste of time", I would go with the transparency approach: "I can't do my job effectively if you don't do this part of your job. Part of my job is to be aware of the status of the work, so that I can communicate accurately to our stakeholders and make them aware of any issues, so that they continue to trust our team. It's good for all of us when our stakeholders trust us, because that builds up a balance of good will that will help us out when there are problems - it means they are more likely to give us the benefit of the doubt and work with us."

I might also present an alternative: I rely on devs updating tickets as they do the work because that's the least labor-intensive way for me to get the info. If you'd rather write me a daily report with a status update, I suppose we could do that...

Answer 2

I agree that it's likely the developer does not see you as an authority figure. However, while appealing to authority could probably get the job done, I don't think argumentum ad verecundiam is really the best approach to use, here.

It is plausible that the developer simply doesn't understand nor care about why you need him to update his JIRA issues. About why you need visibility into his work.

So, instead of just going "Please update your JIRA issues", consider bringing the following, either to the developer in question (making it an issue for him to solve), or to the Team in general (making it a general issue that needs to be solved). "The business needs me to do X. In order to do X, I need visibility into your work. The best way I can think of is for you to manually update your JIRA issues whenever you Y. However, if [you have/anyone has] any other suggestions, I'm happy to hear them. How can we meet this business need?"

Who knows? You might just be surprised with a better solution. Maybe (for example) there is (or could be designed) a JIRA plugin that automatically moves JIRA issues when Y happens.

Even if you don't receive a better suggestion, if you make an effort to have the developer involved in the process, you should see improved buy-in.

Answer 3

Two options to offer:

• Option 1 (Escalation): Our policy with JIRA is this, "If it's not in the ticket, it didn't happen". Add a comment indicating that this ticket needs to be moved if ready for the next steps/done. Escalate to the functional/direct manager if this has not happened after 3-4 requests via the comments, just so it's clear that you've done your part.

• Option 2 (Transparency): As a PM, you must have some reporting or communication statuses to send to your business/management team, no? In my case, my status reports tend to include work that was done. Make it clear to your team that their involvement within JIRA is vital to successful reporting of work done to date, i.e. increase the level of transparency.

In my case, this communication to update tickets hasn't been necessary as the team is included in my weekly reports, so they have full visibility into the overall progress of a delivery initiative.

It's been my experience that when you're transparent with the team about business operations, you'll find the level of cooperation that much higher.

These options are not mutually exclusive, so use these suggestions based on your needs.

Answer 4

This is related to PM of course, specifically to Human Resource Management. First question you should answer to yourself is what kind your organization's structure is (Functional?, Projectized? or Matrix?), and then, what's your power's level?.

After that, you can:

-Escalate the issue to the functional manager.

-Escalate the issue to the project manager.

-Escalate the issue to the project sponsor (last resort).

If you are the PM use the following powers:

Formal (Legitimate): Lead (persuade) the goals you want to achieve, use your soft skills (ask to an expert how to handle this if you aren't ready).

Reward: Giving rewards (this time won't be helpful).

Penalty (Coercive): Penalize team members, period. (you should try to avoid this).

Expert: Are you an technical or project management expert? Again, use your soft skills.

Referent: Use your charisma and fame (or someone's else).

However, if people don't respect you, think about why is this happening.

Answer 5

What level of authority do you have over your employees? Are they matrixed to you in a dotted line but have another boss somewhere in the organization? Or do they report to you directly? Do you have sponsorship in your organization to apply consequences? Whatever the answers are to these questions, it appears your project team does not perceive you as an authoritative figure, either via as a named leader or one that is a perceived leader.

You have to find ways to grow the trust and respect of your team and to manage and lead them in a very positive way. However, you also have to identify the point when you need to turn the machine off, remove the offending cog, replace it with a shiny new one, and turn the machine back on. If you do not have the authority to do that, then get it...or you are not really "running the team."

Interesting you used the word "advice." If you are a native English speaker in the US, that word signals something in your management approach.