Oxfam's 6 principles for a successful CMS replatform project
Oxfam faced the same challenges as many other organisations when it came to replacing a large proprietary CMS for an open source one. “What about security?“, “who will own the IP?“, “who will we call for support?” and more.
But the team needed to get off their creaking (and expensive) Sitecore platform and take back control of their website.
We were delighted to be joined by Theo Ratcliff, Oxfam’s Head of Website, to get the full story of their replatforming journey, from picking a CMS to changing the way the organisation thinks about investing in digital. Here are our 6 key takeaways.
1. Establish a set of guiding principles
Theo established a framework or set of ‘guiding principles’ (with a bit of help from the GDS Technology Code of Practice) that any new platform must adhere to, including:
- "Our website must allow us to iterate" - digital teams need to be able to quickly and easily make updates and respond to change.
- "Our website must have a low cost of ownership" - leaving more budget to spend on making changes.
- "Our website must be managed and operated by the web team" - not by central IT or senior budget holders.
- "Our tools need to allow us to develop relationships with third parties who have a culture of collaboration" - no more vendor lock-in.
Through this lens four open source CMS platforms made the shortlist: Wordpress, Umbraco, Wagtail and Drupal. Each CMS was then evaluated against five new criteria - the ‘5 Ss’: Security, Support, Speed, Simplicity and Salesforce integration. Wagtail came out on top, due to its strong security, good UI and because it’s lightweight, fast and flexible. Oxfam America is also on Wagtail and they supplied a strong supporting recommendation.
2. Go open source
Aside from the obvious benefits of not spending (wasting?) money on licence fees, Theo makes a strong case for why nonprofits should use open source technology, including:
- Your code/website is portable. This means you can work with a number of different partners and vendors or recruit your own developers to work on the site, share code with other organisations, etc.
- Upgrades become a major benefit (not a prohibitive cost). Wagtail runs on a strict 3-month upgrade cycle. Updates involve no down time and include ‘meaningful enhancements like an accessibility toolbar’, that are ‘carefully curated and tested by experts’.
For a website like oxfam.org.uk, I can’t think of a requirement that is so crazy that it needs proprietary systemsTheo Ratcliff, Oxfam GB's Head of Website
There were also some concerns over the security of open source technology at Oxfam, which we helped Theo to alleviate (cue some rigorous meetings with Oxfam’s strong security team). Inheriting Django’s strong approach to security and following testimonies from the Federal Election Commission and National Cyber Security Centre, two pen tests and a review of the CVE database for cybersecurity vulnerabilities, Wagtail prevailed.
3. Try before you buy
Theo’s advice is that if at all possible, instead of running a big procurement process (usually based on heavy business requirements), do a proof of concept with your shortlisted CMS - ideally ‘applying UX principles to management decisions’, by aiming to improve an important part of your site that’s underperforming.
I don't think traditional procurement processes are suitable for websites. Websites aren't commodities.Theo Ratcliff, Head of Website, Oxfam GB
We worked with Theo on a rapid 2-week proof of concept sprint to redesign the ‘shop volunteer recruitment’ journey - the application system where people apply to become helpers in Oxfam’s +600 retail stores. At the end of the sprint, we had a working, tested prototype, powered by Wagtail and integrated with Salesforce. And importantly, this project gave the Oxfam team the confidence to pick Wagtail (and Torchbox) for the project. See our Embracing the ‘Art of the Possible' case study for the full story.
4. Establish a strong, perfectly formed project team
Once you have the technology and agency partner in place, it’s vital to establish a strong project team, on both sides.
Here are the key non-technical roles on Theo’s team:
- A product owner (Theo at Oxfam): to help plan each sprint, monitor progress, unblock the project, test and accept work, and refine the backlog.
- A product director (Katy at Torchbox): to champion Oxfam’s objectives and help shape the roadmap.
- 2 x delivery managers (a Torchboxer to manage the project and an Oxfam Delivery Manager to ‘wrangle people and get them in the room’).
- A senior sponsor at Oxfam to help shape the vision for the new platform.
Having a highly engaged product owner from the Oxfam team was hugely important for the projectKaty Cherry, Torchbox Product Owner
5. Involve users to design your new website
User centered design is sacrosanct (we won’t go into all the details of the discovery and design process but you can read more about it in our case study), and Theo particularly highlights using Gerry McGovern’s top tasks to engage users to help design the new site. This process informed the new navigation and helped Oxfam move from a ‘directory of Oxfam’, where ‘each team had a page’, to a user-focussed website.
6. Think OPEX not CAPEX
Theo makes a strong case for changing the way organisations need to think about managing digital projects and investing digital. He advocates a move away from the cyclical ‘boom and bust’ redesign/replatform cycles, every 3-5 years (typically a capital expenditure - ‘CAPEX’) to continually investing in your website (operating expenditure - ‘OPEX’). With the right foundations in place, we 100% agree.
Only after you launch your new site do you learn how people interact with itTheo Ratcliff, Head of Website, Oxfam GB
Since launch, conversation rates have increased from 18% to over 30% (40% on mobile) and where Oxfam used to have lots of manual processing, there is now far more automation in place.