How to use prioritisation when working on web projects

Do only the right thing

Why do we need a prioritization in our projects? If we know what we want, why shouldn’t we create each element one by one until the final product is ready? Well, there are many reasons not to do that. First of all, we should understand what the prioritization is, a simple method of arranging work in order of their relative importance. The second thing to understand is that, whether we are aware of it or not, we always prioritize the things we do. The conscious prioritization has the advantage of having a bunch of rules help you make the right decisions in the complex and inconsistent world.

The first elementary rule I would apply is to do the right thing (and to do it in a right way). While working towards our goal we have to do the only thing that leads us in its direction. No matter how well we can perform, if we don’t do the specific task that's going to bring us a bit closer to the goal, we’ll fail. So don’t make a spectacular omitting of your goal.

Prioritatisation - do the right thing

Do the most important tasks first

It's fair to say that the “do the right thing” phrase is essential, but far too general to be treated as the only one of importance. We need something much more specific. That's why I also follow the rule of doing the most important thing first.

We are all familiar with the Pareto principle, also known as known as the 80/20 rule, where 80% of the effects come from 20% of the causes. There’s a reason behind the popularity of this approach - the natural conclusion of that is to do most important tasks first and get most of the effects as soon as possible.

Prioritatisation - product backlog

With that you won't get stuck with 80% of your work finished but only minor results. But here’s where we can find one big problem - which tasks are the most important? How to choose which 20% should be done first?

If we don’t operate in a simple environment, there isn’t a universal answer for that. It also always depends on the situation. When it comes to the software development process, you’ll need to take into account three perspectives that are often contradictory:

• the business side of the project: why is something created;
• the developers' perspective: what is the most limiting aspect in the project’s idea when it comes to bringing it to life;
• the reception of end-users: what kind of impact you want to have on users.

To understand the last perspective is the most challenging, but there are plenty of techniques to evaluate what's most important for the users. Let me mention only three of them - the Kano model, Buy a feature, and Opportunity scoring.

Remember about the time

While working on prioritisation, we need to remember about one additional aspect - time. Regardless whether we are aware of our limitations or not, the deadline is always determining our choices. We may be unable to do everything simply because we won’t have enough time. For instance, if we have options to:

A - build a great product that would win over the hearts of all users;

B - build a good product that most users would love to use.

...then which one would you choose?

Prioritatisation - timeline

When it comes to time in the IT industry, there is one more crucial ingredient you should consider in your project - the Time Value of Shipping. This is a rule that tells us that software only creates value for customers once it’s shipped. It is quite rough since according to it you should ship the product as soon as possible to earn a profit.

To be able to do that you have to at least get a Minimum Viable Product. That’s, however, a different story. For the purpose of this article, it will be enough to say that to be released an MVP only needs the most important parts - you don’t want to miss the right moment to go on the market.

If your competition releases a copy of your product before you, then you know you worked on it for too long. The product that’s unfinished is still more valuable than the non-existing one. Only the small part of end users expect perfect solution and will be disappointed when they received an unfinished product. The majority of users, however, will be glad to get their hands on the product and will use it anyway.

However, you still need to be careful when releasing it since this proportion is changing depending on how ready your product is. Remember, don’t be too extreme - you shouldn’t release neither unusable nor perfect application.

In our example, we can define this situation as if our product can satisfy 80% of its users.

On the graph below you can see the comparison of two approaches: do 20% of the most important task first and immediately start earning profit or start with working on details and wait much longer for the effects.

Prioritatisation - Pareto principle

Prioritatisation - Pareto principle in sprints

Blue - Approach 20% of the most important elements first;

Red - Approach without identification of most importants parts

Green - Shipping “the perfect product”

Shiping the MVP is the right path, but we need to be certain that we don’t have too many critical bugs that could destroy our effort and product. The users are, after all, outstanding testers. Without even realizing it they can find the smallest of bugs. However, you'll need to be ready to react quickly.

When it comes to prioritisation and approaching the bugs, we should take into account two factors - a percent of the affected user by a bug and the severity of a bug. In that context we can find three patterns:

1. Bugs which block the core of product for most of the users - that is certainly a primary thing and should be done immediately;
2. Highly disrupting bugs with low effect on users should be prioritised and deal in the near time as well as low disrupting bugs with high affection of users;
3. Low disrupting bugs with the low effect of users can we handle later.

Prioritatisation - how to approach bug fixing

Cost of delay

But what about the budget? Does it influence the priority of the task? Of course it does, it's a crucial part of any project after all. Different tasks have various costs of performance,business values, and priorities. There are plenty of techniques to estimate the cost. We should choose one, but keep in mind that there is no perfect tool - it simply has to be good enough to make a plan.

Let’s compare three features:

1. Feature A - worth 5000 $, cost 3000$;
2. Feature B - worth 2000 $, cost 500$;
3. Feature C - worth 7000 $, cost 3000$.

Based on that we should start with C, then go with A, and at the end work on B. However, when estimating and deciding on what to do, you should always remember not only about the costs of performance but also about the costs of not doing something or delaying it. Such information is fundamental when making decisions but often not taken into account.

Let's add to this example costs of delay, which happen in every phase.

1. Feature A - worth 5000 $, cost 3500$, delay cost x2;
2. Feature B - worth 2000 $, cost 500$ delay cost: x5;
3. Feature C - worth 70000 $, cost 3000$, delay cost: x0,5.

Prioritatisation - Most Valuable First vs Highest Delay Cost First

The example shown above is based on random numbers, while in the real world it's not so simple. People prioritize what has the highest value and unfortunately forget that things change with time. They also often don't remember that the order of things matters, especially if the estimates are not working and valuable things are dramatically losing value.

At such moments one should remember about the principle of sunk costs which tells us that we must forget about past costs and base our decisions on the situation happening at the moment. Current data is always a better basis for proper operation.

Summary

In the end, prioritisation doesn’t go without saying. It’s challenging and you have to remember about so many rules. So, to make a long story short:

1. do the right thing, do things right;
2. do most important tasks first;
3. take into account all important perspectives to settle what is 20% of the most important tasks;
4. be careful with the time and budget - remember about The Time Value of Shipping and delay costs;
5. make a decision based on the current situation and plan for future. Past costs shouldn’t determine your choices.