Friday, August 23, 2019

Don’t Make this Common Mistake When Prioritising Software Projects

Every company I’ve worked for has had one thing in common – they all generated good ideas faster than they were able to make them a reality. Regardless of whether they were a small start-up or a huge corporation, they all had a backlog brimming with ideas, and only so much time and resource with which to deliver them. They needed to prioritise their workload. 

Any decent product owner quickly realises the need to have a logical and defensible way to prioritise the backlog. After all, there will be many stakeholders with pet projects that they need to be delivered urgently. When it comes to something so important, arbitrary or ‘gut feel’ choices aren’t acceptable.

With this pressure comes a mistake which is simple and very easy to make. It comes so naturally and seems so logical, but is the root cause of a phenomenal amount of lost value in tech companies.

The mistake is to put the highest-value projects at the top of your priority list.

At first glance that might sound outrageous, so I’ll be more specific. The mistake is to put the highest-value projects at the top of your priority list without first considering the amount of effort required to deliver them.

The crucial thing to realise is that your goal is not simply to deliver the project with the highest value. Your goal is to maximise the cumulative value you deliver in a given amount of time. The highest value projects tend to be the largest in terms of effort, and by prioritising projects by their value alone, you may miss the chance to deliver maximum value over time.

To illustrate this, lets imagine that you are choosing between two projects, and you can’t work on both projects simultaneously:
  • Project Major is a complete rewrite of your website. It will take 12 months to complete, but once released will deliver $100,000 of revenue every month.
  •  Project Minor is a change to your payments page. It will take 1 month to complete but will only deliver $15,000 of revenue every month.
Most people, especially leaders without a technology background, will rush to deliver Project Major first, because it generates the most value. This is a reasonable instinct but misses the big picture. To see why, lets look at the cumulative value delivered if we prioritise the projects in two different ways.

First, if we prioritise Project Major first, then deliver Project Minor:



This choice delivers no value after 1 year, and $1,365,000 in value after 2 years.

What if we do things the other way around, and put the lower value project first?



This choice delivers $110,000 in value after 1 year, and $1,445,000 after 2 years.

To make the comparison even clearer, lets look at both on the same chart:


As you can see, putting the lower value project first actually generates more revenue over time - $80,000 more, to be specific. But it has other benefits too.

First, value is generated earlier. This is important for many reasons, but especially where cash flow may be an issue. Money generated can be reinvested or otherwise put to good use. In the case where the Major project is focused on first, the business would go an entire year without generating any money from the development work.

Secondly, risk is reduced. Large projects tend to be complex, and hence here is a greater chance that a mistake will be made, the requirements will change, or the project will overrun. When was the last time you heard about a large project being delivered on time? 

A simple way to prioritise, therefore, is to divide the value of each project by the amount of effort it takes to deliver it. In the case of projects Major and Minor, this is the result:

Project
Estimated Value ($ per Month)
Estimated Effort (Months)
Value / Effort
Minor
$15,000
1
15,000
Major
$100,000
12
8,333

This methodology of prioritising projects is a simple version of ‘Weighted Shortest Job First’ (WSJF), so-called because it favours short projects but is weighted towards those with the highest value.

Lets look at how we could use this same methodology to prioritise a longer backlog:

Project
Estimated Value ($ per Month)
Estimated Effort (Months)
Value / Effort
A
$       15,000
1
15,000
B
$       20,000
2
10,000
C
$       75,000
8
9,375
D
$       50,000
6
8,333
E
$     100,000
12
8,333*
F
$       25,000
4
6,250
G
$     150,000
24
6,250*
H
$       35,000
7
5,000
I
$     200,000
48
4,167
J
$         2,000
1
2,000

*NB, where projects have equal value, deliver the shortest (lowest risk) project first

As you can see, the gargantuan Project I doesn’t get a look in. In fact, if you assume that you will work on these projects sequentially, it’s nearly 3 years before you start on it. But this sequence of prioritisation delivers far more value than the alternatives.

In reality, you are probably adding new projects to the backlog all the time, and it may be more than 3 years before you start work on Project I because other projects float to the top before it does. As a Product Owner you may have to work hard to justify the choice to deprioritise the highest-value project. Nobody said this was going to be easy!

This begs the question – should you ever commit to huge projects in the first place?

The answer is typically no, and you should ask tough questions of every huge project that is proposed. First – can the project be broken down into smaller constituent parts, each delivering incremental value? If so, each of those projects should be valued, estimated, and prioritised separately on the backlog. You may find that some of the constituent parts then float to the top, and valued is delivered more quickly.

Secondly, if the project can’t be broken into smaller pieces, can you add more resources so as to deliver the project more quickly? Importantly, the project does not necessarily have to be reprioritised – the project can be delivered more quickly simply by working through the backlog with greater capacity available. If the expense of additional resources can’t be justified, then perhaps the project is not as valuable as first thought.

Failing that, should it be done at all? Arguably, the bigger the project, the more certain you should be as to its value before you commit to it. If the methodology used to estimate the project’s value is weak, it should be challenged, and this should be addressed before the project is accepted.

The chances are, if the project is huge and cannot be broken down into smaller parts, it is not worth doing. Even if delivered successfully, on time and on budget, market conditions are likely to have changed to the extent that the assumptions that went into estimating the project’s value may no longer be valid.

Hopefully by this point, I’ve convinced you that you should take effort into account when prioritising software projects. The same principles can be applied to any projects, not just software (indeed, many of these principles have their roots in lean manufacturing).

However, not all projects have a tangible value, and not all business value is revenue. It is not always easy to estimate the value of each project with great accuracy. Furthermore, it is not always simple to calculate the amount of effort involved in delivering a project. The next blog in this series will look at ways to estimate value for more esoteric projects, and ways to estimate effort that don’t require weeks of work themselves. In the meantime, comments and feedback on this first instalment would be greatly appreciated.

Recap

  • It is a mistake to prioritise projects by their value alone. You should also take into account the amount of effort required to deliver each project.
  • Your goal is to maximise cumulative value delivered by your organisation, not necessarily deliver a high value project quickly.
  • A simple way to prioritise is to estimate the value and effort of each project, and then divide the value by effort to get a score. Then put the highest scores at the top of your list.
  • In general, don’t commit to huge projects. Break huge projects into smaller pieces, or resource up to deliver all projects more quickly. If this cannot be justified then the project is probably not worthwhile.