HOW TO Prioritise Requirements (Part II)

...continued from HOW TO Prioritise Requirements (Part I)

Step 3. Define Requirements

Once you've defined and weighted the organisational objectives your project is being undertaken to address, and you've identified and weighted the user types the project is meant to serve, define the requirements for the software you're planning to implement with your objectives and users in mind. On the Greenpeace UK CMS project, we started by looking at the PMBOK's definition for requirement:

Given this, and looking back on the notes from our away day in February, we developed a list of over 100 conditions and/or capabilities the new Greenpeace UK CMS must meet or possess in order to achieve our organisational objectives and to satisfy our user types.

Each requirement was given an ID, and documented using a technique Martin Lloyd of Greenpeace International suggested we try, which phrases requirements like so: "As a [select user type] I would like to [describe what you would like to do] so that [describe why you would like to do it]" (see Figure 3, below). This worked extremely well for us — it really helped us to define our requirements so that they were easy to understand (and/or to identify the ones that needed to be clarified).

Figure 3 — defining requirements.

Step 4. Score Requirements

Next comes the fun part. Once you have a set of requirements your team members have all had a hand in developing, ask each member of the team to score them based on how well they help achieve the organisational objectives you've defined and how well they help meet the needs of the user types you've identified (see Figure 4, below). We had a list of 90 requirements (pared down over time through discussion), and each member of the team scored each requirement using the following system:

Scoring
2 = Requirement helps meet objective/satisfy user
1 = Requirement partially helps meet objective/satisfy user
0 = Requirement does not help meet objective/satisfy user

Figure 4 — scoring requirements.

It pays to take your time through this exercise — the more precise you can be when using this scoring system (e.g. "1.8" vs. "2.0"), the more useful the end results will be. Once all scores have been given, average them for each requirement and sort the results from highest to lowest. The spreadsheet we used also assigns a priority category to bands of requirements (C for critical, H, M and L for high, medium and low), which is very useful as well — because we want to stay focused on the system features and capabilities that are most important to the web team, to our end users and to Greenpeace, we'll focus our product evaluation on how well each CMS meets our most critical, highest priority requirements.

Endnotes:
¹Project Management Institute. A Guide to the Project Management Body of Knowledge: PMBOK Guide - 3rd Edition. Pennsylvania: Project Management Institute, 2004. pp 371-372.

Download the spreadsheet discussed in this article: Requirements Prioritisation template (200 KB)

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