204: Drupal case study: The Roman Baths, Bath UK

jam's Dev Camp is back with something a little different this week: Rick Donohoe, Account Manager at Microserve in Bristol, presents a case study about how his company delivered six sites on a five-sit fixed budget contract. He gives some great tips on making a project like this successful. I saw Rick do a shorter version of this at Drupal Camp Bristol 2015 and thought that the information he has to share is valuable and that many of us building websites for clients could benefit from it. Thanks to Rick and Microserve for sharing!

The Roman Baths project

Microserve worked hand-in-hand with Torchbox on a fixed budget contract, initially to deliver five sites for the Bath & North East Somerset Council Heritage Services. Microserve's smart and efficient way of dealing with this kind of challenge--based on feature commonality and functional templating--allowed them to easily deliver an initially unexpected sixth site for minimal additional cost and development time.

The sites Rick talks about here are:

Roman Baths website

The Wisdom of Rick

Here are a collection of good ideas and practices that Rick touches on in the case study. I assume they are not all *his* ideas (thank you, team!), but I liked the headline too much to do without it :-)

  • Tip: Feature-driven development workflow to minimise risk in a fixed-cost build. The team identified the functionalities required across all the sites and which ones were shared across sites. They then built the largest, most complicated one (www.romanbaths.co.uk), building each functionality as a reusable Drupal feature (therefore "Feature-Driven Development"). The next five sites in the project were reduced instances of the first one--with different visual branding within a common base theme--so each required less work and there was no chance of adding conflicts that would then retroactively affect all of the other builds and require fixing across six codebases (Drupal multisite would solve this, too, but was not an option for this project.). Rick explains, "We built Roman Baths first. Then we could copy the site over and enable or disable features and that would provide us with exactly what we wanted on each site. That allowed us to provide these six sites at a fixed budget."
  • Tip: Use in-browser design for easier UAT. Torchbox delivered a fully responsive, multi-browser design that Microserve turned into a Drupal theme at the beginning of the project. Starting from a working prototype, your client will be seeing the real site at every stage of the project. Rick loves it when it comes time for User Acceptance Testing and the client says, "It looks just like the design!" ... Because it *is* the design. :-)
  • Intuitive, simple to use sites and close, personal support save time and money over the life of the project:
    • Tip: Reduce your training and support burden by investing in the admin interface and limiting user permissions. "Limit things. Only give the content editing team what they need. If you don't confuse them, it's going to make your life easier; they're going to find it easier to do and it's going to work so much better." [Pamela Barone from PreviousNext talks about making a great back end for content editors in this video of her jam's Dev/Drupal Camp session.] Rick and the Microserve team put all of the content/administration tasks and items on the sites in concise, focused "dashboards" or pages, with nothing extraneous (or dangerous to site reliability or security) visible or even accessible to those users. They are not burdened with Drupal-specific terms or knowledge--"Is a block in content or structure ...?". Everything users need to do is clearly labeled and organized. "Everything was put into one, single place. We said here you go and it doesn't even need any training. You can log in, you can see exactly what you're doing here." Extend limiting permissions to configuring the content entry tool/interface to a bare minimum: allow necessary, semantic markup only! No H1's, font sizes, colors, or other things that will let content authors interfere with your (beautiful, of course!) site design.
    • Tip: Be flexible and encourage your client to call you. If they believe in your and Drupal, they'll be happier, calmer clients. In Rick's experience, encouraging your client to call you if they have any problem sets a better tone than forcing them to deal with a ticketing system--though it is obvious that these have their place, too. If clients are allowed early on to express concerns, be helped over problems quickly, they learn to trust you and Drupal. Rick tells them, "'Call me, just call me whenever you want'" And that helps, "You do get quite a few phone calls at first, but you get a personal touch with the client. You can see where their problems lie, what you need to build to improve, and you'll have a lot pf phone calls at the start, but that will massively drop down. They get that confidence with you. You're helping them."
  • Tip: Reduce out-of-hours support by using Drupal-specific, supported hosting and infrastructure. "If you use an actual Drupal-specific platform--Pantheon, Platform.sh, or Acquia, for example--you'll find your out-of-office, out-of-hours support is massively cut down. We've not had a single out-of-hours support task required ... People who use their own internal hosting ... I think it's dead. It causes everyone headaches, the sysadmin time ... The right platform makes for a happy client."
  • Tip: Work with your client to find the best, easiest solutions to stay within budget. Use your technical understanding of Drupal to help and guide your clients to sane choices. If they want three features that look similar to a non-Drupalist, but one will add days of development time or break the budget, nicely push back and find alternatives together that will satisfy their needs but require (for example) less custom development.
  • Bonus Tip: Take your teams to Drupal community events. "You forget how everything works sometimes. You can be in an office, working with people ... This is what you do. Everyone loves it. It works well, so you've gotta love that, but ... When you go to a camp or a con and you bring the whole team there. And you forget that it's been a few months or for some people, it's been a year since they've been to a DrupalCon. You see the spirit; you see how excited people are. Everyone's in the sprints. You forget about that; you need that. You need to go to camps and cons to get the inspiration and to drive that fact home that there's a lot of other people out there. And you come back and everyone's motivated! You're thinking, 'Drupal 8! I'm gonna build some modules and I'm going to commit!' It's the inspiration you get from the rest of the community."
  • Bonus, bonus tip: Rick's Drupal go-live checklist (revised): "A handy tool for every developers arsenal: a simple go-live checklist! When a site is finally ready to launch it can be easy to get excited and forget some of the important details, but having a checklist to hand can prevent any last minute slip ups. Here is my own personal checklist and below it a further description of each item with some hints and tips. Leave me a comment if you have any questions or think I've missed anything important!" - Rick.

GatherContent content staging

In the case study, Rick mentions how Microserve used the GatherContent service as a content staging and collaboration tool for the Roman Baths project. He had some reservations, but a new version has been released since then that he hopes solves some of the issues they had. Looks like it's worth checking out: https://gathercontent.com/

Case Study Slides

Guest dossier