Delivering great products, services, and experiences is what we do. And the development process is typically intense for both our clients and our teams. Rightly, the focus is on getting features completed, testing them thoroughly, and meeting agreed acceptance criteria. As the launch date looms though, it pays to give some attention to the project exit and the legacy we'll be leaving behind for our client. I'm talking about the end-of-project counterpart of the 'Sprint 0' that kicks off requirements gathering at the start.
For nearly 5 months, I was the Business Analyst for the Appnovation team embedded in a client's lab, working to deliver a multi-lingual portal to support a global product launch.
A by-the-numbers overview of the project:
- 20+ user roles
- 20 content types
- 22 views
- 3 stage content moderation/approval process
- 4 environments
- 4 layers of caching
- 4 integration points with other systems
- 4 languages in addition to English
By any measure, this was a demanding project. We ran 1-week sprints, with both development and quality assurance teams working into the wee hours on Wednesdays and Thursdays to complete and test features for Friday demos. Being on-site with the client organization and forging strong working relationships made it possible for us to stay on top of shifting requirements and to work through issues quickly when they arose.
After a few months of intense effort, the project went live across the globe. But, assembling the internal team that would run things was going to take time. Appnovation was asked to bridge the gap between project delivery and day-to-day operations until the team was in place and ready to take the reins.
But how to prepare for the transition from a project rhythm to the reality of day-to-day operations? Reflecting on the experience, it comes down to 3 essential elements:
- Documentation: What we did
- Training: Enabling the team to do it
- Governance and standards: Making sure it's done right
They may look dry, dusty, and boring, but without them, a corporate online presence can't maintain the level of quality it needs to be an asset to the brand instead of a liability. So let's take a few minutes to look at each one and its role in the smooth transition to operational reality.
Documentation: What we did
Besides the product itself, documentation is the main legacy you'll leave behind when you move on. Long after your smiling face has faded from the memory of your client, the documentation you created - or the lack of it - will leave a lasting impression. A lack of documentation is a black eye that it's easy to avoid - just make the time to create something useful and usable to help client teams to be self-sufficient after you're gone.
For the project, we documented things like:
- Publishing workflow
- User account structure and data passed to downstream systems
- Content types used and where they appear on the live website
- Content access rights by user role
- Content update process for a mixture of Drupal content and code changes
One of the biggest challenges for a Business Analyst near the end of a project is assumed knowledge. At least some of the people who will need to use your documentation have no prior knowledge of the site or system in question. So, to write effective documentation, and even to decide what to document, you need to put yourself in the shoes of uninitiated system users, and surface some of the things that are obvious to someone who's deep inside the system.
Some of this work can and should be done as you go. But some things can only be done when you are already dealing with the day-to-day rigours of running things. Controlled execution of content updates is one example. At the client's office, we had been running (and refining) a regular code release process for several weeks, deploying new features and bug fixes to the site pretty smoothly.
But once we had a live site running, it soon became clear that the process for making content updates wasn't as clearly understood or as consistently executed. Drupal itself is easy to use, especially compared with other enterprise-class content management systems. What varies is the operational context:
- Who needs to be involved from technical operations?
- Should we run a regular release schedule for content updates to align with code releases?
- How should we coordinate a mixture of updates to dynamic content and content changes done at code level?
- What layers of caching (including CDN) may impact the flow of changes through the system down to the end user?
We documented the actual content update process - the actors, the actions, the sequence. To stabilize things, we wanted to make sure that everyone with a role to play knew what it was and where they fit into the overall process, so that it would be consistent, repeatable, and traceable. This is the essence of controlling changes and reducing or eliminating errors.
Training: Enabling the team to do it
Drupal is flexible enough to fit practically any business requirement. This is great news for clients. One of the implications for a Business Analyst (and for their indispensable counterpart, the Quality Assurance Analyst) is that every custom-designed system has quirks that the BA and QAA know better than anyone else.
This is where training comes in. It's all about communicating detailed system knowledge without overwhelming your audience. Following good user experience strategy is a solid approach - focus first on key audience groups and their top tasks. What will these users really need to know how to do? In this context, there's always space to point out pitfalls or emphasize the essential information that underpins successful task completion.
For the client's internal team, we produced training slides for key system users, as well as detailed hand-over documentation covering regular operational tasks, tools for problem solving, and a road-map pointing out how to find commonly-used Drupal functionality.
Governance and standards: Making sure it's done right
Governance is among the driest and dustiest of dry and dusty topics, but it's probably the most important. Of course, governance is nothing without standards. Governance is there to ensure that standards are enforced.
But why care about such things? Well, good governance improves security, safeguards brand consistency, and protects reputations. Here are a few highlights that came up during this project, but relevant to all:
Auditing internal user permissions and setting up the operational team - We reviewed the access rights for the two senior administrator users and more clearly differentiated them so that sensitive core site management tasks were more tightly locked down
Agreeing a publishing and deployment schedule - We worked with our client to determine that multiple layers of caching were creating issues with visibility of content changes and agreed that a regular content deployment schedule was best, minimizing the performance impact of purging caches and invalidating CDN; coordination with the code release process was also recommended
Tightening up the publishing workflow - We brainstormed governance issues around content publishing and identified the need for a consistent internal QA process for publishing changes to the production environment; the ultimate publishing authority was vested in local as opposed to remote users in order to maintain tighter control - especially important in the early operational phase, while processes are still maturing
Digital style guide
A digital style guide is a must for any professional website. Inconsistent copy makes an organization look sloppy and detracts from the power of its messaging. Style guides are all about detail, so might seem fussy to some, but trust me on this one - even a small team needs a style guide for resolving disagreements about the fine details. A good style guide should spell out what consistency looks like, covering this and more:
- Frequently-used terms
- Product or service names
- Time and date conventions
- Technical consistency - e.g. bullet style
- Tone of voice
- Writing for online readers
For this client, we highlighted a number of style considerations and recommended a style guide to enforce greater consistency.
Content quality audits
Maintaining an enterprise-class online presence means incorporating ongoing checks and balances to ensure that high quality is more reality than aspiration. Some things to consider when designing a content quality audit process:
Frequency and scope - Decide how often to perform a quality audit and how much of your site to include (spot-checks, section by section, the entire site, specific content such as an audit of all images)
Quality checkpoints - Identify compliance points you'll check against
Plain Language - Work on complying with a Plain Language standard, such as Crystal Mark
Metadata - Periodically check that the metadata describing your content is complete and correct
Automated tools - For larger websites, consider an automated compliance checker tool, such as Active Standards
Content lifecycle - Monitor key traffic metrics and consider amending or retiring pages that are not receiving adequate traffic; think about the review or expiry date of a content item at the point of publishing it
We discussed such quality considerations with the client's team and recommended a regular quality audit process to ensure quality is maintained.
The transition from project to operations is sometimes a bit of an anti-climax, but also a bit of a shock - especially if you find yourself under-prepared for the challenges of maintaining a corporate web presence. Facing these challenges early and seeking expert advice are sound strategies that should prepare you and your team to navigate the days, months, and years ahead, ensuring your website investment continues to deliver value to your customers and your business.