Stopping the Infighting About Digital Standards - Making a Digital Governance Framework - Managing Chaos: Digital Governance by Design (2015)

Managing Chaos: Digital Governance by Design (2015)

PART I

Making a Digital Governance Framework

CHAPTER 5

image

Stopping the Infighting About Digital Standards

Why Digital Standards Are Important

Identifying a Standards Steward

Standards Definition and Documentation

Standards Dissemination

Identifying Standards Authors

Finding the Experts: Input vs. Decision-Making

Input and Decision-Making Exercise

Summary

Igrew up in Columbia, Maryland, a planned community (see Figure 5.1). And as with the word “governance,” people tend to react to the phrase “planned community” in a not-so-positive way. “Planned” sounds dull and uncreative to people: cookie-cutter homes, on cookie-cutter lots, on cookie-cutter streets—“Little Houses Made of Ticky Tacky,” to invoke Malvina Reynolds’ well-known song. And Columbia was all about that: a city built quickly based on a template. There were street naming conventions, standard model homes, standardized lot sizes, and a standard “village” configuration complete with strategically placed shopping and swimming pools.

image

FIGURE 5.1
Columbia, Maryland—a planned community that opened in 1967.

So what do you get when you build a city on a standards-based framework? Those who focus on the standards part like to say “boring,” “all the same,” “not diverse,” because they believe that any standardization leads to a lack of creativity or innovation. But that wasn’t all there was to it. Once you factor in the context and intent of Columbia, the picture becomes different. Columbia was one of the first planned communities intended to be racially and economically integrated. Its founder, James Rouse, had a vision about creating a place for people to live—a place that would make you feel good, a place where everyone would just get along. And there was the timing: Columbia was founded in the mid-sixties and started its initial growth spurt in the 1970s.

In standardized fashion, villages and neighborhoods were often named after literary figures with streets being named after lines in their works. That standard resulted in street names like Evening Wind Lane, Wood Elves Way, and Plaited Reed. No Main Street. No Church Street. No School Street. Sure, there are some boring people in Columbia, but Columbia has spawned some interesting people, too, including the following:

The late Randy Pausch: The Carnegie Mellon professor who gave us “The Last Lecture: Really Achieving Your Childhood Dreams.” This one touched home, as his mother was an English teacher at the high school I attended.

Michael Chabon: Pulitzer prize winning author. I like to think that Mike’s rich writing style was informed by the literary tradition of Columbia street names. But that might be a stretch. I think he just has a gift.

Dave McClure: Founder of 500 Start-Ups and a rule breaker if ever there was one.

Aaron McGruder: Of Boondocks comics fame; another iconoclast.

Edward Norton: Okay, he’s just the grandson of James Rouse, but cool nonetheless. I mean, Fight Club, right?

All this is to say that, contrary to popular belief from some of my clients, standardization does not have to give way to things boring or flat or uninteresting. It doesn’t mean that the standardized interface can’t be beautiful, or that your customer’s experience of your seamlessly integrated process that takes them from desktop to mobile to call center won’t be sublime. The belief that standardization necessarily leads to the boring and uninteresting is too simple. It’s what’s going on inside the structure that is important. You could have a beautiful, old, organically grown, charming town with nothing creative going on for it except that it looks good. Or you can have tract housing turning out really interesting people, music, and thought. It’s all about the substance and interactivity of the interior. What comes out of a community, planned or unplanned, is really contingent upon the intention and people within it.

DO’S AND DON’TS

DO: Remember that standards are normal. Most things operate within a standards-based framework. Find the right framework that will work.

So, if you’re going to take the time to establish and implement a standards framework, it had better be around the right intention. And that intention is expressed through your digital strategy. Your standards are the tactical manifestation of your strategy that will bring into existence the intent of your digital strategy. That’s why organizations that have no real digital strategy struggle so much with coming up with a quality online presence and why their digital team spends so much time arguing and debating about standards. In the absence of clear business intent, standards can be left up to a matter of taste and debate. So, if you are undertaking to develop standards without first having defined a digital strategy, you may develop a standards-compliant website and have consistently moderated social channels. But your digital target will likely not resonate as well as it could with your customers. Only standards derived from clear vision have the capacity to create a high user experience and deliver on the mission of your organization.

