3

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.

Also related:

Improve this question

3 Answers 3

Reset to default
3

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:

  1. A naturally occurring predecessor / successor relationship of the work packages;
  2. A material and labor resource-induced predecessor / successor relationship of the work packages; and
  3. 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.

Improve this answer
2

High Risk

The first items you want to identify are the High-Risk items.

They could be High-Risk because we have no idea how to do them, or the manpower needed for them is going on leave "soon" or from past experience or it's going to be outsourced or whatever reason it landed up high on your Risk-Assessment.

You want to make sure these are tackled first so that if they fail, they fail soon, and then the project can be canceled / re-budgeted or whatever remedial action is needed.

Length

The next items are the ones that will take a long time. Maybe they need outside input, e.g. graphics that "1,000 people" need to approve.

Third-party

Even if they are not High-Risk, you want to start ASAP on the items that will be outsourced or that you want to buy or use 3rd party elements.

Only once you start dealing with them will you discover how long it will take to integrate them and get them to work the way you want/need them.

This also gives you more time to choose other options, if needed.

Critical Path

Then you can try to identify which items are needed in order to have the basics to start testing.

Certain things can be stubbed out (e.g. return a fixed sensible value) and other elements need to actually work for testing to start.

Those items that can easily be stubbed should be left for last, if they are not on one of the above lists.

Demo version

Often, the customer wants to see progress, or to start data entry, or marketing wants to show something. If you plan carefully you could speed up the delivery of the bare bones needed to deliver a demo or partly working product.

Improve this answer
2
  • 1
    Incidentally, when speaking of "demo versions" I had tremendous success by having teams construct non-functional HTML pages and taking them to the client for review. We showed them what the actual pages for input would be, and what the actual pages of results would look like ... but there was no programming yet. We said, "this is what you're gonna get – all we have yet to do is to make it move." And guess what happened? The client became very engaged, gave very important insights that we'd never heard yet(!), and rewrote our "user stories" in all the RIGHT ways.
    – Mike Robinson
    Commented Apr 30, 2020 at 14:59
  • Lesson learned: "get in front of the actual WORKERS and stay there." Users are not Programmers – they do not think as Programmers do. They're not necessarily very good at "describing what they do" nor "what they need." But you can elicit this additional information – and, as we did, "do it very cheaply." What we said about "making it move" was literally the case: the final HTMLs became the templates. But, had we simply acted on "what we thought the user said," we never would have known "what else he said – when shown a prototype" – and he never would have thought to say it.
    – Mike Robinson
    Commented Apr 30, 2020 at 15:04
2

Also: "get the Stakeholders involved." Probably through the Program Manager. "This is their business that you're writing computer software to support." If you find that you need to prioritize things in ways that might possibly have "stakeholder impact," translate those impacts into stakeholder terms, determine how confident you are or aren't (how likely this is to require stakeholder action or change-of-plans ...), and get input from them.

Everyone fully understands that every business process or function is malleable – no harm, no foul as long as they know first. This isn't just company politics: what you're building will have direct business impact.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.