Chapter 23

Plan for Post-Launch Operations

Summary

An effective website depends on a collection of humans performing roles. Who are these people, what are they being asked to do, and how are lines of communication and reporting established?

Does This Apply?

While we can dream about a fully automated site, that’s impossible. You need people who can work on this site, which means people who can create, maintain, own, and make major decisions about the site. This chapter applies in some way to every single possible iteration of a web project.

Narrative

If you’re familiar with Top Chef – the longstanding reality television show pitting chef vs. chef in Survivor-style culinary elimination battles – you’re already familiar with the difficulties of website governance. You see it every year when it comes time for Restaurant Wars.

Restaurant Wars is a Top Chef staple: an episode-long competition in which the yet-to-be-eliminated chefs team up in two groups to create a pop-up restaurant from scratch. They select an executive chef, a theme, someone to run the front of house, six unique dishes, furnishings, and decorations. And they have two days to execute.

That these teams of chefs get anything done in two days is a wonder, but they always do. They plan their dishes, and they create systems for expediting, and they train their staff to their restaurant’s specific quirks.

Then they go to put it into action. Hundreds show up for a quick service, including the four judges. And it’s always much more difficult than it looks. Meals cannot sync with their orders. People are left waiting for hours. Front of house staff blows up at the executive chef. It’s high drama, and it’s (chef’s kiss) amazing.

In real life, setting up a new restaurant takes months, if not years. Systems are developed for moving food from one place to another, for delivering food to the table in an efficient and consistent manner, for sourcing and ordering ingredients and supplies, and creating fallbacks for when those supplies cannot make it in time. Menus are a constant source of change, as is staff, as is management, as is client base, as is literally everything.

It turns out that opening the doors to the restaurant is the easy part. It’s everything that happens inside that takes a mix of the right people, the right training, and some solid rules and regulations.

In other words, governance.

Governance and Ownership

Governance is all about decision-making; about systems that keep things in order, like the systems that govern our nations, or the systems that govern our organizations. When we talk about digital governance, we’re talking about assigning ownership, determining the people and processes that will manage your site, and documentation and tracking of policies and performance.

What we’re not talking about is a thing that just … happens. Governance is not a milestone, but a spectrum of readiness. Because every organization is different – all unique, in their own ways, with their own problems – governance tends to be measured on a curve. This is all to say that governance isn’t an easy subject, and this is normal. Your situation might be weird. That’s normal, too.

It sounds complicated, and it is. See, governance is people, and people are complicated. People need guidance, and they hate change. They have their own points of pride separate from the organization, and they aren’t movable and slidable parts. You can’t just change the code on people. You can’t save a person as a draft and come back to them later. You can’t CTRL-Z real life.

The Three Areas of Web Governance

When it comes to your site, governance often manifests in three key ways:

  • Roles and Responsibilities: Who is actually taking care of things on your site? Top-level strategy is fine, but under that is a set of rote tasks, and who is doing what?
  • Policy, Standards, and Workflow: What systems and rules are in place to ensure accountability, responsibility, and consistency across your digital ecosystem?
  • Accountability, Authority, and Change: Who answers for the content, design, functionality, and decisions therein on your site, and how does the organization shift to meet those needs?

Roles and Responsibilities

It should come as no surprise that your website isn’t going to run itself. And while there are always promises of automation and efficiency, content and design take time. The web world is always changing, and your website is no different.

And, more than time, it needs people.

Thankfully, you’ve already made the first steps, back in Chapter 3: Form Your Project Team. There, we highlighted the different people you’ll need to help make decisions about your web project. We talked about representing business strategy and project strategy, and we introduced the concept of the web steering committee. Now it’s time to make things more formal.

So, who is going to end up being on your web team?

The Key Team Roles

Talking about headcount in a book like this is difficult, because every organization is different. Some organizations have the ability to staff dozens: to build a strong web team from a diverse set of specializations. These teams might have dedicated content analysts, web-specific designers, and a full team of developers.

