The third and final post in our global rollout series covers publishing activity/approaches, training, scheduling calls across timezones, and general on-going maintenance and support.
Global rollouts often run alongside existing websites for each country. For example, the project may be a re-design and build of an existing Tridion website on a new branch of the Blueprint, meaning that local teams will be maintaining the existing live site, whilst looking to complete and launch the new one.
Depending on both the approach and the infrastructure in place, publishing can become an issue and should be removed as a risk as early as possible. If publishing is notoriously slow on the legacy system, for example, and there is now publishing activity for full new sites, it could interfere with business critical publishing on the existing live sites.
If using Tridion, there are a few things that can be done to reduce this risk:
Ensure all new site publishing to staging whilst the sites are being completed are set to Low Priority in the publishing options. This way, if an item is published to the existing live site and remains on Normal priority, it will always jump the queue once the previous item has completed.
- Not all at once
Ensure editors know not to publish entire Structure Groups or, worse, the Root Structure Group, as this will enter the publishing queue as one single item but will take a considerable amount of time as it attempts to publish many pages. This approach will prevent the priorities being useful, as the entire contents of the Structure Group in the queue will need to be published before another higher priority item can jump in. Therefore, always publish page-by-page.
- Dynamic Delivery for Tridion (DD4T)
DD4T is a framework that links SDL Tridion to your MVC web application. It publishes Pages/Components into your Content Data Store as data, rather than to your filesystem as code.
Data is being stored as JSON to be rendered when a page is requested on the site, as opposed to having to transform it and store it as a HTML page on the filesystem at the point of publish. What this means, among a lot of other things, is that publishing becomes extremely fast and, if implemented in this way, ensures the risk around long publishing times is significantly reduced.
- Plan it in properly
Providing you plan the rollout efficiently, you can work around the need for mass publishing by ensuring this occurs at non-peak times.
When looking to increase the publishing load, it is important that you involve technical/IT resources to review the current infrastructure. Ask yourself, ‘is it optimised for the level of activity you are expecting?’
There are options around having dedicated publishing servers and increasing the number of publishing threads, which means you can publish more than one item at once.
Training local country teams
Training is a key aspect of a global rollout. Often, a local team may be used to working with a legacy CMS , or an agency that was responsible for delivering and maintaining the website.
As a first step, each local team should be made aware of the new website project (if not already), and kept up-to-date with progress as the new website is built.
They should also be invited to training and be provided with as much up-front information as possible on the new website. For example: the reasons for the new site; how it will benefit the business as a whole, but also their local team/market, and new technologies they can begin to familiarise themselves with ahead of the training. Building Blocks can help with generic email templates for such communication.
Once each local market is aware of the project, and the technical delivery of the rollout is complete, you will need to train each local team on the new CMS. Ideally, they will already be well underway with any content creation, meaning you can incorporate exercises into training using real content and, hopefully, save a little content editing time down the line.
When planning training around the globe, it often makes sense to group training sessions by continents or regions. For example, a client I recently trained grouped the training into six training sessions:
- Northern Europe
- Continental and Southern Europe
- Asia and Australia
- North America and Canada
- South America
These sessions usually lasted two days, with a limit of six content editors per one Building Blocks and client-side project manager.
Day one was a basic introduction to Tridion and the client’s solution. Day two included hands-on exercises. This was followed by time for the attendees to begin populating their websites with real content, with the Building Blocks' trainers on hand to help where needed.
For larger sessions, Building Blocks provided additional Tridion trainers who could help around the room as/when required.
Building Blocks attempt to reduce the risk of language issues by:
- Providing all training materials up-front (so the editors can familiarise themselves with the content);
- Providing a browser based training/content guide which the user can use a translation tool on, if required;
- Providing multi-lingual trainers where possible/required.
You can read more about the importance of CMS training here: Why training is vital for successful CMS projects.
Regular calls/Webex sessions
Tied-in to training is the need for regular status calls and remote training sessions. When dealing with teams around the globe, it will quickly become apparent what impact different time zones can have on a schedule.
The key is communication. Working with the different client-side project managers, it is possible to schedule in various calls to cover different time zones. Using the Building Blocks teams in the UK, US and European offices, it is possible to help reduce the impact these different time zones can have.
As with training, it is important to ensure stakeholders and editors with different languages skills are catered for. By providing training in various languages, and providing recordings of the calls/screenshares after the event, it means they can easily recap on what was covered, and review the calls at their own pace.
Building Blocks also provides step-by-step screencast and video training, and tutorials that are uploaded to the training wiki to allow editors to learn at their own pace.
The benefits of using a ticket system with multilingual rollouts
At Building Blocks, we use JIRA to manage project tasks, the DOS contracts and rollout/content support projects. The benefits of using JIRA (or other web based ticket systems) for multilingual global rollouts are:
- Ability for teams within each of the Building Blocks offices to pick up tickets in different time zones and ensure a quicker response time;
- Allows content editors to raise tickets in different languages, if needed, which can be translated by the Building Blocks team and dealt with easily;
- The Building Blocks team can share common issues by linking tickets and feed these back into any weekly calls and/or training sessions;
- Any change requests or improvements can be migrated over to the DOS JIRA project for scheduling and release.
A global rollout project is not simply a build and launch of a new website. There are several different workstreams that need to be considered such as IT, legal and corporate. A key workstream that is often underestimated are the local country teams, who will need to not only create and launch each new local country site, but continue to maintain them in the years to come.
If they are considered and consulted early on and supported through the process, it will lead to better buy-in and a smoother rollout.