V&A Museum: Migrating Content Management Systems - Open Source CMS


Published on

Richard Mogan, Web Technical Manager at the V&A Museum, presents the challenges encountered when moving a major cultural institution such as the V&A onto an Open Source CMS environment

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

V&A Museum: Migrating Content Management Systems - Open Source CMS

  1. 1. Moving a major cultural institution onto an Open Source WCM environment Richard Morgan
  2. 2. Introductions •  The V&A •  The world’s greatest museum of art and design •  http://www.vam.ac.uk
  3. 3. Introductions •  Richard Morgan •  Web Technical Manager •  r.morgan(at)vam.ac.uk •  rpfmorg(at)googlemail.com •  rmorg on twitter
  4. 4. Introductions •  A website redesign for the V&A •  Putting the entire collections database online •  Creating a new website for the V&A •  A new Content Management System
  5. 5. Procurement – what we did •  Create a short shortlist •  A mixture of Open Source and Commercial offers •  Tender designed for companies to “choose a system” and “propose a model” •  Statement of requirement focus was on the company, not an endless list of CMS features
  6. 6. Evaluation •  A technical evaluation of the system – Asked for a Virtual Machine for us to play with – Could we accomplish basic tasks on the system – without a manual?
  7. 7. User testing •  Even a little user testing is a lot better than none •  No training, no previous experience – the ultimate usability test for “museum” users •  A simple task
  8. 8. Import and migration •  Could we import items into the system without much help? •  Was it going to work?
  9. 9. Interviews with stakeholders •  Test of the cost model •  Test of the project management approach •  Test of the relationship •  We made a nuisance of ourselves
  10. 10. Technical strategy •  Web Content Management is hard … •  … and Content Management Systems are all terrible. •  As for Content Management System clients…
  11. 11. No Platonic CMS •  A good CMS is not an end in itself •  Who wants to be known for great management of content?
  12. 12. Linked data and applications •  CMS was not the “master” system •  Play to the strengths of the system •  Use alternatives rather than squeezing in functionality that doesn’t work •  But consumption and provision of services is vital
  13. 13. Spread the risk •  Using multiple systems reduces the risk associated with any one system •  Is ok to be complex, not complicated
  14. 14. Spread the cost •  Different sources of funding available at different times •  Many projects, not coordinated means a variable cost model throughout the financial year
  15. 15. Open Source or Commercial? •  The “traditional” risks of open source are well known •  OpenSource is free … but it still costs money •  But commercial solutions cost money too
  16. 16. Software or services? •  Focus on delivery, not elegance •  The museum does not want a Content Management System, it wants a website •  Time and materials requires firm project management •  But broken promises on fixed cost projects help nobody
  17. 17. Flexibility •  A variable cost model allows migration to be done piecemeal •  An opensource model where functionality can be extended … •  … delivers incremental improvements to challenged users
  18. 18. Agility •  Migrating content incrementally •  Improving interfaces incrementally •  Delivering many small projects with a small ace team •  An agile project management approach is required
  19. 19. “Mixed model” development •  Empower the museum to create its own website •  But guard against variable staffing levels •  Co-location days transfer knowledge •  Doing simple things with a few systems is easier than doing complicated things with one system
  20. 20. Conclusions •  Buying CMS “software” is just taking a hit before getting to work •  Content Management Systems should do services well •  Content Management Systems should not poorly replicate functionality in other systems •  Flexibility, agility, delivery and service