More often, a web team is built out of a small number of generalists: people with more general skillsets who are responsible for multiple items within the day-to-day operations of the site.

The number of FTE doesn’t matter for this. Staffing a web team is less about the number of people, and more about successful representation of specific roles. Often, a handful of people – and, sometimes, external vendors – will take on multiple roles within the internal web team, especially if your organization is new to maintaining a larger, content-managed website.

We can’t prescribe an exact list, but your organization will more than likely need to account for someone who can fill one or more of the following roles:

  • Product or Project Management: Responsible for managing day-to-day and project-based maintenance and improvements of the site.
  • Content Strategy, Information Design, and Writing: Responsible for translating business needs into site content requirements, including organization and creation of content.
  • Data Tracking: Responsible for measuring and acting upon site analytics and testing.
  • Design: Responsible for day-to-day graphics and images, as well as updates to existing site design.
  • Front-end and Back-end Development: Responsible for maintaining the codebase and following best practices.
  • Server Operations: Responsible for maintaining uptime, server monitoring, and security.

These are just high-level categories: for each of these bullets, you can go even deeper. A site dependent upon dozens of complex integrations from external data pools may need a web team that’s more developer heavy, while a boutique commerce site will need someone who can dedicate their time to producing high-quality photography, and an editorial or policy-focused site will want to develop a full strategic content team.

The Core and Distributed Teams

Regardless of the team, what’s important is knowing how they fit in with the larger organization. In Managing Chaos, Lisa Welchman separates those who will use and maintain a web property into four groups:

  • The Core Team: Responsible for conceptualizing, architecting, and overseeing the full scope of a project or initiative. They drive strategy, they measure success, and they build the things. They are developers, designers, and writers, but they can also be videographers, project managers, and data analysts.
  • The Distributed Team: Beyond day-to-day work, this is the team that’s responsible for either the edges of the core product or distribution of external forces upon the core product. They are department liaisons who periodically post updates to the news feed, or they are professors ready to update their bio page.
  • Working Groups & Committees: While the core and distributed teams may live within a specific department, the goals and application of your website belong to the entire organization. Working groups and committees can go in two directions: they either help oversee the core and distributed teams in an advisory role (in order to pull the full organization into alignment), or they serve as smaller opportunities for outreach, such as a working group created within the department to research user needs for a new intranet.
  • The Extended Team: In Welchman’s book, this refers specifically to external vendors, but we find in larger, more complicated organizations there is a kind of “resource borrowing,” where one department reaches across their silos to another department for help.

Not all of these groups will come into play, and you may find variance depending on the focus of your web team, the amount of external vs. internal staff you want to employ, and your overall budget. As with all things web related, your mileage may vary.

For example, for a recent project, Blend helped advise a health-care related organization looking to hire and create their own content strategy team. They had the scatterings of an existing team, but this new team was to be in place by launch of their new content platform. 

Given their ability to lean on resources around the larger organization, and their desire to actually create their own content team, we were able to break their staffing needs into three distinct groups:

  • The core team was dedicated to aligning digital content across the organization, as well as creating and maintaining content within the new content platform. These are the content strategist, information architect, and content operations roles, as well as the main project manager and product owner.
  • The distributed content team roles were filled by organization-wide resources. While some of this feels like core team work we mentioned in Welchman’s list, we have to remember that we were helping staff a dedicated content strategy practice, so anything outside of that practice would fall outside of the purview of the content team. The content team doesn’t need a dedicated designer, or a dedicated .NET developer, for example, so these smaller “roles” are handled by a distributed team of already focused staff.
  • Two advising groups were recommended: a web steering committee, designed to align content direction across all departments, and a content alignment group, tasked with iteratively developing a process for translating departmental content needs into real content assets (essentially, helping create a better workflow for each department to get their ideas to the content team).

Remember that not every role within these groups needs to be internally sourced; in fact, if you’re starting small – or even from scratch – you may not want to over-hire your department. Relying on external vendors is key to helping find your footing, especially for distributed roles.

