Project management consulting and training for social change organisations.
Last year when I was finishing up my work with Greenpeace UK and about to begin development with Amnesty International I thought "Hey, I should really introduce the Greenpeace UK web team to the Amnesty web team — they're both going to be using Drupal and there are bound to be opportunities for knowledge sharing. Maybe even co-development!"
I'd been talking to Oxfam International at the time as well and now they're moving to Drupal (and there's Comic Relief who I know run at least one Drupal site and Concern Worldwide who I'm working with now) — there are a lot of NGOs in the UK (and nearby) who are using Drupal and who could benefit from meeting up face-to-face on a monthly or bi-monthly basis to share information and experiences.
And I'm happy to report that it now looks like this is definitely going to happen!
Some time in early June, possibly at the Amnesty office on Easton Street but definitely in London, a group of people from a number of the organisations mentioned above and myself will be hosting the first meeting of Drupal for NGOs: an approximately 2 hour get together (followed by drinks at a nearby pub) to talk about Drupal, which contributed modules we're using, what our experiences have been and, I hope, what our plans are for the future.
PLUS: it may be the case that Jeff Robbins of Lullabot will be in town at the same time and will deliver a bit of a keynote to the group following on from his "How Drupal Will Save the World" post last year.
If you're interested in attending, please comment here or send me an email. I'll create an event in Upcoming once the details have been finalised and post an official announcement here and on the Drupal UK users site.
Huzzah!
amnesty, comicrelief, concern, drupal, greenpeaceuk, importantprojects, lullabot, nptech, oxfam, softwaredevelopment
For the last 6 weeks I've been working with a team of 7 Greenpeace UK staff to refine the objectives and prioritise the requirements for a constituent relationship management system GPUK plans to implement (we'd originally planned to spend 5 weeks on this activity but made the decision to spend more time on the requirements definition piece).
This week, we're making the final revisions to our list of prioritised functional requirements and must-have non-functional requirements, at which point I'll post them here and solicit your feedback and recommendations — GPUK already has a centralised (but offline) supporter data warehouse they run reports from using Cognos; what they're looking to do now is implement a CRM system that integrates what they already have with their website, which they'll be migrating to Drupal in parallel.
More later :)
UPDATE: this project is on hold until some resourcing issues can be worked out (and until then, I'm not able to post the requirements list mentioned above).
UPDATE 2: I'm no longer working on this project, although it will be continuing (I believe my friend and colleague Sue Fidler will be working with GPUK to complete the next phase of work).
projectmanagement, softwaredevelopment, nptech, importantprojects, greenpeace, howto, prioritise, requirements, crm, drupal, civicrm, democracyinaction, salesforce.com
As I mentioned a few weeks back, I've been working with the Internet and E-Communications Programme (IEP) team at the International Secretariat of Amnesty International to organise and plan a 2 year work programme for the IEP — one that best meets the objectives they've set for themselves and that gives them better visibility into what is actually achievable given their staff and resource constraints.
Last week I met with the team for the day to do two things: to come up with ways the IEP can better manage its ongoing operations (i.e. those repetitive tasks that must be done but never end like keeping site content up-to-date) and to begin to prioritise its projects (those temporary endeavours undertaken to produce unique results like replacing the CMS used to keep site content up-to-date).
To accomplish the former, we used dotmocracy, an equal opportunity and participatory group decision-making process my colleague and friend Jason Diceman introduced me to a couple of years ago. I'd never facilitated a dotmocracy session before, so I read the most recent version of the handbook, got some last minute instruction and advice from Jason himself, and it ended up working out really well — the group came up with more than a dozen proposals (ideas) for improving the ongoing operations of the IEP, which, once dotted, we were able to sort in order of agreement and begin to develop action plans and next steps around. A highly recommended experience :)
Check out Jason's site/company, Co-op Tools, for more on the process or to get him into your organisation to facilitate a session.
projectmanagement, programme, planning, softwaredevelopment, nptech, importantprojects, amnestyinternational, dotmocracy, facilitation, jasondiceman, cooptools
Today was the first meeting of the Greenpeace UK "E-Business" requirements prioritisation team (pictured above — and thanks for posing for the photo, people).
We met to kick-off a 5 week requirements definition and prioritisation project — really a sub-project of a larger project Greenpeace UK has undertaken to provide supporters with the ability to manage their relationships with Greenpeace online.
We'll be following a requirements definition and prioritisation process really similar to the one the web team and I followed on the Greenpeace UK CMS project (and when I say similar I mean identical but with improvements gleaned from our experience in engaging with the Plone and Drupal communities throughout that process).
Gideon, Joss, Katie and Tracy — thanks for your time today and I look forward to working with you on this very exciting and important project :)
projectmanagement, softwaredevelopment, nptech, greenpeace, importantprojects, howto, prioritise, requirements, open source, community
...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
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
Some time ago, I was commissioned by Katrin Verclas of Aspiration to write an article on collaborative software projects, using two (partially) failed projects as examples of what not to do. It's been a long time coming, and in the end, involved collaborating with Important Projects ally Phil Dwyer to complete, but here it is, what I hope will be the first in a series of HOW TO articles published on this site under a Creative Commons license:
HOW TO Manage Collaborative Software Projects (148 KB)
Recommendations made in the article for the successful management of collaborative software projects:
Enjoy! Very interested in any feedback you might have as well :)
projectmanagement, softwaredevelopment, collaboration, nptech, howto, importantprojects