DO’S AND DON’TS

DON’T: Confuse freedom of speech with freedom from standards. Those are two different things.

I was lucky. I learned early that standards could enable rapid growth and provide a framework for coherent development, all the while creating a space for real creativity. Standardization can be, and often has been, the platform for creative and important work. But I’ll go further. Standards, in fact, might be an essential ingredient. Standards frame and limit what you can do so that you can get across a certain message or get a particular piece of work done. And that’s the message you should carry to digital teams who are reluctant to adopt a standards-based framework.

Likewise, you can have a World Wide Web operating within the open standards of the W3C with the whole of humanity trying to express itself freely and creatively, or you could have something else, like an Internet and Web controlled by a few businesses and political interests. It’s about clarity of intention and the quality and sustaining quality of your implementation. It’s about having a vision and figuring out how to make it happen and holding true to your aims and your standards.

Why Digital Standards Are Important

Practically speaking, having digital standards enables an organization to put into place details for execution so that digital work can be performed consistently and effectively. From a governance perspective, knowing who has the authority to define standards saves time by minimizing the time that resources spend making decisions about the same factors, over and over again. For instance, it’s good to know which Web browsers your organization’s digital presence supports, what fonts you use for mobile applications, and when and where it’s acceptable to use your organization’s mark. It might also be good to know that your organization operates on a .net platform, or that when you refer to staff on a public website it’s always “Ms. Welch-man” and not “Lisa.”

In an ecommerce environment, standards make sure that the right content gets to the right customer at the right point in the sales cycle. For example, it’s good for customers to know that whatever they are buying on a site, the sales checkout process will be the same. And it makes customers more comfortable knowing that whether they are purchasing a pair of trousers or a jacket, they will still have the same interface for toggling between garment color choices. In addition, it doesn’t just make the user’s task easier to accomplish, it also takes stress off internal digital workers.

Adopting a standards-based framework takes the stress out of development. When you have standards in place, more time can be spent having conversations about the substance and purpose of the work that is to be done instead of arguing about the details of execution or who has the authority to make decisions about application coding standards or a graphical user interface.

Standards Enable Collaboration, Creativity, and Growth

Many things that people value operate within a standards-based framework, as these examples and Figures 5.2-5.4 show: DNA, Julian calendar, TCP/IP, Equal Temperament, XML, Haiku, 24-hour clock, punch cards, alphabets, metric system, musical notation, and movable type.

image

FIGURE 5.2
Music is based on definitive standards.

image

FIGURE 5.3
Human beings are based on standards.

image

FIGURE 5.4
The Internet operates over a standards-based framework.

Identifying a Standards Steward

NOTE CHARACTERISTICS OF A STANDARDS STEWARD

A standards steward should have the following characteristics:

• Should be a digital generalist.

• Have a “forest” view of the organization’s digital presence.

• Have a librarian’s head for organization

NOTE RESPONSIBILITIES OF A STANDARDS STEWARD

The responsibilities of the standards steward are the following:

• Ensure that the full standards lifecycle (see Figure 5.5) is addressed for each standard.

• Create and prioritize list of standards for definition.

• Develop a standard format for standards documentation.

• Measure and report on standards compliance.

An organization’s digital standards steward’s job is to establish and maintain a standards-compliant environment within the organization (see Figure 5.5). Standards compliance exists in an environment where certain activities have occurred:

• Standards have been defined and documented.

• Standards have been effectively disseminated to all digital stakeholders.

• Standards have been implemented.

• Standards compliance is measured and managed.

The reason why most organizations have trouble with standards compliance is because they miss or incorrectly address these activities and then are only left with one alternative—to enforce (usually undocumented) standards after the non-compliant content and applications are already posted (or nearly posted) online. This reactive dynamic can lead to a stressful dynamic for digital teams. Too often, the core digital team is perceived as the last-minute bad guy, telling teams that the look and feel isn’t right or that the flow of the application screens is unusable.

