Welcome Salesforce Community

View Latest Videos on YouTube Follow on Twitter

Portal Governance – Solid, Long Lasting Foundations

Portal Governance – Solid, Long Lasting Foundations

If you were going to live a house, wouldn’t you want it to be built on top of a solid foundation that underwent periodic inspection? For whatever reason it may be easy to get the impression that a particular technology platform will inherently take care of governing portal deployments. After all – mature portal platforms have security, user groups and taxonomies that a vendor indicated will help govern the content, right?

Setting off on a portal deployment or adding elements into an existing portal deployment without a well thought out governance strategy is unfortunately a path to disaster. Do not be fooled into thinking that by virtue of having an enterprise caliber portal platform somehow governance will magically be take care of. Just as with any technology project it takes expert planning to create a solid, long lasting foundation that will make the platform easy to manage.

The good news is that by following some basic guidelines your deployment can start on top of a solid foundation and stay healthy over the course of its lifespan. Implementing proper governance will arguably add a level of overhead, but once your deployment grows beyond a trivial level, it will provide some serious returns and create efficiencies for users who are developing or contributing within the platform. To keep this guide platform agnostic major content or application areas within a portal will be referenced as a “Collection”.

Collection Lifecycle Methodology

1. Request

The Request exists to formally review and approve any collection that a user would like to propose for inclusion. This process is critical, as without it no responsibility is associated with the content and other components that may be created and it is no longer possible to manage the content lifecycle.

a. Define Purpose and Ownership – a clear purpose needs to be articulated for the Collection. This will determine if the Collection and its components are suitable for inclusion within the portal. In larger deployments this portion of the request would be vetted within a steering committee, during regularly scheduled meetings. Within smaller deployments or if this Collection were to be included as a sub section of an existing Collection, the inclusion could be determined by the parent Collection owner. This is generally applicable for a department or functional group within an organization.

Explicit ownership of the Collection is imperative. Not only should a named person be accountable for the Collection and its contents, but the group that they belong to must also have ownership. It is not uncommon for people to change roles or exit an organization and therefore there must always be a parent owner associated with the Collection. This can default to a generic spot within the organizational hierarchy. This spot must be amenable to the responsibility and its duties (see education 1.d below) to this in order to have the ability to create a Collection.

b. Establish Metrics / Success Criteria – it is important to establish metrics and or success criteria by which to judge the collection during audit periods (detailed below in 3.a). This is critical to avoid the danger of having a portal deployment loaded with irrelevant content that complicates navigation throughout the portal and presents challenges around quality and relevance of search results within the portal. One common criterion might be monthly usage or another objective metric. For information that is an “artifact” like 401k information (see “Technical Tips”) it is possible that the content must exist regardless of metrics and its success criteria is simply inclusion.

c. Functional and Technical Specifications – just as with traditional software development, some level of functional and technical specifications are appropriate for the project and should be submitted with the request. Given the broad range of what may be deployed within a Collection there are wide differences in the level of depth that is required.

Generally there are two different classes of specifications that may be needed – one that pertains to an application that will run within the portal and another that relates to content that will reside within it. It is suggested that this is done only to the extent that it will make sense for the deployment and not act as substantial overhead to everyday management of the portal.

d. Education and Time – education requirements are just as important as ownership and success criteria. Any person or department that is requesting a collection must allocate time for the owner to receive training that is verified and commit to allocating weekly or monthly time for that individual to participate in the maintenance and development of the collection items. If this is not possible the Collection request should be denied. In order for any Collection request to be approved the management responsible for the request must allocate time for the Collection owner to tend to what has been created within the Collection.

2. Create

The Create phase is relativity straightforward. It acts as a gate to ensure that the materials being produced conform to the original vision and are ready for release to their specific audience. Generally the Create stage is very specific to an organization’s established development processes, so a rough outline of generic steps is presented below.