Internal vs. External vs. Occasional

Where these people come from is a matter of organizational choice and budget. “Building a web team” always sounds at first like “hiring a bunch of people,” but in reality the industry is filled with people who are willing to help.

Specialization becomes more important as sites become more complex. In most internal teams, specialization isn’t the most efficient prospect. For example, very few organizations can focus on hiring a dedicated full- time information architect. There simply isn’t enough to justify someone spending forty hours a week working in that field.

This means there are a handful of options for these specialized roles. An information architect might:

  • Find a full-time information architect position within a single organization.
  • Work for a web design or development shop that provides information architecture work to multiple organizations.
  • Become a freelance consultant who provides information architecture work to several organizations.
  • Find a full-time position that includes information architecture, and supplement these core skills with somewhat “out-of-skill-set” tasks.

This is important to discuss because it directly relates to how you might actually find and hire people to fill your web team:

  • There are people and organizations out there who can help you fill a more specialized gap without hiring them to be a part of the full-time team.
  • There are people out there who are easily able to take on more than one role at a time, despite their more specialized nature.
  • There might even be people on your team right now who have the right skills to take on some of your web roles, but have never been prompted.

Of course, every option has its own benefits and shortfalls:

 

PRO

CON

Hiring From Within

They’re already here! They already understand the industry and culture.

They may need to be trained into a level of viability.

Hiring From Outside

They may fit a more specific set of factors.

They don’t have any organizational history, and unless it’s a universal industry they may not even have industry knowledge.

Contracting & Vendors

They can serve in a time of need for situations you do not feel warrant a full time or part-time employee.

They obviously cost more per unit of time, and they have their own schedules and agendas.

Maintaining Vendor Relationships

If the decision is made to look (or continue to look) outside of your organization to supplement your team, the answer will ultimately depend on what kind of vendor relationship you’re looking for. Yes, there are shops out there that provide the full scope of web services from discovery to launch, but you may also look for specialization to fill in the gaps in your own team:

  • Strategic Design Partners: Focused on user research, content strategy, user experience, and graphic design, design partners often draw the line at front-end development, instead focusing on the who and what of the website.
  • Marketing and Data Partners: A lot of firms bridge the gap between building the website and marketing the organization, providing specialized services tied to analytics tracking, paid and social advertising, and editorial search engine optimization.
  • Implementation Partners: If you need something built, some firms understand a specific content management system or development task so well that they’re specialized for that specific service: essentially, you bring them your idea, and they’ll build whatever you’re looking for using the best standards possible.

The benefit of having an outside vendor provide guidance from outside-looking-in viewpoint cannot be overstated: every organization, especially as their site becomes more familiar and their process becomes more ingrained into day-to-day work life, risks becoming isolated from the larger web world. When we work day-to-day on the same website, creating the same content, we begin finding solutions to our problems, rather than for our user’s problems. We get so bogged down in operational work that we forget to look at outside trends. 

An external vendor can help with this, because their job is to look at outside trends. They are not focused on the day-to-day of your organization; instead, they are focused on using their experience to translate the larger industry’s findings into something that works with your processes. 

They can be honest about what’s working and what’s not working, within the boundaries of your digital policy and specific industry needs. Which brings us to the next major part of ownership on your new site: is your digital policy in place?

Policy, Standards, and Workflow

Having the right people – both in terms of roles and humans – gives your website an untapped pile of stored energy: a coiled spring ready to let loose with creativity and productivity. But, we all know what happens when a spring is let loose into the open; it’s unpredictable, bouncing in any direction it sees fit.

This is where policy and standards come in. While to some they may feel like restricting micromanagement, policy and standards are designed to guide that coiled spring toward a productive outcome, directing the work of the team toward a more ordered, less chaotic web property.

Defining Digital Policy

First, let’s talk about policy.

