Because I get to define what's 'possible', and anything is possible given enough time, management backing, and an unlimited budget.
If I don't have management backing, I will decide on my own how to fit this new ASAP in amongst my other ASAP work and the work that has actual deadlines attached to it.
If this ASAP has a time/money tradeoff, I need management backing to tell me which way to go. And what other work to let sluff in order to get the time needed.
In the end, there are only a few priority levels that people actually use.
- Realtime. I will stand here until I get what I need.
- ASAP.
- On this defined date or condition.
- Whenever you can get to it.
Realtime is a form of ASAP, but it's the kind of ASAP where the requester is highly invested in it and will keep statusing and may throw resources at it in order to get the thingy as soon as actually possible. Think major production outages.
ASAP is really 'as soon as you can get to it, unless I think that's not fast enough.' For sysadmin teams where the load-average is below the number of processors this can work pretty well. For loaded sysadmin teams, the results will not be to the liking of the open-ended deadline requestors.
On this defined date or condition is awesome, as it gives us expectations of delivery and allows us to do queue optimization.
Whenever you can get to it is like nicing a process. It'll be a while, but it'll be gotten to. Eventually.
"ASAP, but no later than [date]" is a much better way of putting it. It gives a hint to the queue optimizer as to where to slot the work amongst everything else.
Thank you.