For Prioritizing Web Projects, I Start With Boulders

For web teams, project prioritization is critical for ensuring that the work you’re doing is helping the company to achieve it’s strategic goals. It is also important for managing stakeholder expectations and guiding decision-making when it comes to roadmap planning and what to work on next. And while the goals of prioritizing work are generally the same for everyone, the way it’s done can differ from one person to the next. In this article, I will share my approach for web project prioritization, which emphasizes simplicity and speed in order to save time and energy for getting work done.

Boulders Are the Highest Priority

What distinguishes large rocks from boulders, is that boulders are immovable. You can’t control when they appear, where they’re located, or whether they exist at all. Likewise for web projects, it is important to identify the boulders in front of you that, due to their immovable nature, will require you to work around them. Within companies, boulders are typically projects that are driven by teams outside of your own that you are required to support and are by default, of the highest priority. For example, these could be a new product launch, company rebrand, marketing campaigns, or even legal requirements. To help me understand what the boulders are, I meet regularly with key internal partners such as product, brand, and marketing, among others. Once I know what and how many of them there are, I use a simple 2-step framework for prioritizing everything else.

Step 1: Project Scoring

To sort a collection of items in a particular order, I start with a high level set of values and evaluate each item against it. For web projects, those values are:

• Impact Potential: The amount of impact that the project could have on primary business goals

• Impact Certainty: The degree of certainty that the project will have a positive impact on those goals

• Effort: The projected amount of work, in terms of difficulty and time, that the project requires to complete

• Fun Factor: The estimated amount of enjoyment the team would get out of working on the project

For each project, I work with the team and for every one of those values, we apply a simple high, medium, or low score. Some teams will use a more granular scale such as 1-10 or even 1-100, but in my experience, fewer gradations are better. Once the projects are scored, we’re can apply a sorting mechanism to order them in a way that makes sense.

Step 2: Project Sorting

The way I view sorting is to provide the team and I with a general sense of what the most important projects are. For me though, the final sort order is a guide, not a God. This is because I’ve found that outside of the items at the very top of a prioritized list, pretty much everything else is of roughly equal importance to the other items around it. For example, some teams will put in a lot of effort to create strict sequential ranking (1,2,3 …. 35,36) but the vast majority of the time, the 35th ranked project is not definitively more important than the 36th.

I sort scored projects by ordering them in terms of impact potential first, then impact certainty, followed by effort and fun respectively. Here’s an example of what 20 prioritized projects using my approach would look like.

Conclusion

The important thing I want to stress here is that this list is not sequentially ordered, even though it looks like it. The way to look at this, at least from my point of view, is that projects that have a lot of red are super important, those with a lot of orange moderately so, and the gray ones even less. But identifying what specific thing from this list to work on next is a separate exercise altogether that depends, only in part (albeit a big one), on applied priority.