Set your priorities right!

As a project manager, I see a lot of topics that can be improved in my work or in the projects that I manage. Therefore I decided to write some blog posts to help me think about solutions and to discuss what works for me.

One of the most important topics is the setting of priorities. I’ve had my fair share of projects where nobody cared to set priorities and where deliveries are postponed continuously because the product isn’t “finished” or isn’t “perfect” yet. If everything is equally important, you will never go live. One of the things that is missing in a lot of projects is that priorities aren’t set or aren’t set right.

If everything is equally important, you will never go live.

Why setting priorities should be obvious, it doesn’t always happen so here are a few reasons:

• You make sure your team works on the critical topics first. It’s better to have core features that work, then a lot of features that don’t work.
• When there is a delay in your project, you still have a good chance that the critical topics are delivered on time. This way you don’t have to postpone your project.
• When you are running out of budget, you are sure that you have a functional product with working core features.
• It makes it possible to have a flexible plan and deal with problems and scope changes.

Better to have core features that work than a lot of features that don’t work.

There are different ways to set priorities, here is my favourite one:

MoSCoW - Must have, Should have, Could have, Won’t have (this time).

• Must haves: these are the topics that are very important, and you can’t launch your product without it. If even one "must have" topic isn’t delivered your project will fail.
• Should have: these topics are also important, but will not be a deal breaker to go live if you don’t have them. They may not be as time critical as the "must haves".
• Could have: these are topics that are nice to have, the bells and whistles. They improve the overall usage of the product, but will only be done if time allows it.
• Won’t have (this time): these topics will not be planned for the current delivery. They are topics that are the least critical or don’t have any added value to the product or the business case.

If even one “must have” topic isn’t delivered your project will fail.

Now how do you start with this? Here is what I always do:

• To set the right priority, I do the following exercise “if we deliver in a month, what is important?”. I try to keep a maximum of 40-50% of the available time reserved to "must have" epics/stories. For the ones that the client didn't pick, I do the same, and I have my priorities set.
• I put an initial priority on epic level. It can always be that there are some stories in the epic which are not important, in which case they will not be done at that time and the epic will receive a new priority once all the important stories are developed. But defining an initial priority helps me with planning.
• If you have too many epics defined as "must haves", it can be good to repeat the exercise on story level as well.
• During the backlog grooming priorities are reconsidered and possibly changed.
• If more than 60% of the available time is spent on high priority topics, the proposed timescale of the project will probably not be met.

If more than 60% of the available time is spent on high priority topics, the proposed timescale of the project will probably not be met.

Some final notes... setting priorities on functional stories, doesn't mean that specific tasks should be skipped in order to save time. These tasks are related to automated deployments, testing, reviewing, refactoring and documentation.

Skipping them might save you time in the short run, but you will always pay it back later. As the saying goes: There is never enough time to do it right the first time, but there is always enough time to do it over. Whatever you do, do not favour adding functionalities over quality!