Ideally priorities shouldn't change frequently - it's much easier to work in a stable environment and not have to switch between tasks and priorities quickly. The reasons for frequent changes could be:

• Hectic managers and/or stakeholders - they panic and change their mind all the time
• System constraint not defined. If you don't know your slowest/most fragile part of the process - you can mistakenly redirect resources from it. Shortly after that this will slow down the whole system.
• Low quality of the product or environment - something keeps breaking and we keep fixing
• Business model is built around screwing someone over instead of doing a good thing together with them

If one of those is true for you - try to fix it.

But if it's really not fixable, if it's the type of work that you do that's so unpredictable (could you describe it in more details?) then coordinating tasks is a full time job. You probably need a person who's always available, who can always tell to do this task and not the other.

Good question. I'm unclear on some of the details that inspire your question, so I'm going to provide three different answers

Risk Matrices are dangerous to your health.

You say,

I fall back to very crude ways of communicating priorities, by for example saying that a task or a project has "medium" priority.

Tony Cox and others have done some persuasive research that "medium" is a recipe for failure. Brief summary is that "medium" is a term without units, and gets interpreted inconsistently by all parties in the discussion, leading to misunderstanding. Cox et. al. recommend communicating risk through value - $ of dollars or time at stake. You're looking for "this screw costs $0.02, but failure to have this screw in the parts inventory risks a set of delays that will set the project back 3 months and cost $15K +/- 3K."

Risk Breakdown Structure

There are many ways to build a Risk Breakdown Structure; I'll describe briefly one way that I do it in my current work. I use a synthetic number which is derived from the risk and the suspense.

• Risk measures the impact on overall project if the task fails to meet the scheduled deadline. You'll have to do your own risk calibration; mine would be useless to you. You need to set a clear scale from low/"nice to have" to high "life threatening". It isn't completely clear from your example, but I think you're actually working from a value at risk model.

• Suspense date is set for each task, and is the date at which the risk needs to be recalculated. I measure in days because that works for my project.

For every task I calculate the risk/time to suspense. (I actually include the amount of work remaining, but that isn't relevant to the question you ask.) That number tells me what I need to worry about today. I can then break it down to an "Eisenhower matrix" style communication, "This task must complete or update within 10 days and failure will put $x thousand dollars of work at risk. How confident are you that the work will be complete by date Y? What could go wrong? What are the potential blockers and how can I remove them? "

Referencing your cases:

1. (Task must be done before deadline) is Urgent/time sensitive; the risk derives from that deadline
2. (Task ceases to be important after deadline) - Prior to the suspense date the risk (value at risk) is high. After the suspense date drop the value at risk to negligible.
3. (case is unclear) - I think this is resolved by treating the value at risk separate from the time risk. Some tasks are urgent (resolve within 3 days or else abandon), some tasks are important (I have a year to solve this, but if I fail, it will cost a life).
4. (task depends on task that has slipped). I don't deal with a lot of coupled dependencies. If I had this situation, I'd include "downstream risk" in the risk number. I'd add the risk of all dependent tasks to the risk value.

Don't communicate risk; communicate options

In general, I avoid discussing risk. I've found that managers stop listening when I do. What I communicate is options and ownership.

Internally I generate the list of risks, rank order them from highest to lowest. I then establish a cutoff and work the issues that are above that cutoff threshold. What goes to management is a watchlist - an ordered list of worries.

1. Task X depends on a $0.02 screw, but the screw is rare. I've called the supplier and asked them to confirm that the screw will be available, but it would help if you'd call and reinforce the message - let them know that if we don't get that screw on time, it will cost us $15K. Remind them that we're planning on buying $X from them next year, and we'd like a good relationship.

2. Task Y will hit a critical milestone in the next 5 days; if we slip this milestone it is likely that tasks W, K, and L will slip as well. Robin in HR is responsible for the action. Robin says that so long as she can concentrate on task Y, the task will complete on schedule, but Robin needs to concentrate on task Y with no distractions. Can you help assure Robin?

3. Task Z is on my watch list because $20K of other work depends on it. We're going to have to make a decision on how to proceed within the month. Avery says that the decision memo has been sitting on Jordan's desk for 5 days. If that decision memo isn't signed by the 20th, the work will be delayed by a week, and every week will cost 3K. Can you call Jordan and communicate the importance to our project? Jordan's office tells me that the delay is because the decision will impact Charlie's project, so you may wish to discuss it with Charlie first.

And so on - those aren't risks, there are no "mediums" - there are just lists of consequences and options.