Painless Prioritization?

A few weeks ago, I co-taught a class on change management for nonprofit leaders. One of the participants presented this situation: We have too many things going on in our organization. To be successful, we need to focus our energy on the small number of initiatives that matter. How do I make that happen?

After reflecting for a second, I told her that I’d never seen a prioritization exercise that happened without pain or leaders having to expend political capital. 

The process is usually like inviting 100 people to a party and then figuring out there’s only room for 60. There’s almost no way to make that work without hurting people’s feelings. 

Everyone agrees with prioritization—and they are perfectly willing to cut other people’s work. George Carlin once said, “Have you noticed that their stuff is s**t, and your s**t is stuff?”

The only approaches I’ve seen successfully lead to prioritization all shift the decision-making process for starting projects.

For example, in agile software development, teams conduct sprint planning to identify the highest-priority activities for the next two weeks. However, when doing that planning, teams start with a cap on the number of “sprint points” they can reasonably handle in those two weeks. Once they reach that cap, the activity must be punted to the next sprint. The team may have ambitious goals for their overall project, but they restrict themselves from starting work they have little chance of completing with the given capacity.

Another approach is zero-based budgeting, which helps solve for reasonable capacity by starting with an assumption that today’s activities will not continue. Everything needs to be justified from scratch, providing a framework to compare activities directly. So, rather than discussing what projects to “cut,” the discussion is about “what’s most important now.”

Finally, I once worked in an innovation lab in which for a team to be formed, it had to include everyone needed for it to be successful—i.e., a designer, an engineer, a product manager, and a business analyst. In practice, that limited the number of projects based on the availability of the most scarce resources and prevented the creation of projects that did not have the resources to succeed. The idea was to be either all in or completely out.

Once a project starts, it is hard to end it without experiencing loss. In each of the front-end approaches to prioritization, the goal is to prevent that pain by mitigating the need to eliminate activities.