Project management consulting and training for social change organisations.
Thanks for coming out to Drupal for NGOs at Development House last night! Those were some great presentations (from Anna Feldman of GreenNet, David Gildeh on the work he did for Ashoka and Thomas Muirhead of Macmillan Cancer Support)!
And speaking of presentations, I'm thinking maybe next month we shouldn't have any presentations — instead, I'm thinking we should run a couple of workshops, or run an open space meeting around how we can really start to benefit from being part of this community we've built over the last few months. Let me think about it some more. Watch for details here and/or on the Drupal UK site!
Happy Halloween!
developmenthouse, drupal, drupalforngos, greennet, importantprojects, opensource, nptech, softwaredevelopment
Just a quick post to thank everyone for coming out to Drupal for NGOs on Monday — great to see/meet you! You are one motley crew (see above).
Thanks as well to our presenters, Oliver McColl of GCAP and Francesco Moretto, and to the very nice people at Comic Relief UK for hosting us! Thank you all :)
Preparations for our October meeting are now underway — watch for details here and/or on the Drupal UK site!
comicrelief, drupal, drupalforngos, importantprojects, opensource, nptech, softwaredevelopment
Alright! The next meeting of Drupal for NGOs will be held at the Comic Relief UK offices near Vauxhall 34 days from today!
Presentations for September are TBD (and please contact me if you'd like to present) — watch the event page or the Eventbrite registration page for more details as things come together :)
If you can't make the meeting but want to join us at the pub afterwards, we'll be at the Morpeth Arms (and thank you, Dan Duke of Comic Relief, for the recommendation).
UPDATE: Oliver MacColl of GCAP will present! Still looking for one more presenter. Francesco Moretto will travel from Milan to present on using CiviCRM with Drupal! 18 11 4 tickets remain The event is now sold out!
comicrelief, drupal, drupalforngos, importantprojects, opensource, nptech, softwaredevelopment
Alright! The next meeting of Drupal for NGOs will be held at the Greenpeace UK offices in Islington 19 days from today!
Check out the Drupal for NGOs group Robert Castelo set up for us on the Drupal UK site, create an account if you haven't already and comment on the event page so we know how many people to expect (last month we had more than 50 and it was awesome).
Presentations for this month are TBD — watch the event page for more details as things come together :)
UPDATE: Owen Pringle of Amnesty International and Ben Steele, Ben Alexander and Martin Gill of Comic Relief will present!
drupal, drupalforngos, greenpeaceuk, importantprojects, opensource, nptech, softwaredevelopment
A couple of months ago I mentioned I'd started working with Concern Worldwide on a pretty massive Drupal/CiviCRM project and was excited about the work we'd done in defining our objectives. We're now just one week away from completing our first development sprint, and although I'm pretty much all about that at this point, I still want to write about the objectives we've set for the project (and especially today — long story but I had to bow out of my faculty position at Social Tech Training in Toronto this week where I was meant to lead a session on setting objectives... Christopher Roy has kindly agreed to deliver the session on my behalf and I guess writing this now is partly an attempt to be there in spirit).
Notwithstanding the fact that many project teams very often forget or intentionally skip setting objectives, taking the time to set them is important for a number of reasons:
Collective focus on project outcomes is pretty critical to project success, and setting objectives allows us to achieve collective focus, so we set them. That is, we should set them — a lot of teams don't set objectives because they find it hard, or because they don't know how, or because they'd rather just "get on with it" (and deal with the consequences later — bad).
To make setting objectives on your projects easier, I've done a bit of research and put together the following step-by-step instructions. Enjoy!
Step 1. Understand organisational/program goals
Back in 2006, I don't think I really understood the difference between objectives and goals. This is pretty (embarrassingly) clear if you go back and look at the "objectives" set for the Drupal migration project I worked on with Greenpeace UK that year. Those weren't objectives; those were goals. Goals and objectives are different1:
Objectives map onto goals. And once met, objectives contribute to the achievement of goals. So before you set project objectives, you should really understand the overarching goals of the organisation undertaking the project, or the goals of the program of which the project is a part. Right?
The project I'm working on right now with Concern is part of its "Next-Generation Web" (NGW) program (i.e. it is one of many projects to be undertaken by Concern as part of the NGW program), which has the following goals:
To contribute to the achievement of these goals by a certain date and for a certain amount of money, we've set some narrow, specific, short term and measurable objectives for our project :)
Step 2. Define SMART objectives
Narrow, specific, short term and measurable objectives are good, but SMART2 objectives are even better. SMART objectives are objectives that are:
With Concern we've used the following format for defining our SMART project objectives, which I think has worked well and which I recommend using:
By [INSERT DATE], [INSERT WHO] will have [INSERT WHAT] resulting in [INSERT RESULTS] by [INSERT DATE].
Without the actual values inserted the above doesn't seem to have a lot of, well, value, I realise — here are the three SMART objectives we set for our project (I've removed the measurements because they're for internal use only at this point, but you'll get the picture):
It took us a bit of time to figure these out, a bit of discipline, but we got through it, and once done, we were able to validate our work by testing for SMARTness :)
Once you've written your SMART project objectives, it's good to test them as a team, or even better, with stakeholders on the project but external to the core team (i.e. those who may influence outcomes but who are not part of the day-to-day). Get them in a room or on the phone with you and test each objective one by one. Like so3:
One of the huge benefits to going through a process like this is determining whether the objectives you've set for your project are relevant — in my experience when teams do set objectives they often set them for people other than themselves, objectives they don't actually have the ability to achieve (e.g. objectives having to do with organisational changes they'd like to see happen but can't really influence). That and measurability. You've got to set measurable objectives. Even though you could be long gone before the outcomes of your project become measurable. SMART objectives are measurable if nothing else :)
Download this post as a PDF: 
HOW TO Set SMART Objectives (108 KB)
Endnotes:
1Goal vs. Objective — Difference and Comparison (n.d.). Retrieved June 24, 2008, from http://www.diffen.com/difference/Goal_vs_Objective.
2SMART (project management) (n.d.). Retrieved June 24, 2008, from http://en.wikipedia.org/wiki/SMART_(project_management).
3Setting SMART Objectives (n.d.). Retrieved June 24, 2008, from http://www.thepracticeofleadership.net/2006/03/11/setting-smart-objectives/.
concern, civicrm, drupal, importantprojects, nptech, objectives, projectmanagement, SMART, softwaredevelopment, STT
Check out the justice: Tom MacWright and Eric Gundersen of Development Seed have contributed a logo we can use to promote Drupal for NGOs. Thanks so much for this, guys!
Next Tuesday, June 10 at 18:00 the International Secretariat of Amnesty International will be hosting the first meeting of Drupal for NGOs — I'm so excited (and I just can't hide it).
The agenda has been set — Tracy Frauzel of Greenpeace UK will present their Drupal-powered site and talk about their future development plans, and Joel Bassuk of Oxfam International will join us live from Oxford via Skype video to talk about their Drupal project, currently underway. Nearly 30 people have said they're attending on the Upcoming event page (make sure to do the same if you're planning to be there), and the late-breaking news is that we'll also be joined by members of a local CiviCRM users group as well. Should be a good night :)
Can't wait — see you there!
amnesty, civicrm, comicrelief, concern, drupal, greenpeaceuk, importantprojects, nptech, oxfam, softwaredevelopment
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
