<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Information Technology Aligned&#187; Information Technology Aligned &#8211; Portal, Intranet, Governance, BPM and SOA</title>
	<atom:link href="http://www.infotechaligned.com/tag/portal-deployments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.infotechaligned.com</link>
	<description>where technology and business connect</description>
	<lastBuildDate>Mon, 29 Aug 2011 19:56:46 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Portal Governance &#8211; Solid, Long Lasting Foundations</title>
		<link>http://www.infotechaligned.com/enterprise_portal/intranet-goverenance-solid-long-lasting-foundations/</link>
		<comments>http://www.infotechaligned.com/enterprise_portal/intranet-goverenance-solid-long-lasting-foundations/#comments</comments>
		<pubDate>Tue, 02 Jun 2009 03:06:55 +0000</pubDate>
		<dc:creator>John Brunswick</dc:creator>
				<category><![CDATA[Enterprise Portal]]></category>
		<category><![CDATA[content maintenance]]></category>
		<category><![CDATA[deployment]]></category>
		<category><![CDATA[governance]]></category>
		<category><![CDATA[methodology]]></category>
		<category><![CDATA[portal]]></category>
		<category><![CDATA[portal deployments]]></category>

		<guid isPermaLink="false">http://infotechaligned.com/?p=23</guid>
		<description><![CDATA[If you were going to live a house, wouldn&#8217;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 &#8211; mature [...]]]></description>
			<content:encoded><![CDATA[<p>If you were going to live a house, wouldn&#8217;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 &#8211; mature portal platforms have security, user groups and taxonomies that a vendor indicated will help govern the content, right?</p>
<p>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.</p>
<p>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 &#8220;Collection&#8221;.</p>
<h3>Collection Lifecycle Methodology</h3>
<h4>1. Request</h4>
<p>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.</p>
<p><strong>a. Define Purpose and Ownership</strong> &#8211; 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.</p>
<p>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.</p>
<p><strong>b. Establish Metrics / Success Criteria</strong> &#8211; 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 &#8220;artifact&#8221; like 401k information (see &#8220;Technical Tips&#8221;) it is possible that the content must exist regardless of metrics and its success criteria is simply inclusion.</p>
<p><strong>c. Functional and Technical Specifications</strong> &#8211; 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.</p>
<p>Generally there are two  different classes of specifications that may be needed &#8211; 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.</p>
<p><strong>d. Education and Time</strong> &#8211; 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.</p>
<h4>2. Create</h4>
<p>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&#8217;s established development processes, so a rough outline of generic steps is presented below.</p>
<p><strong>a. Create</strong> &#8211; 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.</p>
<p><strong>b. Secure</strong> &#8211; 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.</p>
<p><strong>c. Check</strong> &#8211; 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 &#8211; 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.</p>
<p><strong>d. Launch</strong> &#8211; 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.</p>
<h4>3. Manage</h4>
<p>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.</p>
<p><strong>a. Audit</strong> &#8211; 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.</p>
<h4>4. Retire</h4>
<p>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.</p>
<p><strong>a. Close</strong> &#8211; 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.</p>
<h3>Technical Tips</h3>
<p>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.</p>
<p><strong>1. Owner / Department Information</strong> &#8211; 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.</p>
<p><strong>2. Content Type (artifact vs perishable)</strong> &#8211; content generally comes in two forms &#8211; 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.</p>
<p><strong>3. Time Stamping</strong> &#8211; 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.</p>
<h3>Wrapping Up</h3>
<p>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.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.infotechaligned.com/enterprise_portal/intranet-goverenance-solid-long-lasting-foundations/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Niche Cooking for Intranet Success</title>
		<link>http://www.infotechaligned.com/enterprise_portal/niche-cooking-for-intranet-success/</link>
		<comments>http://www.infotechaligned.com/enterprise_portal/niche-cooking-for-intranet-success/#comments</comments>
		<pubDate>Sat, 13 Sep 2008 00:37:49 +0000</pubDate>
		<dc:creator>John Brunswick</dc:creator>
				<category><![CDATA[Enterprise Portal]]></category>
		<category><![CDATA[corporate portal]]></category>
		<category><![CDATA[intranet]]></category>
		<category><![CDATA[portal]]></category>
		<category><![CDATA[portal deployments]]></category>
		<category><![CDATA[roi]]></category>

		<guid isPermaLink="false">http://infotechaligned.com/?p=8</guid>
		<description><![CDATA[Creating a winning recipe for an internally facing corporate portal is a daunting task. At the onset of a project there is a natural tendency to think that having a large target audience is the route to success and value. What has been found through practice though can actually be quite the opposite. Whether we [...]]]></description>
			<content:encoded><![CDATA[<p>Creating a winning recipe for an internally facing corporate portal is a daunting task. At the onset of a project there is a natural tendency to think that having a large target audience is the route to success and value. What has been found through practice though can actually be quite the opposite. Whether we are experienced with portal deployments or not, there are some fundamental dynamics that if carefully orchestrated can help to ensure a deployment&#8217;s success.</p>
<p>When working with powerful, versatile technology it is not uncommon to loose sight of the human element that we need to cater to for success. The &#8220;because it can&#8221; factor is tough to ignore and often initiatives tend to gravitate toward this. In order for a deployment to be successful, people need to walk away from their experience with added value. Using a restaurant analogy, this added value differentiates the quality of a portal deployment from an outstanding four star meal to an unappealingly average fast food meal.</p>
<p><strong>A Grand Opening </strong><br />
Just as with a restaurant opening, a portal deployment goes through a series of phases that ultimately will determine if the investment (servers and software licensing) is worth it.<br />
1. Grand Opening<br />
2. Quality Assessment<br />
3. Reputation Establishment<br />
4. Patronage Level Establishment<br />
5. Patronage Fluctuation</p>
<p><em>Grand Opening </em><br />
When a new restaurant opens its doors people are drawn by a mix of marketing effort and personal curiosity. In our case we are most likely going to get exposure through a corporate email or newsletter that lets people know that a new project has been deployed with the portal.</p>
<p><em>Quality Assessment </em><br />
What happens next is absolutely crucial. Users visit, or in the case of our restaurant, people eat there. This might seem obvious, but when we look at a corporate portal it is easy to overlook since we have a tendency to be drawn toward and tout features over the applicability of an experience, or meal, to the individual.</p>
<p><em>Reputation Establishment </em><br />
Users need to have a rewarding, compelling experience. With the ability to quickly communicate and multitask via email and other electronic means, people have tight schedules and are generally unwilling to incorporate an additional tool if it does not provide significant value. When they experience the portal deployment they will ask themselves a few simple questions: &#8220;Did this make my life easier? Cut down on my workload? Enable a process more effectively that my traditional communication and information management methods?&#8221; The portal will not grow or assist the business through its novelty, but by the outcome of this hard, black and white examination.</p>
<p>Based on this assessment a reputation is established about the value provided by the new service within the portal or the portal itself. This provided value is where our target audience becomes so crucial. Did we just cook generic food in an attempt to satisfy a wide range of people? Or did we cook a specialty food that directly targeted a particular group of enthusiasts? The word that spreads throughout the enterprise is based on this crucial experience. It will ultimately come down to either satisfying a small group of people who will become vocal advocates, or frustrating a large group of people with a mediocre experience and creating a stigma around the portal platform.</p>
<p><em>Patronage Level Establishment </em><br />
If we were able to deliver a satisfying meal we will have done our job to establish devoted patrons. Having this group of individuals will allow us to have sustained value within our portal deployment.</p>
<p>If we did not provide a good meal, people will say &#8220;Yeah, I have eaten there, but it was nothing special.&#8221; This means that whatever value we provided was quickly realized and then lost, leaving our organization with an &#8220;Empty Portal&#8221; or failed project.</p>
<p><em>Patronage Fluctuation </em><br />
Assuming that we did provide a good experience for our users by adding value, we will pick up positive word of mouth. This will ideally open a good dialogue between these patrons and our business and technology teams. With this communication channel we can continue to invest in shaping value for this group of users, growing out patronage. Beyond this, as more people become advocates of the platform, we can continue to develop solutions for the business members we are serving and gain even more return from our investment with additional, iterative, focused releases leveraging the portal framework.</p>
<p><strong>Getting the Recipe Right &#8211; Tips for Success </strong><br />
Continuing with the restaurant analogy, we need to make sure that when they ask for a soufflé we serve it to them instead of crème brulee (as good as our crème brulee might be). The portal is a &#8220;top down&#8221; tool and that means the business needs to dictate the direction of development initiatives with these needs. In order to make sure that the platform can best assist in driving us toward our business goals, the following items are imperative for success:</p>
<p>1. Invite Food Critics &#8211; Get participation from the business unit that you are targeting. These are the people who will be eating at your establishment. This is about what they need, not the buffet of things that you can place in front of them.</p>
<p>2. Serve Bite Sized Pieces &#8211; Remember that small is manageable. Let your menu evolve based on the demands of the business. Do not try to pack it full of choices from the onset.</p>
<p>3. Time Food Preparation &#8211; Great restaurants have impeccable timing to ensure that their dishes are served in the proper order and correct temperature. Be sure to heavily weigh the benefits of any major development portion of a project. Having one piece of the project get away from you could ruin an otherwise good project as the business will be eager to complete their meal.</p>
<p>4. Maintain Great Ingredients &#8211; Governance is essential to maintaining value for a deployment. Just because we served up a great meal the first time does not mean that we are set and can move on. We need to put controls in place to ensure that the quality of the meals stays consistent or improves over time in order to retain patrons and grow our business.</p>
<p><strong>Final Thoughts </strong><br />
Thinking back to how all of this applies to the overall value that we can provide, it is apparent that a large scale launch, although seemingly impressive, serves up less value in the long run if we are not focused on serving targeted, high value tools to our audience. We are sometimes tempted to do things just because we have the ingredients, but in order to build a thriving business, it is vital that we listen to and deliver the great treats that our customer base is interested in.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.infotechaligned.com/enterprise_portal/niche-cooking-for-intranet-success/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

