Use Mutually Understandable Names for Priorities in Project Management Tools
So today I got access to a customer's new JIRA task management system. Unsurprisingly, every task has a field priority, from highest, high, low etc. It's understandable that tasks might be sorted by urgency, to communicate that the most urgent stuff should be done first. But these aren't good names. I have had the following experience at various previous customers:
Fundamentally a task management system is about communication between the team, and to/from management. If I am working alone, I can just use a text file for tasks, I don't need a JIRA. Everyone thinks they know what a high priority task is, but like the fact that we wonder if everyone else sees colors the same way as us, I don't think there's any evidence different people agree on what high means. If you open JIRA and some important things are in normal and other irrelevant stuff is in high, you start to ignore the priority.
I was at one company where there were 2-3 screens of tasks (50+ tasks?) at the highest priority. Any PM knew that to get their new task done, they also needed to create it as highest, so this created positive feedback which exacerbated the problem. If anyone created a task with anything other than highest it would land on page 4 of the task list, so would get completely ignored.
I try to find priorities with objective names, so that different team members can agree on which priority a particular task belongs to.
Having an ordered list of objective priorities allows one to state and discuss the philosophy of the organization, for example are bugs more important than features? Security holes more important than data loss?
Here are the priorities I use, from most urgent to least urgent:
- Security issues on the live system
- Data loss issues on the live system
- Stability issues on the live system (for example the whole system goes down sometimes)
- Bugs on the live system (for example, in a certain situation you get an error)
- Things that have been promised
- Things that are important for the customer
- Bugs, not on any live system
- Most important next steps
- All other things
That is to say, I would prefer to lose the user's data than allow someone else to have access to it. And I would prefer the system to be down, than the user to lose their data. And I would prefer users see an error in a particular situation, than the whole system go down and every user see an error.