Many NGOs are good at forming strategic alliances to achieve their objectives (they’re usually also good at competing each other nearly to death, often at the same time, but I’ll keep that for a different post maybe). Yet, at the level of web technology, this usually seems to be limited to the level of exchanging tips and tricks, perhaps some RSS feeds, and referring each other to providers and vendors.
Two major developments are changing that situation now:
- Many organisations are investing in Drupal for their web platforms. This creates an eco-system where it’s easier to exchange actual technology, and to talk about it on a higher level of abstraction of artefacts and concepts.
- There’s an exploding interest in the NGO world to align strategies and investments in technology. The “Tool Pool” discussion revived at the Ecampaigning Forum, and the NetSquared conference next week brings this closer as well. Not to mention to emergence of more and more BarCamps like Social Innovation Camp.
From the code level: Easier sharing in the form of Drupal modules obviously is a great step forward, but still leaves you to reverse engineer the code and functionality of a module, to find out what the objectives and constraints were at the time of building.
From the organisational level: The predominant thinking still follows the pattern of coming together, listing needs, identifying commonalities, then trying to pool resources and plan towards development. It doesn’t facilitate a “long tail” approach with more ad-hoc alliances based on existing schedules and deadlines.
Enter the “open roadmap”
The middle ground in this is starting to share road maps in a more standardised way: to formulate organisational needs in terms of technical functionality, and indicate “organisational value” as well as expected “workload” (and maybe even available resources or indicative planning).
There are two main processes that need to be in place to make this “open roadmap” work:
- Organisations should develop and maintain product roadmaps for their online platforms, and make those available openly. In that way, (inhouse or external) developers can easily get an overview of multiple roadmaps, and identify overlaps. Occasional developers can also more easily contribute to a feature that will quickly be used.
- Development should be done in an agile way: relatively short iterations with new releases, and a mindset of continuously assessing opportunities and priorities. When developers signal overlaps, organisations can change their plans and truly join forces, without jeapordising their end goal.
I’ve taken the opportunity as “NetSquared project lead” for the Oneworld Connect project to explore how to translate organisational objectives into feature requests for engineers to work on, working towards a roadmap via a wiki.
And so I was excited when my friend Rob Purdie (who has managed migrations to Drupal for Greenpeace UK and Amnesty International, and is currently working with Concern) organised the first of hopefully an ongoing series of Drupal for NGOs meetups in London, and suggested a session called How To Build a Product Roadmap, with the dream that it helps participants identify roadmap overlaps and then collaborate.
I hope to see this “open roadmap” develop quickly in various conversations in the next two-three weeks already 🙂