How do you prioritize work packages/deliverables?
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
There is a presumption with projects that all identified work packages, activities, and tasks are necessary and required for the successful completion of the project. Within the context of the project, nothing is deemed elective. There can be some debate, perhaps, that some activities could have been avoided, such as the fifth and sixth coat of paint on the wall, something attached to quality that may or may not be measurable; however, this answer assumes that the method chosen produces value that is both desired and measurable and, therefore, necessary.
I think there are three ways work packages / tasks are prioritized within the context of a project:
- A naturally occurring predecessor / successor relationship of the work packages;
- A material and labor resource-induced predecessor / successor relationship of the work packages; and
- A matter of choice based on logical criteria.
I think these three occur in this order for solutioning the sequence of work by way of precedence. Solve #1, then #2, and then #3.
Number one assumes that task A must be performed and completed before Task B (there could be some leads and lags built in for some tasks in a logical way). For example, you cannot paint a wall until the wall boards are hung. You cannot hang the wall boards until the frame is up.
Number two assumes that task B cannot be completed until task A is complete because of the availability of either materials, tools, and / or labor. Either A or B could have gone first but, once that has been decided, then the other cannot go until the first is finished.
Number three assumes you have no other logical constraint in prioritizing and scheduling the work. I suspect in most cases, choosing one over the other yields no real benefit or penalty; however, in those cases where it might, then prioritizing the tasks using the same scoring method of benefit, penalty, cost, and risk could be used. It is a time consuming and expensive activity so I would reserve it for only those times where I predict problems if I did not choose wisely, typically around stakeholder disagreement.