Prioritization: How do I know if I should do it based on time to completion or difficulty?

Question

One of the key problems I face when it comes to project management is determining when I should prioritize based on time or difficulty.

Thus far, I have no method of determining something like this; for the most part, I end up just doing it based on difficulty but I would like to employ a more rigorous method that is backed by some research and logic.

My question:

When do I prioritize based on time to complete a task or the difficulty of the task?

Thanks!

P.S. What are some other ways of thinking about this? I understand that there are other variables at play i.e. deadline, impact of the task etc.

Answer 1

The Scaled Agile Framework uses an equation named Weighted Shortest Job First (WSJF) for prioritization. It's applicable to any set of initiatives, regardless of development methodology.

Briefly, you'll be comparing the projects you're ranking by business value, time sensitivity, investment value (risk reduction or opportunity enablers), and the size of the job (or difficulty).

If you add up the first 3 and divide the total by the last one, that will give you a priority score. The higher the score, the higher the priority.

The logic is that high-profit, time-sensitive, or strategic investment jobs are great, but may take a back seat to quick wins if the effort is too significant.

As for the scoring, it's all relative. A good approach to start off is to take an obvious low or high-scoring item in a category, and give it a 1 or 21. Then, everything else is a question of "is this more or less valuable/time-critical/etc." As time passes and new projects are introduced, you can adjust and re-rank as needed.

http://scaledagileframework.com/wsjf/

Answer 2

Prioritize against all criteria, not just one criterion. A common prioritization model I have used is to compare value against cost and risk. You can further decompose each of these three to a lower level if you desire. Score each criterion and then take the ratio of value over cost + risk.

You can add a weight to each criterion, as well, if desired. So if, for a particular project, time is critical, then you can put a higher weight on the time criterion over the others. If cost is critical on another project, then weight it higher.

Here's an example scoring sheet that I have used:

If you are facilitating this with others, I would hide the results, the priority column, so that will not influence the scoring for someone's pet project. You can also add scoring rules to help approach true objectivity; for example, with cost, you may indicate that a project that costs below $500K scores 3; projects that cost below $1M score 5; on and on. Try to create as many scoring rules as you can but some criteria will need to be approached more subjectively.

Answer 3

Ask Senior Management

At work, one should generally prioritize deliverables based on business value. How the business assigns that value to each deliverable will vary widely, and there's no canonical answer. Sometimes speed or cycle time is more important; sometimes a specific feature or earned value matters more.

It is always the responsibility of senior management to define business value. While this responsibility can be delegated to a Product Owner, portfolio manager, program manager, steering committee, project manager, or some other group or individual, assigning value doesn't happen in a vacuum. The framework for determining business value must be defined at the top, so any questions you have about how to define business value within your current organization should be referred up the chain of authority.

Answer 4

Prioritize to manage project risk.

You mentioned time and difficulty, but another key consideration is risk.

• A task whose requirements or scope are not well understood is riskier than a task that is well defined and a variant on work the team has done before.

• A task that requires the use of new technology is riskier than a task that can be built on existing foundations.

• A task that is critical to the success of the project carries greater risk than a task the project could succeed without.
• A task which, when complete, would surface potential problems elsewhere in the project which are unlikely to be identified by other means is riskier than one which does not. This last is one reason the agile methodologies often recommend vertical slices through an application: as soon as you give your users/testers/project owners actual working code that they can play with, they can discover that they didn't get the requirements right.

"Difficulty" captures some of this -- a complex task is riskier than a simple task -- but not all of it.

Prioritize risky tasks, because if they're going to fail, you want them to fail early: in the case of a recoverable failure, so that you have more time to recover; and in the case of a catastrophic failure, so that your sunk costs are minimized.