Foundations of managing "highest priority" tasks in multi-projects

Question

Despite all the Agile approaches which become hard to follow in a multi-project context all for themselves following Agile, depending on culture but also real life project situation, I observe over years that if there are racing conditions in context of understaffing or unexpected troubles, be it due to internal or external dependencies, the result is, plannability and reliability of delivery declines.

Sometimes, when it is about prioritization, it's some "priority one" task. Then there are many "priority one" tasks.

Therefore my question is:

• How to properly* disambiguate how much resources "priority one" shall consume? 80%? 100%? Moreover, does "priority one" mean, "we should stop all other tasks"?

• How to properly* disambiguate how to split time between multiple highest priorities?

* Properly should mean here not "what is your opinion" but "do you know a source where this problem is described and assessed" either "have you experienced and addressed this problem"?

Answer 1

The foundation for managing "highest priority" work in multi-projects is actually order, not priority.

There is a saying that goes "When everything is urgent, nothing is". On the same train of thought, when everything is "priority one", nothing is.

What you need, is someone with decision power that can create that order for you. Be that a product owner, a program manager, or whatever, someone with enough visibility of the big picture and authority to sort all of the work in your pipeline. If you don't have this, then it's just a sign of lazy management deferring how the work gets done to the people doing it (people which most of the times don't even have visibility over the big picture or authority to decide on what work to place their efforts).

If your work is ordered, it then becomes a matter of picking up what's first in the list. You pull an item/feature/task and you work on it at full capacity. It the product owner/program manager's job to make sure you get to work on the right priorities. If something more important comes up, it's placed first in the pipeline or it gets to replace what you are currently working on. The things you were working on then go back in the pipeline, and it's again the product owner/program manager's job to place it at the correct position within the pipeline.

Answer 2

You don't say what kind of work this is but I'm going to assume these are software development projects you are talking about. Some of what I say may not be relevant to other kinds of project.

Firstly, do not assign priorities based on tasks within projects. Prioritisation ought to be assigned to features and deliverables, not tasks. Similarly, prioritisation should sit within Products or Value Streams, not projects. Put the product first, never the project, and align your teams to each product so that they can focus on the priorities for each product stream. Juggling project-based priorities is just likely to end up satisfying nobody.

Now once you have properly engaged product ownership - a owner/sponsor for each product or value stream - your problem becomes much more manageable. All resources should be working 100% on the top priority items in each work stream. If there are too many priority items to fit within work-in-progress limits or iteration velocity (or whatever metrics you use) then the product owner gets to decide which items to do first. Prioritisation really just means "ordering" but that ought to be driven by business priorities not by which project bagged the development resources first.

Answer 3

Caveat: I don't feel like I have sufficient grasp of the situation to offer what I would call a good answer; I'll provide the following partial answer in the hope of clarifying the gap.

be it due to internal or external dependencies, the result is, plannability and reliability of delivery declines.

If the goal is reliability of delivery, then quantify the priority based on the impact of the deliverable on reliable delivery.

• Critical path is the primary tool here - critical path gives you a way to quantify the impact of any task/deliverable on project closure. Actions or interventions that affect the critical path should have a higher priority than those that are further from the critical path. It may be necessary to calculate multiple alternate critical paths based on alternate assumptions, but this bridge over into the next item. On the other hand, you imply that this is an agile environment, where critical path is difficult to calculate; the theory still applies - which of these actions/interventions is most likely to affect, or has the greatest effect on delivery of the sprint goal.

• Risk Management - Estimate the probability and impact of each intervention, and work those with the highest consequence first. Most of the time you'll be operating in an environment of unknown unknowns, which means you'll need to estimate and you'll need to document your assumptions and treat them as risks. That may lead you to consider multiple risk scenarios. If your situation is complex enough, you may wish to explore something like FAIR (you may need to adapt slightly from information risk to project risk, but the model is flexible enough to permit that). That permits you to predict the net impact of multiple sets of assumptions on your sprint goal.

• This is a change management problem - when contemplating any change, work with relevant stakeholders (inside or outside of a CCB) to analyze the potential impact of the change, and set the priority of each task/action based on the effect it has on the sprint goal/project closure.

Hope that helps in some way.