We did it. We met the deadline.
On time. On budget.
For a small moment we allowed ourselves to savour the feeling of accomplishment.
The last twelve months I have been part of a team that has overhauled and republished a aged university website. Using agile concepts, we're running a content team co-located within the delivery team. So far we've taken ~2,500 pages of website content and made it fit-for-purpose and published to the new templates and components. Of course we're under-the-pump with time and resources. We work hard and we collaborate to deliver on our promises: first a homepage by June, and then a website by Christmas 2016.
Somewhere between the first and second toast to our successful delivery someone asked, “Now what?”
Over the months of building our new website, questions cropped up. Quietly at first and as the deadline drew closer, the questions became louder and more numerous until we had to prioritise them:
- How are we going to hand the website back to the business?
- Our content authors need to know how to use these new components; who’s handling the training?
- How do we communicate our new content strategy and vision for the new site?
- What about the personas?
- Who’s going to maintain the content between go-live until the authors are trained and have access to their content again?
- How can we future-proof our strategy and vision?
- Who’s going to support the authors as they become familiar with their new website?
What happens after go-live and the transition back "to the business" is every bit as important, if not more so, as the project of building the website itself.
Our old website had a lot of problems and we worked really hard to address them. If we as a community continued the old habits we had with the old website, the new website would end up in the same situation that kicked off this project in the first place. More than anything we didn’t want to have our new website slowly rot on the vine as its predecessor had.
This time we want it to be different. We want to encourage continuous improvement based on data and user-feedback. We want to be able to respond as technology changes and evolve our website as required. We want to change the way we do web.
Now we are handing the live website back to the users, and the proof really is going to be in the pudding. All those decisions we made with them in mind. All those discussions about the authoring experience.; the assumptions we made based on our experience, expert practice, research and data are now about to be proven by the users and the authors as we measure the success of our new website.
The next steps have become a project in itself. Decisions now need to be made about how are we handle:
- Support of content and authors between going live and handover to authors
- Training of authors of the new concepts, components, menus and architecture
- Authoring access to the new website
- Community of authors to encourage collaboration and self monitoring
- Analytics to determine where change and adjustments are needed
- Enhancement to components and structure based on research and analytics
- Again and again and again…
All the while working on the next project; the next website.
I want to capture how we answered some of those questions as well as look at our content production during the project. Like everyone in agile projects we’ve been creating solutions as we encounter our challenges; so sharing some of what we did might help you iterate faster.
We’re not experts, but now we are experienced.