image

FIGURE 5.5
Creating a standards-compliant environment.

The core digital team shouldn’t be in the position of having to ask their colleagues to remove content and applications that might represent weeks or months of effort. In the best of cases, the organizational standards steward is not an enforcer, but someone who is able to create an environment where bad things don’t get online in the first place. Let’s take a look at what the standards steward does to make that happen (see Table 5.1).

DO’S AND DON’TS

DO: Make a distinction between policies, standards, and guidelines. Each of these serves a different purpose—to protect the organization, ensure online quality, and guide tactical behavior, respectively.

NOTE PROCEDURES

Procedures (also known as standards operating procedures) are as important as policies, standards, and guidelines. In practice, procedures are used as a medium for conveying execution requirements in an organization. While policy and standards define basic constraints and specific protocols for digital development, a procedure outlines exactly how to execute policy and standards. When policy, standards, and procedure are effectively teamed, they provide a clear and concise direction necessary for consistent digital operation.

TABLE 5.1 IS IT A POLICY, A STANDARD, OR A GUIDELINE?

Policy

Standard

Guideline

What is its function?

To manage organizational risk associated with operating online

To specify development protocols

To steer resources into making the “correct” decision in a subjective context

What does it protect?

The enterprise

The quality and effectiveness of the digital presence

Digital quality and organizational norms

Who codifies and maintains it?

Legal; senior management or compliance division; board; human resources

Digital subject matter experts; technologists; marketing experts; communications experts

Guidelines are often not formally codified but are recommended to stakeholders

Who informs?

Legal; compliance; various digital and organizational subject matter experts

Business and digital stakeholders; industry expert best practices; W3C and other technology standards and protocols

Industry best practices; organizational cultural norms

Standards Definition and Documentation

If you want your extended digital team to follow your standards, it’s important to write them down. This might seem self-evident, but many organizations, when asked, are unable to produce documentation of the standards that they claim their stakeholders will not comply with. This “I’m an expert, so do what I say” dynamic is hardly fair to digital stakeholders because these stakeholders often have some digital domain expertise and are heavily impacted by the business outcomes of their online efforts (so they are informed and they have a vested interest). Here are a few things to keep in mind when documenting standards.

Develop a standard for documenting standards. The first standard you should define is the structure you will use to document your standards. Having a consistent format for standards will allow your digital team to be able to access the information more efficiently and will enable you to consistently cross-reference standards. You also want to consider the platform you will use. A wiki can be a good platform for documentation. It allows for revision and version control and can be accessed by multiple standards authors. Some standards can also be integrated with various digital production systems [like a Web content management system (CMS)] so that the standards appear in the context of a workflow. For instance, there might be ready access to editorial and design standards within the context of a text editor in a CMS.

Determine what should be a standard. There is almost an endless list of standards that can be defined. It’s important to figure out which ones are most relevant to your organization. For instance, if your organization is getting ready to ramp up on mobile, standards related to responsive design might be important. Or, if your organization’s aim is multichannel content delivery, component content authoring standards might be a priority. Sometimes organizations will place high priority on documenting standards that have caused a lot of debate, such as graphical user interface or information architecture. Let your own organizational dynamics drive the standards prioritization process.

Leverage what you already have. The standards steward will also need to understand what standards your organization has already documented or where a digital standard can be largely informed by an already existing standard. Brand guidelines, style guidelines, applications development protocols, compliance mandates, and records management schedules are examples of information that might help inform or greatly impact the substance of your standards. It’s important to perform an audit and detail what information exists and where it is. That way, when standards authors sit down to write standards, you’ll be able to reference relevant standards easily and consistently.

Standards Dissemination

