Web Governance in the Age of Portals

Web site technology promised organizations the ability to easily post information for employees, partners, suppliers, and customers; however, its simplicity was and still is rarely reined in through proper governance processes. Accordingly, customer-facing sites have been plagued by inconsistent design and branding, chaotic navigation and administration, and even conflicting information due to mergers, acquisitions, and divisional decentralization. Employee sites (intranets and employee portals) have faced isolated site development that makes finding information across sites difficult as well as inconsistent design that can diminish corporate unity and efficiency. Extranet sites (partners and suppliers) have created confusion among users by offering numerous seemingly separate systems to access relevant information, often with overlapping capabilities.

META Trend: By 2004, portal frameworks will become the centerpiece of a delivery infrastructure that acts as a fulcrum to aggregate reusable application, content, analytical, and collaboration components for highly dynamic user interfaces. By 2005, organizations will exploit portal frameworks to deliver contextual business workspaces, enabled via maturing XML and Web service standards. Through 2007, portal vendors will increasingly leverage enterprise infrastructure services.

Web governance uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization. Organizations are often driven to put governance processes in place via their internal or external Web sites when inconsistency threatens brand image or corporate cohesiveness, or when software and maintenance costs increase due to redundancy. With proper governance policies, processes, procedures, and personnel, site owners should maintain the freedom to create, design, and implement sites freely based on business needs within an adaptive framework that ensures the organization’s overall objectives are not compromised.

Web governance must be more than a list of standards and a compliance warning. Indeed, we recommend a three-step approach: create a statement of governance that lays out principles, enact processes for compliance, and establish a committee that will create the actual governance rules. This approach has been much more effective than those that create rules immediately as part of the governance process, because it enables the creator of a statement of governance to start with policy, then assign roles responsibilities and analyze processes within a flexible framework.

Readiness Assessment

Research has shown that an iron-fisted approach to governance is likely to fail. Web projects often demand an unprecedented level of horizontal cooperation among departments and organizations within the company. Corporate culture must be taken into account during the creation of the statement of governance, and any attempts to change the corporate culture must achieve buy-in at the highest levels and include a change-control plan, often stretching out three to five years. The results of a readiness assessment can be used to ensure the accuracy and achievability of timelines and goals:

• Is the current organizational model closer to centralization, federation, or decentralization (see Figure 1 for definitions)? Because federation is typically the preferred end state, organizations already experienced with federation can expect quicker results (all other things being equal). Moving from centralization to federation will be easier than moving from a decentralized organization.
• What is the current degree of non-compliance? Cultural change always involves a degree of difficulty, pain, and time. Organizations that are catching Web chaos (i.e., displaying an inconsistent look across sites and using multiple products and approaches for different instances of the same type of sites) early will want to implement governance as quickly as possible before different groups start developing independent processes and mechanisms. However, most organizations are now facing the pain caused by a lack of governance, which is being felt at the executive level. To proceed, organizations should execute a benchmark against a subset of proposed processes and standards to determine the current level of non-compliance.
• Is information and code sharing among Web site owners common? What incentives (or disincentives) exist for information sharing? Some organizations have encouraged information sharing by producing metrics of contributions to shared repositories and collaboration postings and have included this information in annual reviews.
• Is administration between systems centralized? Radical changes from central control to decentralization (and vice versa) will be difficult and take more time than simply changing the degree of centralization/decentralization.
• Are responsibilities and budgets for Web software and personnel aligned? Expensive central dictates with a decentralized funding model are more likely to fail.
• What is the expected rate of organizational change? Mergers, acquisitions, and reorganizations greatly increase the need for Web governance policies, processes, and standards. If major organizational change is upcoming, Web governance should be accelerated (if possible) to help with the transition.
• Are there legal agreements that will help ensure compliance? For example, in a franchised organizational model, there may be obligations of franchisees to protect brand identity that can be leveraged to ensure compliance with design standards.
• Is there a statement of governance (SOG) from another area that can be adopted as a model for the Web? Organizations often have governance established in other areas that can be leveraged for the Web. The most applicable statements of governance are other knowledge management areas such as content management and business intelligence.

