Search

Must be quick, complete — i.e. your search must index all important repositories of information, regardless of where they are housed — and Google-like. Whether we like it or not, the Google search experience sets the bar. Also keep in mind: very few of your users care about advanced/boolean search.

Secure

Must be secure, respect privacy rules/laws, and — this is key — be perceived as such by users and business owners.

Slick

Has to look professional and be consistently on-brand, otherwise users won’t take it seriously.

Responsive

Intranet team must be equipped and staffed to accommodate requests from new user communities quickly and efficiently. That said, day-to-day work (especially content updates) should never be centralized.

Governance

Have buy-in from upper management and from grass roots, as well as clearly articulated rules and processes governing business ownership. The most successful intranets don’t let any content go up without a named business owner who is accountable for it.

Here are a few ideas to spark thoughts and discussion among your team:

• Display a ‘Toolbox’ with links to functional elements
• Place content in a knowledge base with its own ‘brand’
• Identify tools with a specific icon or other visual cue
• Clearly define what a ‘tool’ is for your users: Typically a tool would consist of an electronic form which gathers one or more pieces of information, processes those data, then produces some sort of output or outcome (e.g. a Change of Address tool whose outcome is that official paperwork is routed to your new address when you move, a financial report whose output is a printable list of results for a range of dates, or a ticketing system whose outcome is the resolution of a technical problem)
• Design the UI in such a way as to guide users to make the choice between information seeking and task completion up front
• Make universal search the sole – or primary – route to content, while using a navigational structure to guide users to specific tools (i.e. HR tasks are available in the HR section, IT tasks under IT)

1. It gets you and your team to think clearly about what you are trying to achieve, how you will get there, and who will have to participate if you hope to be successful.
2. It can be a crucial means of communicating your goals, as well as the specific responsibilities associated with governance and the day-to-day operation of your site to your executive sponsor and other stakeholders.
3. A charter is often where you will get sign-off to proceed from decision-makers responsible for allocating funds.

Here are some of the key things you should consider including in your charter:

• A clear statement of the purpose/goals of your intranet
• A description of your governance model, including roles and responsibilities related to business ownership and accountability
• At least a broad definition of the audience(s) you are aiming to reach
• Rules for content (e.g. currency, style, approvals, specific exclusions such as gossip, personal info etc., translation requirements) as well as how these rules will be enforced
• A statement outlining the overall scope of the site (including any relationships to other systems)

It’s a good idea not to turn the intranet charter into a project plan – e.g. by including granular details or specifying details of the development process. Try to keep the document high-level, even timeless, while recognizing that you will need to revisit the charter (perhaps on an annual schedule) in order to accommodate shifts in the business and other changes.

Add a star rating service to content
Let users rate any – or selected – content on a 1 to 5 scale.

Pro: Relatively easy to implement; not likely to be hijacked by someone with an agenda; can provide ‘instant gratification’ for users.

Con: Using star rating to drive UI (e.g. for ordering search results) might be a challenge to implement, depending on your CMS.

Add commenting to content
Pro: Gives users a sense of ownership; adds implicit metadata that can be mined to drive navigation, improve search, or as part of a rewards program for content contributors.

Con: You may be required to implement moderation (by corporate lawyers, for example, or nervous senior management).

Add Facebook-like functionality to your online corporate directory
Allow users to update information about themselves, such as status (could be a pulldown of business-related options), job description, projects they’ve worked on etc.

Pro: More current information about people; these data can be used to help make connections between people.

Con: Can be hijacked by exhibitionist team members, possibly exposing the company to harassment lawsuits etc.

Implement blogging
Create a forum for users to share their thoughts on business-related – or any – topics.

Pro: Encourages participation, creating buzz for the site as a whole, driving traffic; may generate value by providing a window for leaders to take the pulse of the organization, or get ideas from front line team members. If senior management can be persuaded to participate, this can be a powerful incentive for all users to visit more often.

Con: Like some of the other strategies above, allowing users un-moderated access to a public forum could create problems if it is misused.

Here are a few considerations you should keep in mind when calculating the cost of implementing an intranet.

1. Be sure to distinguish between upfront costs and recurring expenses. The project-related expenditure required to get the site up and running will likely be wasted if there is no budget to keep the site fresh after launch.
2. Identify capital costs and operating expenses separately.
3. Get numbers such as loaded labour costs from your finance team.

Here’s a list of specific items that often need to be considered:

• Server hardware and other infrastructure.
• Server setup and configuration costs.
• Software license fees.
• Software installation, configuration, customization, integration and testing costs.
• If you have decided to ‘roll your own’ you’ll need to factor in software development.
• Up-front labour costs for graphic design.
• Desktop software for content creators, such as HTML and graphics editors, as well as any hardware upgrades required to run these tools.
• Training for IT/IS staff, intranet team and content authors.
• Recurring labour costs associated with content authoring.
• Costs associated with supporting the intranet once it’s launched, including call centre resources as well as IT/IS and the intranet team.

I think this is particularly pertinent to those of us managing intranets, whether in IT or the business. Because we are with few exceptions a cost centre in our enterprises, senior management has few qualms about making ‘left turns’: reducing funding, changing corporate priorities etc.

It is incumbent upon us to keep the level-headed voice of the GPS in mind as we respond to such shifts: Make sure you know your goal and just keep steering towards it.

• Companies don’t as a rule publish costs for internal communications so benchmarks are hard to come by.
• There are almost as many solutions as there are intranets, ranging from externally hosted solutions with no up-front costs to full enterprise class implementations that include costly middleware platforms, search engines and CMS platforms.
• The internal capabilities of your IT group will be an important determinant of how much you’ll have to spend: If they have experience with open source tools & platforms that lend themselves to intranet development you can avoid some or all of the ongoing expense of licenses for proprietary software.
• Flip side of the previous point: Internal development costs can easily exceed licensing fees (though you’ll usually get an intranet that better meets your business requirements). How such internal costs are accounted for by your finance team is an important consideration when tallying the cost side of your ROI calculations.

