Completing a project requires breaking the project down into work packages and prioritizing the work packages. How do you prioritize work packages? What factors do you consider to prioritize one work package over another? What is the process for analyzing work packages?
What is the framework for prioritizing tasks within a project?
My recollection is that this general question or variations of it have been asked more than once, so I hope that generalizing it will lead to a Q&A that will serve as a reference for the future. Of course I could be wrong......
This is largely inspired by @DavidEspina's answer to a largely unrelated question "Conflict between priorities and skillsets in the backlog in which he outlines a potential framework for prioritizing work. I want to avoid the scrum bias of that question, but I would prefer answers that address skillset challenges. I've recontextualized to work packages to draw a distinction from How to prioritize features; Mr. Espina has an answer there as well, but that question references features in a product, and I'm trying to generalize to work packages/deliverables/tasks within a project. For the purposes of this question consider tasks and work packages synonymous (technically also synonymous with deliverables within this context). While there are distinctions between the terms, the only prudent response to discussion of those distinctions is to retreat rapidly and flee.
How do you track and measure multitasked work and deliverables between different teams - For this question I want to ignore multitasking and team deconfliction.
At what level should the Product Owner prioritize work? - This question is tied to scrum; I'm asking about project/program/portfolio management, not about scrum.
All answers should extend beyond the Eisenhower matrix