Start With a Narrow Scope and Expand Over Time

The scope of the policy must be selected carefully. Scope can be narrowed to a particular organizational unit or horizontally for a particular process. Governance boards often start by governing the current pain point and expanding its scope later. Common pain points include the following:

• The need to drive a consistent brand image is hampered by inconsistent divisional B2C sites (e.g., inconsistent navigation, reference to parent site, look and feel, use of technology, conflicting content)
• The need to drive corporate spirit is hampered by inconsistent regional, agency, or departmental sites
• Proliferation of B2E sites
• Diminished ability to find and share information
• Redundant technology purchases
• Mandated compliance issues (e.g., HIPAA, SOX, USA PATRIOT Act, Basel II)

Creating a Web Site Statement of Governance

The SOG should be kept as simple as possible. Deciding what not to govern is as critical as deciding what to govern. Voluntary information sharing should not be discounted for areas where formal governance is not necessary. An organization may decide not to govern a process (i.e., forcing portlet reuse) but may enable sharing mechanisms (i.e., creating a portlet library that all can contribute to).

The core of the SOG should address people, policy, and process (see Figure 2). It should be wrapped in an introductory section that describes scope of the document and conclude with a description of the metrics that will be put in place to measure the impact of the governance.

People Issues to be addressed in the SOG include the following:

• Who creates the governance guidelines?
• What roles/teams are involved in day-to-day operations?
• Who reviews sites and site plans to ensure compliance?
• If there is no centralized authority, who gets authority to create standards?
• Will governance be centralized, decentralized, or federated?
• Should the same team create the governance guidelines, compliance guidelines, and standards?

Governance over Web site policy and process is usually assigned to a group with a name such as “advanced technology,” “Web technology,” or “Internet technology.” This group acts as a subcommittee beneath the IT steering committee, which is, in turn, a subcommittee of the executive steering committee. In many organizations, these groups may be further segmented by internal and external sites. In all cases, the committee comprises business and IT representatives. This group must be treated as a standing committee and not a temporary working group that disbands after initial governance is put in place. Although the governance committee may reside within this group, it should contain representatives from the divisions/regions covered by the scope of the governance procedures. Many organizations may have a compliance officer or a governance board; these generally relate to a different form of governance and compliance (legal and regulatory) and they do not get involved with internal, best-practices governance and compliance.

It is inappropriate to have a chief executive (CEO or CIO) review and approve all the details of the processes, standards, and guidelines. The role of the executive is to approve policy and then publicly authorize an individual, role, or group to create and enforce processes, standards, and guidelines that implement this policy. For example, the following would be a reasonable description of the executive charter needed for the governance committee and the responsible individual: “We plan to continue a strategy of growth through acquisitions. To gain value from these acquisitions, we need to exploit synergies and help acquired companies become part of the Acme family. Consistency of information and branding across our internal sites is critical to this strategy. Therefore, I am appointing the vice president of the Advanced Technology Group to head a standing governance committee that will create and continually review processes to ensure that our Web sites leverage the value of the Acme name for all our employees.”

A table or organization chart in the SOG should show all the main roles involved in developing and maintaining Web sites and their responsibilities. Roles to be assigned include content creation, content approval, collaboration moderators, infomaster, site designers, site developers, and site architects (see WCS Delta 1216).

Policy
The SOG should address the following issues:

• Why should we care? Why are we doing this?
• What if decentralized regions/divisions acknowledge the overall need for governance but continue to make exceptions for their own sites because they see no value in complying in their individual case?

Site owners often greet governance with groans. A document full of dictates from above does little to persuade site owners to cooperate. Indeed, they often proceed to look for loopholes. Detailing high-level policy helps to fill the loopholes that will inevitably be present by making the spirit of the governance clear, and it enables the owners of the governed sites to understand the business rationale for the governance policies, which can help them gain acceptance.