A common problem in digital teams is that they’ve often forgotten that their internal digital stakeholders are users as well. Typically, the experience of accessing and understanding digital standards for internal users in organizations is very low. For example, if you are a digital stakeholder trying to understand the rules of development for your organization, you are probably not interested in browsing through a beautifully designed PDF of a style guide. You just want to find the information quickly so you know, say, what font color to use for a visited link reference. The digital standards steward can help facilitate that information by being more strategic about standards dissemination.

Tell people about the information. If you have established a digital community of practice (CoP) inside your organization, be sure to discuss new standards and standards revisions as they arise. Frequently, resources aren’t told that a standard has changed until the standard is violated. Digital CoPs are effective because they bring together all the people in your organization who work with your digital channels. As you’ll see in Chapter 8, “The Decision To Govern Well,” these communities are ideal for sharing information and for training.

Web or Intranet-enable your standards repository. It is essential to produce standards in Web-ready format. Often, digital standards are authored in word processing applications or published as large PDF files. Instead, organizations should make an effort to leverage the power of the hyperlink, making it easy for stakeholders and developers to click through to corresponding and related digital standards (and policy) to get the whole picture. Sometimes, there may be standards that individuals would not typically seek on their own, but might be relevant to their work at hand.

Standards Implementation

Digital standards stewards usually feel that their job is complete when they have documented the standards and placed them online. In reality, their job has just begun. The real work lies in ensuring that the standards are implemented.

Use tools. When possible, an organization should use tools to implement and ensure compliance with digital standards. If content contributors and developers must build through a narrow standards-based gate in order to get their content on the server, it’s less likely that you will end up with “rogue” or non-compliant content and Web pages. You can help support the implementation of standards for visual design page structure by establishing templates in a Web content management system. For example, you can raise the quality of writing by implementing an editorial review process and workflow. If you have certain metadata tagging requirements for an online catalogue, you might implement a sophisticated auto tagging system.

This is a straight gate and narrow way, however, and not all outcomes can be achieved via tight constraints. Certain standards, particularly some editorial and design standards, need to be implemented via other means, such as employee training and education.

Training and education. Not everything that is a standard can be implemented with a tool. Certain editorial concerns, for instance, might require training from internal or external experts. Many teams have found value in providing education for areas like writing for the Web or graphic design for the Web. You often won’t get 100% standards compliance with training and education. People are unique, and they will interpret standards in different ways. At the end of the day, this means that you need to staff your digital team with the right people and trust them to do their job correctly.

Standards Compliance Measurement

Hopefully, if you have defined, disseminated, and implemented your standards well, compliance will be high. Still, websites and intranets are large, complex environments. Even in the best of circumstances, standards will be misunderstood or ignored in haste. That is why it is import to measure standard compliance in a consistent and automated way. You can monitor standards through spot checks and prepublication reviews, but in a large production environment, this is often a daunting task. Implementing a website auditing tool is often helpful because it allows the core digital team to provide quantified reports on things such as broken links, terminology language use, usability, compliance, and SEO. Reporting back to stakeholders about which standards they are upholding and which they are not, and creating a plan to lead the team to higher rates of compliance, is a more positive method of standards enforcement than threats that content or applications will be removed from the server.

DO’S AND DON’TS

DO: Make sure that you have a way to measure whether digital workers are complying with standards. If not, consider making it a guideline instead.

Even after you’ve implemented your standards lifecycle, there will still be exceptions to the rule. There will be times when digital workers will want to break with the standards. And then each organization will have to determine when it’s okay to break the rules and when it’s not. These types of situation can be touchy, particularly if the resources involved in the standards breach are fairly senior in the organization (like a CEO who insists on having the picture on a homepage or wants to write lengthy, dense blog posts). In the end, these types of situations will have to be negotiated by the standards steward, authors, and the “standards breaker.” During the discussion and negotiation, it is important to emphasize how the business is being put at risk due to a standards breach and how the business could benefit if the standards were complied with. At the end of the day, you’ll never have 100% compliance, but hopefully the vast majority of your digital presence will follow the rules as defined by digital standards authors.

Identifying Standards Authors

The standards steward has a very important job, but his role would be unnecessary without the information the standards authors provided.

