Image showing what to do when you have too many projects to manage
January 17, 2018

Too Many Projects? 2 Simple Steps to Prioritizing Projects

Project Management
Agile

Many project managers are faced with a common problem: We have more projects to work on than time in the day. What should you and your team tackle next? In this blog, you’ll learn two formulas that help with sequencing projects (WSJF) and allocating resources to them. Used in tandem, they can help organize project chaos.

Someone I recently met at a professional event — let’s call him “Steve” — told me he works with project and portfolio management in the IT department of a major financial company.

Steve has a problem.

His department has 200% of the work they can do.

Here’s why: In his company, the business groups have funding for IT development that is about twice of what the total capacity for what IT development actually is. Further, the IT budget is capped at the current level, so it’s not possible to balance this demand through grow in the IT.

Aside from project management difficulties, this imbalance can create animosity between the two departments. Business groups will feel that IT is a bottleneck — that they can’t get anything done, that someone else’s project is always prioritized, that they take too long to do even small things, and so on.

The IT department will feel that the business is unreasonable — that they don’t understand they ask for impossible things, that there already is a long queue of planned projects, that the funding for IT doesn’t match up.

Steve is not alone.

It doesn’t take a wild imagination to know that there are a lot of frustrated people around the world staring into the same dark and difficult situation. Many of us face similar problems, if perhaps not on a smaller scale (in Steve’s case, the budget is many hundreds of million dollars). During our discussion, Steve also mentioned he had so many different stakeholders to satisfy, and that it would be impossible to get them to agree on overall priority. Steve sounded very tired. I thought about this in the days that followed, and landed on a solution to this problem. Let me outline this for you.

How to Prioritize Projects in 2 Steps

1. Sequence Using Weighted Shortest Job First (WSJF)

Let’s assume the business side is made up of a number of business groups, each owning a budget for IT investments. What they’re probably doing is using a fixed-priority method for arranging their backlog of projects. Projects are ordered by high, medium, low, etc. But, from Steve’s perspective in IT, all of the projects coming in from these groups are high priority. So, priority doesn’t help the team pick the most valuable project for the organization.

What if, instead of prioritizing, they sequenced their projects?

What would happen if each business kept their project request list arranged, not as a prioritized list, but as a sequenced list. They should, at all times, be ready to answer the question: “If we can start one new project from your list today, which one should it be?”

So how do you sequence projects in the right order?

One simple way to sequence your projects is to use Weighted-Shortest-Job-First (WSJF) ordering. To implement WSJF ordering, you do the following:

  • Estimate the cost of delaying the project (loss of revenue, loss of opportunity, and so on).
  • Estimate the duration of the project.
  • The WSJF value is now simply Cost of delay/Duration.

Each business group would do this for all of their projects. The project with the highest WSJF value should go first. If each of the business groups maintain a list of their projects, sequenced WSJF, all Steve’s team has to do is pick from the top of it when they have capacity. Implementing this will require IT and business groups are aligned regarding how to estimate the cost of delay and how to determine duration, but the structure is simple.

2. Allocate Resources to Queues — Not Projects

Now, we have all the business groups sequencing their projects using WSJF, giving Steve and his team have a better idea of what to work on. Yet a problem remains: They have only 50 percent of capacity needed to meet demand. One way to resolve this is to negotiate a capacity allocation for each of the business groups for the next budget period (6-12 months typically).

  • Business group A gets 20 percent of capacity.
  • Business group B gets 30 percent.
  • Business group C gets 15 percent, and so on.

As Steve’s team completes projects and opens capacity, they have a guide providing what queue to pick from next. But how do you align your teams in reality?

What is the best way to allocate available capacity?

Steve now needs to figure out the best way for his teams to complete this work. One of the most effective ways to solve this is to begin with an Agile team-based approach, with 5-9 people per team. These teams should be long-lived, and persist across the boundaries of any particular project or initiative. In Steve’s scenario, he’d assign whole teams to projects (one or more), with each team only working one project from start to finish. Under this model, allocating teams resource capacity among business groups A, B, and C is simple. All Steve needs to do is assign a certain set of teams to each business group for a fixed time period. These principles are illustrated below.  

capacity allocation for business groups

By aligning small teams to queues, organized by different business groups, and completing work organized by WSJF, Steve and his team will be able to:

  • Determine when capacity is available to start new projects.
  • Know what business group should benefit from that available capacity.
  • Understand which project should be started for that business group.

Aside from turning a high-stress working environment into a well-oiled machine, working in such a way yields many other benefits:

  • You achieve a high level of transparency.
  • You shorten project cycle times.
  • You simplify resource planning.
  • You have better teamwork through stable teams.
  • You increase efficiency by reducing multi-tasking.
     

Bringing It All Together

There are, of course, many details to figure out to successfully implement what I outlined above. One particular thing to point out is that for this scheme to work well project requests should not vary too much in size. Typically, it means large projects should be broken up into a number of smaller requests. As always, there is no silver bullet. But if can agree with your different business stakeholders to work in the spirit of what I have outlined above, I genuinely believe that life will be easier for everyone involved.  

Learn more about Hansoft, the Agile project management software for simpler projects.