HOW TO Prioritise Requirements (Part I)

When you're planning to implement a new piece of software, prioritising your requirements is really important because a) it helps you focus on the things that matter most and b) it makes selecting the right product way less of a crap shoot. But unless you follow a logically sound prioritisation process — one that all project stakeholders understand and buy into — prioritising requirements can become an arbitrary and unnecessarily emotional exercise (i.e. the exact opposite of what you want).

On the Greenpeace UK CMS project, we're currently defining the requirements for a new content management system (the existing system was developed in ColdFusion over 4 years ago and simply no longer meets its users' needs). Our plan is to evaluate 3 open source products and make a selection based on how well each product meets our top priority requirements — to do so, we're following a step-by-step process designed to keep us focused on the system features and capabilities that are most important to the web team, to our end users and to Greenpeace.

Step 1. Define and weight organizational objectives

Like I've said before, projects are undertaken to achieve strategic objectives. Greenpeace has a number of strategic objectives, one very important one being to win campaigns. At our away day meeting in February, we brainstormed on how the web team could help Greenpeace achieve this objective, performed a SWOT analysis, came up with a number of project ideas and decided that replacing the existing Greenpeace UK CMS with something better was the most important project for the web team to undertake at this time.

Having made the decision to take on a project (i.e. a temporary endeavour involving risk), teams should write down and distribute the organisational/team objectives the project is being undertaken to address. This will help ensure project stakeholders are on the same page, can help determine whether the project really should be undertaken at all and will factor into both requirements definition and prioritisation later on.

We defined 3 organisational objectives for the Greenpeace UK CMS project, and assigned weightings to each, according to how well we thought they could help us help Greenpeace win campaigns (see Figure 1, below):

1. To make Greenpeace staff (and the organisation) more effective [weighting: 4]
2. To communicate information more effectively [weighting: 3]
3. To build/maintain the Greenpeace brand more effectively [weighting: 2]

Figure 1 — defining and weighting organisational objectives.

Step 2. Identify and weight user types

Once organisational objectives have been defined and prioritised, identify and assign weightings to the types of users that will interact with the system you've decided to implement. Again, you want to do this because you want stakeholders to come to agreement on who the project is being undertaken to serve, and because you need to think about (and, where possible, directly involve) the users of the system in the requirements definition and prioritisation process.

Users are people/machines who/that interact with a given system — in the case of the Greenpeace UK CMS project, we identified 4 different user types, and weighted them according to their relative importance in achieving our overarching project objective of helping Greenpeace winning campaigns through the implementation of a better content management system (see Figure 2, below):

1. Content editor [weighting: 3]
2. User [weighting: 2]
3. Supporter [weighting: 2]
4. IS/IT person [weighting: 1]

To be continued Continued in HOW TO Prioritise Requirements (Part II)!

projectmanagement, softwaredevelopment, nptech, importantprojects, greenpeace, howto prioritise, requirements