NOTE CHARACTERISTICS OF STANDARDS AUTHORS

The standards authors have certain characteristics:

• Have specific digital domain expertise.

• Are able to explain the rationale and context for the standard.

• Enjoy staying abreast of digital trends in their areas of expertise.

Anatomy of a Standard

Every organization will have its own way of documenting standards. But here are some components to consider when deciding on an appropriate format (see Figure 5.6).

Forms Creation Tool

image

Standard Title: This area is self-explanatory.

Standard

InfoPath 2007 forms creation tool shall be used for forms on all Web pages that use underlying Microsoft Web technologies (e.g., IIS, Share-Point, SQL Server) and development platforms (e.g., Visual Studio .NET). Where these underlying Microsoft Web technologies are not used, a form creation tool compatible with the XForm standard will be used.

image

The Standard: Express your standards clearly and succinctly. Be sure to provide examples, code snippets, images, and anything else that will illustrate the standard and foster compliance.

Rationale

InfoPath 2007 is an XML Forms tool, included in the Enterprise License that the enterprise has with Microsoft. Using this tool allows the business to collect all responses in an underlying database structure, preferably to a network database store as a SharePoint list, a SQL Server table or relational database, or a metadata repository.

image

Rationale: Even if people agree with a standard, they’ll be more likely to comply with it if they understand why the standard has been put into place, so give the rationale for it here.

Related Policies, Standards, and Guidelines

1.15 Text-only pages

1.3 Electronic forms (accessibility)

2.1 Forms Creation Tool

2.2 Survey Tool

2.5 Portals

2.7 Website and Web page creation

image

Related Policies, Standards, and Guidelines: No standard lives in a vacuum. It likely has a relationship to other existing policy and standards—some Web related and others not. Listing related standards and hyperlinking to them helps create an ecosystem of standards and supports an environment where compliance is the norm.

Author

Core Web Team

image

Author: This is the place to list the decision maker for the standard. When standards are published on an intranet, an email link to this “owner” is useful in case someone has a question or a request for revision.

Last Updated

August 2008

image

Last Updated: When was this standard last revised? Often, teams try to update the whole “book” of standards on a regular basis. This is an unrealistic and ineffective method. Individual standards have their own lifecycle. Update them when required; otherwise, leave them alone.

FIGURE 5.6
Forms Creation Tool standard.

NOTE RESPONSIBILITIES OF STANDARDS AUTHORS

The responsibilities of standards authors include the following:

• Draft protocols and other tactical instructions for digital development.

• Conceptualize implementation schemes for standards.

• Express metrics for evaluating standards compliance.

• Conceptualize training paradigms and processes for standards compliance and communicate them to the digital support team.

When people call for governance help, the core problem—perhaps wrapped in a lot of detail about projects, workflow, personalities, decentralized management, and technology—is that resources within the organization are locked in a debate about who gets to decide the substance and content of digital standards. The resolution to this debate is simple: digital standards should be defined by those who have relevant domain expertise.

For example, design standards should be defined by staff who have expertise in areas such as typography and color. Editorial standards should be crafted by those with expertise in Web writing and content strategy. Standards related to publishing and development should be written by those who understand Web content management systems technologies and how best to author content so that it can be effectively moved around and delivered by those systems.

This relationship between domain expertise and standards definitions may seem self-evident, but it’s often ignored inside organizations. For example, it’s not unusual to find graphical design standards and norms being established by applications developers, and conversely, infrastructure technology standards being established by marketing writers with little to no digital domain expertise. And business stakeholders, who often have no skills in digital development at all, are often adamant about the supremacy of their opinions about things like information architecture, Web content management systems, and the use of social media. This phenomenon happens for a few reasons:

Staff assume that since they are doing the work, they have the authority to define how that work gets done. That’s usually not a valid assumption. A lot of this assumption finds its roots in the fact that the Internet and Web are relatively new platforms for business and in the early days there was a natural compression of skills in website development. The traditional webmaster did do everything—configure the server, make the graphics, and write the content. But today, 20 years into the commercial Web, there are resources that specialize in certain aspects of digital and often have 10–20 years honing that expertise.