When it comes to digital policy – specifically, digital policy directed toward web communications tools like your website – the focus is on rules and boundaries. Policy is often tied to legal requirements, and while we’re specifically talking about how digital policy relates to your website and its content, policy commonly also includes social media communication, files and information systems, emails, intranets, and digital broadcasts.

Digital and content policy is likely (or should be) a branch of your existing organizational policy – and in fact, digital policy should be aligned with corporate policy whenever possible. Some of this policy will be public, visible as a link in the footer of your site, while others may be stored away in internal documentation for staff to understand.

Digital and content policy will usually focus on:

  • Privacy and Data Collection: Often linked from the site itself, a privacy policy at minimum alerts site visitors to what data – anonymously or tracked – you are collecting, and how you are using it.
  • Security: The security policy might be rolled into the privacy policy, but it also focuses on data transfer, passwords, and secure information.
  • Accessibility: What is required and promised to meet web accessibility guidelines.
  • Domain and Digital Property Management: Who manages and owns web domains and other digital properties including the CMS itself.
  • Intellectual Policy and Copyright: What is protected through the organization’s copyrights and how can these things be used?
  • Web Records and Archives: What guidelines and requirements are placed on content as it’s removed from the site – if it can be removed at all.
  • Localization and Translation: What regions, languages, and translation methods are required for the site.

Digital policies will be created in partnership with legal and other policy bodies within your organization, but it can ultimately take any shape. There are no specific rules as to what you need as a whole, but we like to point people located in the United States to resources like Digital.gov’s Digital Governance Policy Outline, which provides a starting point for creation of a digital policy document.

To stay on the safe side, always confer with your legal representatives. They will help you determine what is necessary and what is not.

Defining Standards

If policy is the “rules” side of governance, standards are the “suggestions and best practices” of governance. While your privacy policy is going to define and make promises upon a set system of rules and regulations, defining your web standards will help provide guidance toward everyone who is creating content and managing the moving parts of your website.

While these are definitely part of your overall governance plan, we’re going to focus more on standards – specifically written style guides and design standards – in Chapter 24: Maintain and Improve.

Workflow: From Who to How

Talk about workflow can mean one of two things; one system-based, one people-based.

  • System-based: Within your chosen content management system, you may have various levels of workflow functionality, allowing for pages and blocks to be assigned for approval, locked for editing, and pushed through various levels of editorial guidance before it finally goes live. When CMS vendors talk about workflow, this is what they’re talking about.
  • People-based: However, the human side of workflow is tied to moving information from person to person. People-based workflow focuses on how content moves throughout the organization – the steps and people required to take an idea and turn it into an indexable and shareable piece of content, for example.

We won’t touch on system-based workflow. CMS workflow tools are just that: tools. They are not created to define your content workflow as much as they are created to help facilitate a people-based workflow.

On the other hand, that people-based workflow? It’s messy. While documentation of workflow often looks like a flow chart, where a chunk of communication moves through a series of steps, in reality it’s a bit of a tangled mess. We imagine our content working through a series of smart decision trees and as-needed checks and balances, but in reality they more often look like Rube Goldberg machines, taped together and just a few steps from disaster.

And that’s okay – workflow is meant to be refined, rather than written in stone. Sure, workflow requires definition. And it requires specific people at specific times. But it should also be flexible enough to allow for someone to be, say, on vacation, or busy with other things. It has to be agile enough to contract when a deadline gets tighter, or expand when the deadlines are farther in the future.

Content Operations: All of the Little Things

Finally, as we’ve learned over the past dozen or so chapters, so many other things tie into creation and upkeep of a website – from hosting the site, to maintaining the domain name, to making sure files are uploaded correctly. We often think of our website as a thing that’s created and maintained as a whole, but in reality it consists of dozens of little tasks strung together – which means there are dozens of little tasks that are scattered across your organization.

At Blend, we call this “content operations.” Just as the local Best Buy store requires support from an operations department – finances, transactions, scheduling, human resources, and management – so too does your website. Some of this ties to the creative workflow process, and some of it also ties to existing teams within the organization, but it’s worth having some kind of documentation on the entire scope of content and site operations.

