We've recently hired a new Head of Operations, Emma. It's the first time we've had someone in this role, so alongside establishing her areas of responsibility it's also incumbent on me to determine what areas of my role I can best delegate. Emma's been doing a great job of asking me questions to help with that. The key one which came out of her first week was 'what do we mean by operational freedom?'
case study: The Student Room
The best way to demonstrate this is probably with an actual story. In mid 2016 we were approached by The Student Room (TSR). They run the largest student community in the world, with over 1.8m members. The bulk of their content is forum based, but they also have to manage a large number of regular content pages such as articles, revision guides and university guides. Prior to engaging miggle, TSR had been managing these pages using the same open source solution which powered their forums. They’d found innovative ways to use that platform beyond its core capabilities, but had reached the limits of what was achievable.
TSR wanted a solution whereby content pages could be created by community members, based on their privileges – so alongside the tools to achieve this, moderation and approval workflows were key. They also wanted to give universities the means to update their own guides, with the options and toolset available to them determined by the service to which they had subscribed.
In terms of technology they wanted a content management system (CMS) which they could use alongside the rest of their solutions – the forum software, the adserver and the single sign on solution being three examples.
Finally they wanted something open source, based in object orientated PHP so that they could get their existing development team trained in how to use it, with the supplier leading that skills transfer.
In short, they had a number of constraints and as such they were looking for operational freedom so they could improve on their offering while remaining self-sufficient.
other common challenges which block self-sufficiency
Beyond that, other common challenges which we often hear from prospective clients are:-
- We don't have enough control over the creation or editing of pages, or the ability to manage how our content is structured, navigated and searched for. Our content is out of date, performs poorly in search and limits user engagement because we cannot cross-relate or distribute or share it.
- The tools we use to manage content lack moderation or workflow capabilities, or require more time to use than we have available, because we are constrained by resources.
- Our website is unreliable, suffers frequent outages, has security issues or broken pages in terms of links or displays.
- We have no idea of what value our website delivers to our business.
- Our in house team doesn't have the skills or capacity to keep up with demand.
- We get indifferent service from our existing agency.
So, how do we resolve those?
case study: CLPE
CLPE - the Centre for Literacy in Primary Education came to us with a number of these issues. They had four sites, each on a different platform, with one further site in the pipeline. They had a limited amount of content management control within each system, with little uniformity. Customers, content managers and admin staff all needed separate logins for each system, which created inefficiencies alongside issues with user data quality. It wasn't possible to share or cross-promote content and services. Four individual instances needed to be hosted and maintained.
In terms of interface there was little uniformity in brand, design or navigation. Search was also pretty limited. There was no means for staff to be able to easily preview content or test new feature requests.
We were able to resolve these problems by merging the sites together as a single site with the four services distinctly incorporated within it. Customers got one login to manage their engagement and staff one login to manage the site's content and all the admin and commerce workflows. When the client requested new features, which were often page or service specific, we were able to interpret these as tools and deliver functionality back which could be used in more that one place.
what else do we need to cover?
What helped us make CLPE more self-sufficient was understanding how the challenges sat within the wider context of their business. Often in these situations we need to establish what they have to hand already in terms of solutions, capability and resources that they can work with. Then we need to understand how, or map a path by which this will change over time, alongside the evolving needs of the business. After that we need to put in place a strategy encompassing solutions, tools, infrastructures, training or resources that will support this. Those need to be encapsulated in projects which are highly visible to all stakeholders, which we can then deliver on.
After initial delivery the focus becomes more about the day-to-day support of what we've put in place. For us, support is about understanding where the limits of self-sufficiency fall, as well as how they shift over time. We know they are different for every client because they are determined by so many parameters; skills, resource, time, opportunity cost, frequency of need, training, reassurance. Support requests can often end up as a requirement for a new feature. The way we handle these might be slightly different to run of the mill requests . Expect us to challenge where the business need is, where it delivers on key user journeys and ask how success will be measured, with us helping to put those objectives and measurements in place if they don't exist.
The final piece is around delivering peace of mind and ensuring that everything is managed within a reliable infrastructure to processes and procedures that everyone can understand.
how do we do it?
The means by which we deliver this are as follows:
- If we take on an existing site we'll generally put them through our six point health check. You can read more about that here.
- If we are looking at a new build or a redesign then we will propose a discovery phase.
- Following on from that we will define the project. This will be made up of design, content, development, test and delivery components, all of which we can manage in-house with our dedicated team and network of specialist suppliers and partners. We favour open source technology and our go-to solution is Drupal. You can find out why here.
- Support is managed via ad-hoc support agreements in which clients sign up to and purchase in advance a number of hours over a quarterly period, against which we undertake to turn issues around by the end of the third day. They are based on weekday office hours. In general we advise clients to buy a certain amount of support hours and then to establish what level of budget you’d like to spend per quarter on new feature development. That budget would then buy an amount of days against which we’d prioritise tasks on your roadmap, which would all be itemised in JIRA, the project management software we use, to which you have full access.
- Of course clients often ask us, business hours is great, but what happens if issues happen outside of that? While we can facilitate clients who require a more detailed SLA than our standard agreements provide, in most instances these sorts of issues generally relate to problems with hosting infrastructure. A poorly written application can impact on this, but in general sites only tend to go wrong when clients or suppliers are working on them, and that's usually within office hours. In any case we aim to use highly available hosting with a service layer on top which provides us with a range of tools to iterate, develop, test and deploy at speed, to which we can quickly and easily onboard resources if necessary. Our ‘go to’ solution for this is hosting provided by Acquia and we have several options we can offer.
- Where relevant we can train client teams in the new skills required to manage everything over time on an ongoing basis. We can even help source the staff people you need.
managing the relationship successfully
The success of client relationships is largely determined by the practice our teams build together with the Product Manager being central to that at our end. The relationship will be taken care of by an Account Manager, whose job it is to ensure you’re happy. They will take responsibility for ensuring timesheets, invoices and contacts are in order. They will also make sure regular meetings happen, at least once a quarter, to establish iterative development and support priorities.
These are the means by which we offer operational freedom. Does that make sense? Please feel free to ask us if not, either by phone, email, requesting a meeting or below.
And of course if any of the challenges we have talked about resolving sound like challenges you have had then we'd be happy to look at how we can help.
If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.