Business stakeholders assume that because they have a vested interest in the outcomes of digital that means they should be allowed to make key decisions about how digital is deployed. This is only somewhat true. What this really means is that they ought to be around the table when the digital strategy is being defined, rather than telling information architects that all their links need to be on the homepage.

Many aspects of digital touch on areas of expertise that have traditionally been the domain of the marketing communications team or a technology team, such as graphic design and infrastructure technologies, respectively. There is an assumption of expertise or ownership because some digital disciplines have a lot of functional similarity or the skills sets are superficially similar. But just because a staff member has the expertise to select and integrate a customer relationship management system, and has been doing that for 15 years, doesn’t mean that she understands Web content management systems or search engine software. And just because a writer has written marketing copy for 10 years, doesn’t mean that he automatically knows how to write content in an environment where a component-based, multichannel content delivery strategy is in play. Of course, organizations should leverage the expertise of these resources while understanding that skills and methodologies likely don’t transfer one-to-one to digital development.

DO’S AND DON’TS

DON’T: Assume that all the digital knowledge resides on your core team. Distributed team members can also be (and often are) serious digital domain experts. Make sure that you leverage their knowledge when getting input for developing standards.

So the history of bootstrap, make-it-up-as-you-go-along collaboration around the Web has led to a high degree of participation and ownership by many stakeholders. Because of this dynamic, core digital teams and the management that empowers them with the authority for standards authorship find themselves in the difficult position of having to rescind assumed authority for standards definition from other digital stakeholders. This is never a fun situation, although that is exactly what needs to happen in many organizations. It doesn’t mean that these stakeholders cannot provide input for standards definitions—just that they have to do so within a defined set of parameters.

Finding the Experts: Input vs. Decision-Making

Over a decade ago, I worked with a large governmental organization. When I started talking about governance and decision-making, they informed me that they made decisions about standards by consensus. That meant that the entire group needed to eventually come to the same conclusion about what ought to be done online. Everyone. All agreeing to the same thing. I accepted that. It sounds good, right? It sounds nice and fair.

But as time passed and I saw the model in action, there was something that always struck me as being impractical about it. How likely is it that 40+ people (the size of their Web manager community) were going to agree about the diverse set of standards that support digital? Actually, in practice, most of the time they agreed about things. But sometimes, for key things like information architecture and infrastructure product selection, there was fierce debate. It was obvious that the whole thing would come to a head at some point, and it did. After a few years of avoiding making decisions about key standards, I watched as the organization was held back from making a good technology choice due to the disagreement of a single individual. I liked this guy. He was sharp and a strong digital domain expert.

The problem was that he was both right and wrong. He was right that the technology wasn’t the number one choice for the particular needs of his areas of the website (although it was adequate). At the same time, he was wrong because the technology was the best choice for the organization as a whole. He was trying to maximize the outcome for his department’s needs, not for the entire organization. In fact, it was hard for him to even see the broader perspective. But his position meant that the whole team couldn’t move forward. And they didn’t—for years. What a mess.

In a stroke of timeliness, I happened to be reading Peter Weill and Jeanne Ross’s book on IT governance (IT Governance: How Top Performers Manage IT Decision Rights for Superior Results). There is a lot to take away from that book, but the thing that stood out for me and provided me with guidance was the distinction they made between providing input and making a decision. It’s a distinction that seemed obvious after I read it, and it seems obvious to Web teams when I introduce the concept to them today. But I still get delighted when I watch them have an “ah ha” moment when they realize that they may have had their last standards stand-off.

So how does this apply to digital standards?

When making decisions about standards, there are two different constituencies: those with an interest and those with the authority to make the final decision. Typically, those with the authority are the people who have the following background:

• The expertise to craft a good standard.

• The authority to do so (with senior management’s blessing).