Essentially, governance of the entire web experience will mean assigning roles, policy, workflow, and standards to all of the following:

  • Content Development: Who comes up with ideas? Who creates those ideas? How are those ideas turned into functional web pages?
  • Strategic Planning: Who is responsible for making high-level strategic changes, and how do they turn into actionable goals?
  • Analytics: Who manages this data – both in terms of reporting and analyzing but also in terms of technical needs?
  • Style Guidelines: What guidelines are in place, but also who maintains those guidelines?
  • Workflow and Approvals: How are content, design, and technical updates approved and moved through the organization? We’ll talk about this in Chapter 24: Maintain and Improve.
  • Content Review: Who reviews new and existing content for accuracy, relevancy, and outdated pages?
  • Archiving: How do we handle legacy content?
  • Content Logging and Auditing: How are changes tracked, and who makes these changes?
  • Permissions: Who gets to see what – both from a site user’s standpoint and from an internal standpoint?
  • Training: Who is responsible for keeping the people up to speed on all aspects of digital communication?
  • Form Handling: What processes are in place to ensure we don’t drop or mishandle content sent to us via forms?
  • User-Generated Content: Who is accountable for reviews, ratings, forums, and other user-generated content?
  • Technical Support: Who is permitted to make changes and approve decisions around servers, site uptime, and development access?

Accountability, Authority, and Change

Finally, let’s address the elephant in the room: you aren’t creating a process around a website. You’re creating processes around people. Which means your website is going to be only as successful as the team itself.

We want to make this perfectly clear here: despite all the time we spent talking about web roles and who might fill them, we’re not talking about roles and tasks here. We’re talking about everything that flows around that: the adjustments and changes, the differences in skill, and the interpersonal relationships that exist within your organization. We’re talking about stability and growth.

Because if there’s one thing we know, we know that not everyone’s on board with this new site. And despite all the work we did throughout this entire book – from bringing them into the process, to making sure they were heard, to involving them whenever possible – buy-in is always going to be slow.

This is just … how it is. Change is always hard. Dan and Chip Heath, in their book Switch: How to Change Things When Change Is Hard, say:

“Change isn’t an event; it’s a process. There is no moment when a monkey learns to skateboard; there’s a process.”

Your team is not a group of animals; they are much smarter, and definitely better equipped. However, your content platform and digital alignment are also not “learning to skateboard.” It is infinitely more complicated, and potentially affects the entire organization.

We believe there are several ways in which teams can slowly and incrementally ensure success as a new site and new process is brought up to speed.

Clear Ownership and Budget

We mentioned at the start of this book, and again at the start of this chapter, that ownership of the site is often a tug of war.

For a smaller organization, this isn’t as much of an issue: the website is, in essence, a capital expenditure, and it’s owned by everyone. In larger organizations, however, the tug of war determines who has enough influence to push decision making in their direction. While we’d like to chalk this up to a matter of behind-the-scenes politicking, in reality the tug of war can lead to a very public fight.

You can imagine how this affects the ability to communicate and promote change. If the departments and managers responsible for this new website can’t even decide who is in charge of it, then why should we waste our time with what is surely going to be another waste of money and time?

So, how do we solve these issues? Who should own the website? IT? Marketing?

The answer (and we’re so sorry to continue doing this) … is that it depends. It depends on where funding is allocated. It depends on your organizational charts and your existing teams and your product and your industry. As long as your various departments can get along and work together toward a common good – one that’s steeped both in technological best practices and positive user experience – it doesn’t matter which department owns the site.

As long as it’s not both. That’s when things get messy with regards to budget, staffing, and bragging rights.

Support from Leadership

A new website is a chance to begin shifting and adjusting some inefficiencies, drive a brand refresh, and signify a change in the overall mood of an organization, but it can only be this way if the leadership team outwardly supports the new site. This means making sure leadership is speaking positively about changes and their potential benefit, being clear with policy and governance decisions, making sure everyone understands what they are expected to be accountable for, and (most importantly) pitching in whenever they can. 

