6 Pre-Emptive Tips for Easier Prioritization

Working with stakeholders to prioritize requirements is an important part of the BA role.  Often, prioritization can be a difficult exercise, with stakeholders asserting that every single requirement is a “must have”.

When this happens, it can be a sign that insufficient attention has been paid to the project foundations.

Prioritization should be based on a measure of relative business value, and therefore it’s essential that there is a shared understanding of what the project is aiming to achieve before the requirements are captured and prioritized.

There are several pre-emptive steps that can be taken to make this process easier:

Prioritization - must or should?

Prioritization can be difficult if there isn’t a shared understanding of business value

1. Before working with requirements – check the foundations: Projects should have a clear purpose, with clear and unambiguous and measurable objectives.  The business value being delivered by the project should be clear. This might be financial benefit, a non-financial benefit, or a mixture of both.  As Business Analysts we can help to determine and quantify this benefit through active involvement in the feasibility phase, and input into the business case.

It is possible that some projects might be progressed without adequate foundations.  In this case, we should escalate and encourage the sponsor to ensure that this is addressed.  The early stages of a project are where the high level conceptual thinking happens, and if they have been rushed it is likely to cause significant inconsistencies and problems throughout the project lifecycle.  This will have a wide ranging impact beyond requirements and prioritization.

2. Make it memorable: Once the foundations are in place, it can be useful to have a quick and informal “acid test” to determine whether a feature or requirement is in line with the project objectives.  Spending time crystallizing the core of the business case into a single, short, user-friendly sentence can help.  For example, a project might have an objective such as:

“To increase revenue by expanding into the UK Market by 2012, whilst reducing transactional costs by 2.5% per item”

The beauty of distilling a project’s objectives into a sentence this simple is that it sticks in people’s minds.  It’s a great way to ensure that everyone on the team is on the same page, and it quickly surfaces any misunderstandings.  This helps immensely when prioritizing and defining requirements, as there is a shared understanding of the high-level objectives. This can act as a useful conversation starter and can help encourage stakeholders to link the requirements back to the full business case and objectives.

3. Agree and communicate a delivery road-map: It is important that stakeholders understand the real impact of prioritization, and that there is an open and honest discussion over de-scoping.  For example, will the “nice to have” requirements be delivered in a later iteration?  Will they be delivered in a later phase, and if so when?  Or are they effectively being de-scoped?

This is a significant point.  Stakeholders who have experience in waterfall projects may try to “cram in” all the features they can, since they fear that there will never be a phase 2.  It’s essential to build trust through open and honest communication, so that stakeholders feel able to prioritize rigorously and ruthlessly.

5. Have a clearly defined prioritization framework: Whether you use MoSCoW, or an alternative prioritization framework, ensure there is a clear understanding of how each requirement will be prioritized, and what each priority-level means.  It can be useful to have a clear, written definition of each priority level and to keep these visible whilst the prioritization is happening.  And when carrying out the prioritization exercise, encourage stakeholders to link requirements or features to business value.

6. Prioritize often: Agile techniques focus on regular and consistent prioritization.  I think this is good practice whatever software delivery methodology is being used.  Early prioritization and scoping saves waste.  In a waterfall project, prioritizing high level requirements will give a guide to which are the most important areas which require detailed analysis, and may even reduce the scope of the required detailed analysis.

In summary, a shared understanding of business value will help stakeholders to prioritize requirements accurately and rigorously.  As business analysts, we play a key role in this and our business analysis process can help by challenging projects where the foundations have not been established.

>>Define Your Business Analyst Process

Join us for the BA Essentials Master Class. You’ll learn a step-by-step business analysis process that you can customize to meet your organization and project situations.

Click here to learn more about the BA Essentials Master Class

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Adrian,
    Great post! I often talk to other BAs who believe in prioritizing after the requirements are elicited and I can’t stress to them enough that prioritizing during the process will make their lives easier. Love this post – can’t wait to share your perspective with others!

  2. Some great tips here. Thanks for sharing!

  3. My favourite trick goes like this:
    Stakeholder: “That (clearly non-essential) feature is a ‘must’.”
    Me: “So you absolutely do not want to launch this project/change until we’ve done that bit, even if it means waiting another X weeks/months?”
    Stakeholder: “Erm, OK, maybe it’s a ‘should’ then.”

  4. Some good ideas here Adrian and I am in total agreement with you regarding the need for a project to have comitted the time to build the necessary foundations.

    I am constantly dismayed when reviewing documentation for other projects when it is obvious that someone has just randomly completed a priority column. A bit of investigation usually reveals the lack of objectives, or when they exist some very poorly constructed ones.

    Pointing me in the direction of this entry reminds me that I must finish that article on objective setting at some point and send it to you.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.