I realized that this was what was missing in the room when I talked about the Web team at Cisco Systems, who were trying to make the decision about buying a Web content management system (see Chapter 1, “The Basics of Digital Governance”). No one knew who had the authority to decide the standards.

In situations like these where the authority is unclear, things generally happen:

Someone steps forward and assumes authority, and the group accepts the authority. If the individual who steps forward is a domain expert and he has done his homework about the organizational and functional needs, then you might get a good outcome. If he hasn’t, then you’ve got someone with a lot of chutzpah, but he won’t necessarily lead to a good standard.

More than one person steps forward and assumes authority, which often creates factions. In the instance where two people step forward, you can still have the same result: the scenario where they might be making a good or bad decision, but you also have to deal with the more likely scenario that these resources who have assumed authority probably won’t agree on what the standard is. That’s how the endless debate starts and never stops.

No one assumes authority, and the process stalls. In this situation, the organization simply doesn’t make a decision. They just have a lot of meetings talking about things, but ultimately don’t move forward. In situations where there is no governance, business units or other organizational subdivisions usually just do their own thing. This is how incongruent technical and information architecture paradigms start and are sustained.

Luckily, you don’t have to settle for one of these less-than-optimal situations. You can clear up standards authoring authority by completing a simple exercise.

Input and Decision-Making Exercise

Use this matrix shown in Table 5.2 to clarify digital standards decision-making. It’s a simple but powerful exercise. You can create one for each standards area and for specific digital properties. List your stakeholders on the left and then tick off who will be providing input and who will be making decisions. You can use the four standards areas outlined in Chapter 1 (Design, Editorial, Publishing, and Development, as well as Network and Infrastructure). Or, if those areas are too broad or narrow, break them down or flatten them.

TABLE 5.2 INPUT AND DECISION MATRIX

Stakeholder

Input

Decision

Marketing

Communications

Legal

Human Resources

IT

Digital

Those people with an interest in the substance of a standard should provide input or context so that those people with expertise can effectively determine what the standards should be. This is the way to be inclusive without having to come to consensus about everything. An “interest” could mean that you are responsible for the integrity of the corporate brand, or it could mean that you are a content contributor that has to use a Web content management system on a daily basis. In many ways, providing input is like expressing requirements for standards. After those requirements are expressed, those with expertise can take the full picture into consideration and define the protocol. This input also gives the decision-maker(s) enough insight to know how to react to ever-emerging technology trends, so they know when to revise or remove ad standards or when to create new ones.

When you perform this exercise (see Table 5.3), you will see decision-making patterns arise quickly and also get a few surprises. One of them will be that the core digital team where authority for much of standards authoring often resides is often in complete agreement with their digital stakeholders. When these standards are discussed outside of the context of a pressing deadline, resources find that they all want the same thing: a high-quality effective digital presence.

TABLE 5.3 INPUT AND DECISION MATRIX FOR GRAPHICAL DESIGN STANDARDS

Stakeholder

Input

Decision

Marketing

X

X

Communications

X

Legal

Human Resources

IT

X

Core Digital Team

X

X

CONTENT GOVERNANCE

image

Ann Rockley, The Rockley Group

One of the primary goals of structured reusable content is the ability to create content that can be automatically published to multiple channels and dynamically adapted to customer needs and devices. To reach and maintain these goals, you need to have governance. Creating content or making changes to the structure in an arbitrary way can result in partial or full loss of automation, not to mention the loss of productivity and translation savings. Governance is critical to success!

Summary

• Standards articulate the exact nature of an organization’s digital portfolio and are put into place to enable digital workers to work collaboratively and effectively in a decentralized environment.

• A standards steward is a digital generalist responsible for ensuring that all standards are written and the full lifecycle of standards compliance (definition, dissemination, implementation, and measurement) is considered.

• Standards authors are responsible for defining specific protocols for digital development. The authoring of standards is usually distributed to a number of digital domain experts.

• Organizations should have clarity regarding who provides input and who makes decisions about standards. Standards authors should gather input from organizational stakeholders, and that information should be gathered before defining standards.