I’ll follow up with another post with some recommendations on considerations you should keep in mind when calculating costs.

Rather than focusing on such ‘explicit’ metadata, I recommend using the technology to your advantage by gleaning ‘implicit’ information about content wherever possible. By way of example on the public web, think of the recommendation engine at Amazon.com: The books that Amazon suggests are determined primarily by information implicit in your earlier actions.

Here are a few examples of implicit metadata:

• Author
• Author’s department
• Date created
• Date modified
• Links to and links from (these are the foundation of Google’s multi-billion dollar enterprise)
• Title (whether this is considered metadata or is part of the content depends on several factors: Author training, strength of writing guidelines etc.)
• Where created (by this I mean “where was the author’s starting point in creating this content?” It requires an authoring environment where authors navigate the site prior to launching a form to add a piece of content)
• Automated keyword extraction

Any of these can be leveraged to drive both reporting and end user UI.

Another type of metadata that can help free you from a dependency on authors tagging content is ‘user-centred’ metadata. Here are two examples:

• Clickstream data (i.e. where are viewers of a particular piece of content coming from? Where are they going after reading it?)
• Popularity

Finally, here are two examples of ‘user-generated’ metadata:

• Star rating (give users the option of rating each piece of content)
• Thumbs up/down (a simpler way of promoting/demoting content)

1. Things change. Once a newspaper article is completed, it’s done. A document stored in a CMS on the other hand, may be usefully referenced over a longer period of time. This means that whatever taxonomies guide users to it must reflect current reality, not just the state of things when it was created. Therefore, some method of review/update should be built into the system.

2. Nobody uses “Advanced Search.” Very few users will take advantage of a content discovery system that requires them to consider anything but basic keywords: Google is the de facto standard for finding stuff. If the implementation of a taxonomy is anything but implicit, many users will never use it.

3. One is usually not enough. Taxonomies often reflect a particular view of content that is biased by the needs of the team or department that implements them. Such multiple views are often perfectly legitimate: Relationships between content as seen by IT can be quite different through the eyes of HR. An enterprise view will often require multiple taxonomies, with all the additional overhead and complexity that that implies.

4. Compliance can be hard to enforce. Getting authors to tag their documents with the appropriate taxonomic labels can be very challenging. Having the taxonomy drive the filing hierarchy (i.e. where authors store content) is one way to make this automatic, but it doesn’t always make sense in light of my previous points.

5. ‘Brute force’ might be better. Over the past couple of years, I have helped implement search engines that leveraged the exponentially greater computing power of modern servers to drive both search and navigation based on automatic indexing and analysis of the full content of documents and web pages. In these systems, authors are not required to subscribe to a taxonomy or explicitly add metadata to their work: The search engine does the work for them, responding to users’ needs with a near-real time view of all content in the system.

This is not meant to discourage you from developing one or more taxonomies as part of your intranet initiative. At minimum, formulating a taxonomy will reveal relationships and metadata that no other exercise can. Rather, my intent is to encourage you to place taxonomies in the appropriate context, and to make you aware of some of the pitfalls that can accompany them.

These regulations, if adopted, will govern a broad range of activities, from signage to websites and enterprise software. There will be a substantial impact on intranets, including ensuring content is made available in a format that can be used by people with a range of disabilities. The specific disabilities that will be addressed in the legislation include visual and hearing impairment, as well as “understanding” impairment. While there are fairly well understood means of accommodating those with visual and hearing impairments, the last item — understanding impairment — is perhaps the most challenging, as it will require that all content be made available in “plain language.”

These are some of the general requirements of the new rules:

• Inform persons with disabilities that there is accessible information and communication available.
• Ensure that individuals with disabilities are not disadvantaged in terms of the timeliness, quality and availability of communication, given or received.
• Establish a user request, feedback and complaints process that allows persons with disabilities (whether they are consumers or employees) to identify their communication needs and to communicate with the organization.

Here are some of the provisions pertaining to IT systems covered under the proposed legislation:

• New IT systems must provide an accessible user interface and content file format by default (which means you don’t have to ask for it – it’s available) when these systems are made available for use by employees or the public.
• New content must be in an accessible digital file format on existing systems.
• User interfaces of existing IT-based information and communication systems must be made accessible.

Here is a summary of the section of the proposed regulations that pertains to “Business Enterprise Systems” including intranets, as well as applications that face a cross-section of internal users:

• Once the standard is in effect, any newly acquired business enterprise systems must provide accessible formats and methods of communication when they are made available for use by employees or the public.
• If, at the time of the standard taking effect, an organization has already invested in a system or signed a contract for a new system (but hasn’t started using it with employees or the public), it will have three years to comply with accessibility requirements.
• For existing systems, organizations have to meet the requirements for accessibility at the time of system update and no later than within six years of the standard coming into effect. User interfaces and data formats must be compliant by 2012.

While these rules have not yet passed into law, I strongly suggest that anyone managing an intranet or other employee-facing application in the province of Ontario should start looking at what would be required to bring their systems and processes into compliance in anticipation of these changes. As well, I recommend that an intranet team member be assigned to monitor the progress of this legislation, in particular the timelines for compliance.

One final note: There will also be grey areas where new modes of communication are concerned. Specifically, how will video or audio based communications be treated under these laws given the requirement for equal “timeliness, quality and availability of communication” for those with disabilities? If you are considering the rollout of new media tools to your team, be sure to consider how you will make the information accessible to those with disabilities.