Project management consulting and training for social change organisations.
About a month ago, I posted the list of six activities the Greenpeace UK web team and I plan to perform by the beginning of June. So far, we've completed the first three:
We've also chosen the 3 open source CMS products we plan to evaluate given our prioritised requirements, and they are (in alphabetical order):
So without further ado, our prioritised requirements: 
Prioritised CMS Requirements for Greenpeace UK (741 KB)
If you're an experienced Drupal or Plone shop (we'll work with Greenpeace International on the Planet 2/OpenACS front) and are interested in working with us on this, please comment here or send me an email — rob[at]importantprojects[dot]co[dot]uk.
And thanks!
projectmanagement, softwaredevelopment, nptech, importantprojects, greenpeace, prioritise, open source, cms, requirements
...continued from HOW TO Prioritise Requirements (Part I)
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.
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:
1Project 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
Logo compliments of Crush Design — thanks, Natalie :)
nptech, importantprojects, web2.0, web2.0forgood, W24G, ecampaigning, webofchange
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):
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):
To be continued Continued in HOW TO Prioritise Requirements (Part II)!
projectmanagement, softwaredevelopment, nptech, importantprojects, greenpeace, howto prioritise, requirements
A few weeks ago I attended a planning session for Web 2.0 for Good, a one day open space conference to be held on May 22, 2006 at the RSA here in London. Here's a draft description:
I'm extremely excited about this event for two reasons: first, it picks up exactly where our discussions at the eCampaigning Forum left off back in January, and second, because my colleague Juhi Shareef and I have been retained by Policy Unplugged to co-ordinate and manage the event.
I'll post more as things come together — now to reach out to my network of "Web 2.0 for Good" people back in Canada and beyond to ask for their input and advice :)
projectmanagement, softwaredevelopment, nptech, importantprojects, web2.0, web2.0forgood, W24G, ecampaigning, webofchange