A web project must be a project for everyone, from the top down. Leadership needs to promote and support and celebrate … and even roll up their sleeves, when the time comes. Otherwise, it’s another tool thrown down the corporate ladder for someone else to figure out.

Messaging and Momentum

Even with clear ownership among leadership, alignment reaches further than just the people who make the decisions. There must also be some level of alignment and buy-in from those who will be affected by the new site, including site editors, department heads, and customer service.

As we mentioned back in chapter three, front-line staff should be kept informed of site updates and progress from the beginning, and they should feel heard throughout the process. But this goes beyond just ownership: this is, in essence, a marketing campaign for your new site, and it requires the same level of planning and thoughtfulness that any communications plan requires. It’s just that, in this case, your audience is internal staff, and your message is one of change, improvement, and forward thinking.

Go back to the reasons you used to sell the idea of the website in the first place. Maybe it’s focused on efficiency. Maybe it’s a point of pride that shows off a new brand or new concept. Maybe it’s just as easy as saying “the old one was … old. Now, we’re modern.” The new site will be a source of pain, but the pain is short-term. Help them understand that it will get better.

Web Content Training

And then, follow up that messaging with action. The people who edit the new site are going to be thrown into a very different world, for the most part, and they will need to be trained to understand how to use the new system.

In a perfect world, this training happens long before you are ready to launch – months before. Web training should be a time to mess around with a new system; to better understand what you’re working with in a test environment, and then gain reps through some areas of manual web migration. CMS training is often provided by a combination of the content management system vendor (for out-of-the-box functionality) and the implementer (for custom template training).

Understand that training exists on two levels — learning the CMS itself, and learning the website that was built with the CMS. You need both. More people need the latter, certainly, but

if you don’t have an expert external partner, then there needs to be some people in your organization who know the CMS down to the bones so they can help resolve issues.

Beyond learning about the tool itself, you’ll often need to communicate a shift in other areas of your workflow:

  • Internal training: understanding workflow and communicating changes to how content is written and maintained
  • Editorial content training: understanding the basics of writing for the web, including plain language and accessibility
  • Ongoing industry training: keeping abreast of the larger content, digital marketing, and analytics industries

For an in-house web team to be efficient, they must have a chance to learn beyond the office. Attending conferences, viewing webinars, joining industry groups, and simply trying to expand their knowledge through industry education is an important touchpoint for growth within an industry that changes all the time.

So when you begin talking about change, also talk about how you will help them make that change. Talk not just about training the CMS, but training their strategic thinking within the industry as a whole.

People Are Hard

There’s no way to get around this: people are hard to deal with. Trust me, you are no different. You have your own expectations and your own routines. You feel threatened when someone else dictates how you will do your work. You bristle when potential change looks more like change for change’s sake.

But your new web project? It’s just a pile of code. Like a set of puppets, that web project only does what you help it do: its functionality is a set of strings that you pull. And like those fledgling concepts during Restaurant Wars, they are utterly incapable of running without the right systems, people, and policies in place.

But when they’re in place? Those systems, people, and policies will help keep this new website working long past the point you thought it could. We’ll talk about that in the next chapter – the last chapter!

Inputs and Outputs

You’ll need a bit of knowledge around what roles you’d like to fill before you can start filling those roles, and much of that knowledge will be tied to understanding budget, organizational structure, and the overall environment. Which makes the biggest input an issue of knowledge and ownership based on the functional needs of your new site.

And the output? It’s a team of people who own the site, manage the site, and follow the policies created for the site. No big deal, right?

The Big Picture

Honestly, planning and execution of site governance happens parallel to site planning, design, and build, and in fact should be in place (with some exceptions) and rolling in time for the site to be launched. However, we also understand that governance changes take time. That’s okay.

Staffing

This is all about staffing. But who staffs the staff? Someone’s going to make the formal staffing choices, whether it’s the human relations department or the communications department.

Resources

Books