Policy is a set of principles that are used to guide action. Creation of a statement of governance creates challenges for executives and site owners. Executives do not have the time or knowledge to buy in to detailed process guidelines, but they will often endorse business principles and anoint people (the Web governance subcommittee) to create and enforce processes in accordance with these guidelines.

Note: If an enterprise architecture or a set of Web conceptual principles from a Web domain architecture exists, it can be used to create the policy statements in the SOG.

The following types of policy should be defined:

• Design policy: Principles supporting the need for common navigation and “look and feel”
• Technology policy: Principles supporting the need for using a standard set of Web technology (e.g., browser support, application servers, use of flash/applets)
• Security, privacy, and business risk policy: Principles supporting the need for risk to the business and risk to customers/partners (i.e., legal risk) to be mitigated; legal counsel should be involved in reviewing this area
• Technology risk policy: Principles supporting the need for controlled rollout of new and untested technologies

Process

The SOG should address the following process issues:

• At what stage in project life cycles should compliance testing be done?
• How will ripple effects (changes to one site or portlet that affect other sites) be checked for?
• What approval processes will be used to verify technical and content compliance?
• What if non-compliance occurs?
• How often should this be reviewed?

Standards should not be a part of the main governance document. They are a result of the standards process and an input into the compliance process. Standards documents and governance processes will be on different release cycles, so it is best to keep these documents separate but with clear linkage (i.e., putting the standards in an appendix). Standards should come out of a Web architecture process that defines appropriate technology and methods for the common Web application patterns of the organization.

Processes that define design, technology, and people processes for Web sites should be set up. Point-in-time snapshots of the sites should be evaluated in dynamic Web site reviews (see Delta 2579). A key problem for many organizations is that Web development processes have not been formalized to the point that governance and compliance checkpoints can be inserted.

Funding and compliance are complementary. Compliance should be cheaper than non-compliance. This will always be true from the long-term, corporate point of view, but it can also be made true in the short-term, tactical case if there is centrally funded technology.

Processes to be defined include the following:

• Content approval process: This involves how content owners and site owners can submit new content for sites. Often, different processes for internal and external content exist.
• Standards process: This involves determining which standards should be set, how they will be set, how to access the most recent list of standards, and how to submit questions or suggestions.
• Compliance process: This describes how content and sites will be checked for compliance. Particular attention should be paid to the impact points of governance in development, production deployment, and change-control processes. This section should include non-compliance statement. The process for “out of compliance” is best when it is short and sweet (e.g., “Divisional VPs will be notified of any sites that are determined to be out of compliance”).

Measurement and Timelines

Executives sponsoring governance initiatives are going to demand results. This makes metrics an imperative. Metrics should relate back to the desired outcomes specified in the SOG. For example, if “maintaining integrity of the global brand name” was a policy, then a measurement could be the number of regional sites that do not conform to design standards relating to the brand (e.g., logo, company colors). Measurements of secondary importance are those relating to processes rather than outcomes (e.g., number of compliance reviews performed per quarter). Once metrics are determined, reporting procedures that describe how and how often they will be reported should be developed.

Metrics must be determined before governance goes into place to demonstrate improvement. Therefore, benchmarks should be performed while the SOG is being created. In most situations (where some degree of chaos already exists), governance cannot be imposed overnight. A timeline that shows phase-in dates for various processes (SOG completion, training, start dates) should be developed. Goals should be set to demonstrate forward progress and reining in of chaos over time, but not with the expectation of 100% compliance on Day 1 (or possibly ever).

Business Impact: A governance process over Web activities can prevent inconsistencies that tarnish brand image, decrease customer loyalty, and increase development and maintenance costs.

Bottom Line: Web governance needs to address policy, people, and processes to rein in the degrees of freedom that organizations assume with no such governance in place. Clients should create a statement of governance as the start of this effort and follow that with the creation and implementation of a Web governance process.

META Group originally published this article on 31 December 2003.