a. Create – create the Collection on the basis of what was defined in 1.a and 1.c. The creation should be completed in a development environment or sandbox environment where the Collection owner has the ability to privately test what they are doing without interrupting typical usage of the portal environment.

b. Secure – any security criteria that may have been part of the request in 1.c should be enforced at this point, even if it is being constructed within a sandbox or development area. Leaving this step until a launch into a production environment could create serious unforeseen complications.

c. Check – review what has been developed against the purpose that was outlined in 1.a and 1.c above. If a delta exists between the two – either revisit 1.a and 1.c and update it based on the new needs or adjust what has been deployed to conform to the specifications that were outlined.

d. Launch – if the check stage above has been passed, deploy the Collection to the portal for consumption by the intended audience. The Collection will now enter the Manage phase of its lifecycle.

3. Manage

This stage should be performed on a quarterly basis or as makes sense based on the nature of the collection and availability of resources. It provides an opportunity for the portal to stay current and to continue to provide high quality, relevant material to end users. Although it may seem like a large investment in time, its results prove very cost effective with regard to worker productivity and the aversion of significant costs associated with a deployment that has become unmanageable.

a. Audit – based on the metrics and success criteria that were outlined in 1.b review what has been deployed and how well it has met the expectations that were created for it. If the Collection is not meeting the objectives that were outlined for it should be decommissioned as outlined below in step 4. The audit should also include a review of ownership to ensure that a specific individual is still accountable for the contents of the Collection. Due to resource constraints it is fair that the audits take place on a quarterly schedule or as possible based on available resource levels. The people conducting the audits should be from a Business Analysis role that interfaces with the various groups seeking to build Collections within the portal framework. If the audit is failed for other reasons, such as lack of meta-data on various parts of the Collection, the owner(s) should have a fixed amount of time to correct the issue.

4. Retire

Retirement provides for the methodical removal of Collections or content that have not passed the audit stage. This process has to be completed by the respective Collection owner to avoid any unintended removal of valid content.

a. Close – if a Collection or part of a Collection fails audit or is no longer relevant to the deployment it should be removed from the portal. This is very difficult for most organizations to achieve due to a lack of obvious ownership around content, but there is compelling value to the user experience in doing so. The person responsible for the removal of the Collection or pieces within it should be the owner.

Technical Tips

Even though a technology platform does not automatically provide governance, it can do many things to ease the pain around providing a layer of management on top of Collections. There are a few basic, expedient ways to add a lot of value and reduce the time consumed by the governance process.

1. Owner / Department Information – always associate this information with any Collection and the contents within it. Most portal platforms have the ability to associate meta-data with a wide range of objects. This meta-data is generally searchable and through saved searches or various queries it is possible to filter, sort, view and administer a Collection and its items from this data. This will allow for valueable reports around this information to be quickly created during the audits or otherwise.

2. Content Type (artifact vs perishable) – content generally comes in two forms – artifacts and perishable content. Artifacts are items like annual reports or a dental plan for 2006. They are static and will not change over time. Generally they are needed for reference and have unlimited lifespans within a deployment. Perishable  content might be various project documents that are only relevant for a short period of time before needing to be archived or removed from a portal. Just as with owner and department information, it is extremely beneficial to flag this information to allow content to quickly be sorted and evaluated for removal from the portal deployment.

3. Time Stamping – as mundane as a time stamp sounds it is very useful to help sort and act on content to keep a portal deployment running cleanly. It can be leveraged just as the above 2 elements to assist in report generation and auditing.

Wrapping Up

The general framework outlined above provides a clean, straightforward model to help govern a wide range of portal deployments. Whether the deployment is external or internal to an organization or provides content or applications, it will help any organization to keep a firm grasp on their deployment. Although some initial investment is needed, the usability and management benefits of a properly governed portal deployment far outweigh the effort for ongoing enforcement. If your portal is a crucial tool for your organization it is imperative that a solid governance framework resides on top of it.

Related Articles

0 comments