Angie Cullen

When building a business case around a social Intranet, there are a few key components to consider.  Here are five suggested features that you might ask your potential vendors to demonstrate.

Forum Collaboration
By using a forum or threaded discussion  tool, you can engage your employees around specific topics and challenge them to start talking about topics that matter to them. For instance, Project Managers might discuss the project they are working on along with the status of that project, IT employees may share valuable technology updates, and HR personnel may share links to recruiting best practices.  Be sure that the tool  allows employees to create a profile and specify the topics they are interested in. This also provides a way for employees to get to know their colleagues and share information.

Social Tagging and Ranking
Although search engines are getting smarter by the minute, nothing replaces the ability for an employee to indicate whether an article or piece of content was useful to them in their job. Especially if the search engine takes that ranking into account in ordering their search results (e.g. articles they ranked higher, should be placed higher in the results). In addition, if employees are able to add their own keywords that helps influence search results, they will be able to find information that is more meaningful to them much more quickly.

Document Storage & Collaboration
With a document storage and collaboration tool, employees can find and share documents easily.  This tool will allow employees to create, open and edit documents by placing them in a centralized location that’s easy to access. Having this tool will allow multiple users to work and collaborate in real-time, based on the permissions that are set by the owner, on a document simultaneously.  A document collaboration tool can also help you cut down on storage costs. Employees will no longer need to email a status report, PowerPoint deck, or Excel spreadsheet to the entire project team (these multiple copies take up storage on the email server). Instead, they can simply email a link to the single copy stored on the Intranet and use check in/check out functionality to edit that single document.

Expertise Finder
Employees consistently rank the company directory as one of the most used functions of their Intranet. An expertise finder takes that directory one step further and allows users to identify employees that hold specific knowledge or expertise. This is paired with the ability for employees to create their social profiles and self-report their skills. Similar to tagging content, employees should also be able to tag other employees with terms that they could use in the future to find that expert again (e.g. tagging someone as “Intranet administrator”)

Knowledge Base or Wiki
Your employees have a great wealth of knowledge and given the opportunity many of them want to share it. Be sure to ask your potential Intranet vendors whether they offer a knowledge base or wiki functionality that would allow your employees to quickly, easily share nuggets of knowledge that may assist other employees. Keep in mind that it must be easy to use and be integrated with the search functionality so employees can use a single search to locate people or content.

These five key components  are just a few of the items to consider when reviewing potential software solutions for a social Intranet. Be sure to ask each of your vendors to demonstrate the functionality and consider inviting a few of your end users or members of your Intranet Governance Council to the demos to get their input, as well.

Have additional features that you think would be critical to a social Intranet? Feel free to leave a comment and let us know what you think is important or what has turned out to be a popular social feature for your employees.

Sean R. Nicholson

Last week was a great week for online discussions relating to Intranets. On Monday, Alex Manchester of Step Two Designs posted an article to his blog asking whether the term Intranet is dead. His thoughts were sparked by a recent presentation by Jane McConnell of NetJMC and the conversation that ensued was a healthy dialog on the future of Intranets, their relevance in a world of social media, and whether the term “intranet” was really the best way to describe an interactive workplace. The conversation continued throughout the week and I’d encourage anyone who works with Intranets to check out the threaded discussion and add their $.02.

Tuesday continued the interesting online conversations as Jarrod Gingras and Alan Pelz-Sharpe of CMS Watch made his predictions for technology in 2010. One of particular interest to me was his prediction #1 that :

1) Enterprise Content Management and Document Management will go their separate ways
ECM as a marketing and technical concept has great validity. But the idea of having a single overarching platform to manage all sources of content management only works well in those enterprises that follow a unified and services-oriented architectural approach to IT.

I agree with Jarrod and my interpretation of this prediction is that organizations that aren’t able to settle on a single vendor for all of their information systems or aren’t able to invest in a comprehensive services-oriented architecture just won’t be concerned with Enterprise Content Management (ECM) because they won’t be able to address every departmental business process problems with a single ECM tool.

To expand on Jarrod’s prediction, I’m thinking that as more and more vendors build document management functionality into their applications, organizations will be less concerned with where it is stored, as long as it is stored properly, is accessible to the end-users that need it, and can be discovered and produced in time of legal necessity. Instead of costly redevelopment of business processes to restructure where content is stored, organizations will invest in search technology that allows content to be stored in native applications and use search tools like Microsoft Enterprise Search, Autonomy, and Google appliances to ferret out information.

In other words, federated search will become crucial to organizations that choose not to implement a structured ECM architecture.

The results of this kind of shift are as follows:

1. Content and documents  will reside in their native application, allowing the information to have more context than if it were stored in a centralized ECM system.
2. Those ECM vendors who wish to provide value to the enterprise must figure out how to store the content centrally, yet serve it back to end users in a context that is meaningful to their end users.
3. ECM vendors who provide true, enterprise-scale software MUST offer a full services-oriented architecture that will allow business applications to easily access the content and surface documents in the context of the business application.

S0…this brings me to my question of the week. Is Enterprise Content Management going the way of the Intranet and becoming an outdated notion? Will better federated search technologies negate the need for a central repository? Are organizations better off investing in the functional elements of ECM like document management, records management, and business process management instead of buying the whole enchilada?

I’m curious to see what others think…looking forward to thoughts/comments.

Sean R. Nicholson

If you haven’t figured it out already, it’s a Google kinda world out there and your Intranet users expect your search functionality to provide them with accurate, relevant results to their search queries. With that in mind, if you haven’t already begun the process of building a federate search strategy, it’s time to do so.

While the term “federated” might sound fancy, it’s just a high-tech way to say “cross-functional”. In a nutshell, if your Intranet search is federated, it means that it can go beyond searching your portal content and also retrieve results from your document management system, Enterprise Resource Planning (ERP) system, Customer Relationship Management (CRM) system and any other relevant applications.

When putting together your federated search strategy, keep in mind that while returning a broad set of results from multiple systems is important, maintaining the security standards set forth by those applications is key. In other words, your federated search results should only return content and documents that the user is allowed to see in the originating application. This can often be the trickiest part of federated search, but many application vendors have begun exposing search APIs and Web Services that only return appropriate search results with security in mind.

The first steps to defining a federated search strategy is to take an inventory of all applications inside your Intranet that users currently search. Next, determine what roles might have a need to search which applications and prioritize the need to federate your search to those applications based on the business need. For instance, if a high volume of your users search your enterprise knowledge base and it isn’t tied into your portal search, that might be a good place to start. Your priority list will be defined on which applications are searched most frequently.

Once you have developed your priority list, work with your application vendors to determine whether they already expose Web services that would allow you to easily pass search terms and integrate results into your portal. Be sure to test your integrated functionality extensively to ensure that the results that are being returned are the same as if the user had searched in the originating application and be thorough in your security assessment of the results.

As you progress down your list of applications that are integrated into your portal search, be sure to let your users know that they can now use the portal search to quickly locate content across the enterprise. The more federated your portal search becomes, the more quickly your users will be able to locate information, which will drive portal adoption.

Sean R. Nicholson

Okay Intranet fans, here it is…the 2009 completely unofficial list of must have functionality for every Intranet.

**Please note that we reserve the right to update this list and expand it beyond 10 based on the great feedback and comments we will undoubtedly receive.

{drumroll please….}

# 10) Application Interoperability – There’s nothing like a good Intranet mashup. Being able to search for a user and see not only who they are (from the HR application), what they are working on (from the Project Management application), and where they are located (From HR + Google Maps) is pretty cool, not to mention that it brings relevant information to the user on a single page. Look for creative ways to mash up your applications and streamline information gathering. Remember that good mashup also leverage a “simpler sign-on” schema so that users don’t have to login over and over to see data in different applications.

#9) A Clean Design – Lot of functionality is good, but be sure to spend time up front determining what should be on the front page and what can be moved to secondary pages. Your users should be able to find content quickly and easily. Spend some time watching how your users physically navigate the Intranet and strive toward reducing the number of clicks they have to make to locate the information they are looking for. Need help creating a design? Bring in a consultant from the outside to provide an objective point of view.

#8) A Good Name – I always love hearing people refer to the Intranet by it’s given name, rather than “the Intranet”. Creative names allow folks to create an identity for the Intranet that gives it a life of its own. If you don’t have a name for your Intranet, try holding a company-wide contest to come up with names and then have your company vote on it. Your even more likely to get strong buy in if the name is chosen by your organization as opposed to being assigned by a developer with a Star Wars fetish.

#7) A Strong Navigation Taxonomy – Yes….it’s a Google kinda world, so folks like to find content through search, but when they find that content, they also like to see where they are in the navigation, using a folder taxonomy or breadcrumbs, so they can find other content that is similar in nature AND know how to get back to the content in the future.

#6) Personalization – Users need to be able to customize pieces of the Intranet. Whether it’s their weather, stock quote, news headlines, horoscope or other content, allow them to make the Intranet more useful to them as an information source. Also, by allowing users to relocate portlets or widgets, they can create a design that meets the way they work. Need a good source for personalized information? Look to subscription information providers such as YellowBrix.

#5) A Good Rich Text Editor – Nothing helps an Intranet grow more than content, so making the creation of content easy is important. A good WYSIWYG (“what you see is what you get”) editor is important. Don’t forget to make sure your editor has a spell check. I speak from experience on this one (ahem…Plumtree/BEA/Oracle WebCenter)

#4) Governance – No need to go into full-blown lockdown mode, but governance is a good thing for any organization. It keeps your Intranet from becoming the wild, wild west and ensures that the content created has meaning and is relevant. Some areas of the Intranet (WIKIs, forums, etc… ) can be looser than others, but your governance strategy should be flexible enough to accommodate for these different needs.

#3) A Strong Collaboration Toolset – User created content will drive your Intranet page views through the roof. A good, spirited conversation about the latest product or marketing campaign can help spread the word about what your organization is doing and can drive new innovations. Try adding an “Idea Center” to your Intranet and challenge your employees to come up with new ways to do business. Products like user-driven blogs, forums, and WIKIS can turn your readers into contributors growing your content exponentially. Daily polls can also be used for gathering user sentiment on a corporate topic, or just for a little fun.

#2) A Federated Search Engine – Again, it’s a Google kinda world, so make sure your search works and it can talk to other applications. No one likes to have to search 10 different places for information, so leverage tools like Google appliances or federated search engines like FAST or Autonomy to bring all of your content together into one search. If you haven’t ever seen a demo of one of these “meaning” based search engines, give them a call and ask for one. You’ll be amazed at what modern search engines can do.

#1) Meaningful Content – The best design, the coolest name, even a great governance strategy…they’re nothing without meaningful content. If your users don’t find value in your Intranet, they won’t adopt its use. In addition (and I can’t stress this enough), the content MUST be timely and accurate.

The only thing worse than no information is bad information…Your employees will act using bad information because they don’t know it’s inaccurate. There’s nothing worse than a sales rep sharing an outdated rate sheet or a customer service rep providing an inaccurate solution to a problem. To avoid this, be sure your Intranet content is up-to-date and reviewed frequently.

There you have it, Intranet fans! 10 must haves for any good Intranet.

Additions:

Accessibility – Everyone needs to be able to use your Intranet. Ensuring that your pages comply with the accessibility guidelines will ensure that folks with disabilities can read or hear the content. Thanks to Russell @theparallaxview for the suggestion

Have input? We’d love to hear any additions, suggestions, or constructive criticism in your comments!

Sean R. Nicholson

A few years ago, I was in charge of an RFP for a Fortune 500 company to select an Intranet portal application and portal content management system. Thinking about the requirements for that portal and how they would change in this age of social networking got me thinking about how the requirements would change if I were to conduct that same RFP today.

Portal Requirements in 2005

Back in the “olden days” of horizontal portal requirements (you know…a few years ago),  the top requirements for our enterprise portal were as follows:

1. Enterprise scalability, with current requirements at 25,000 end-users, but scaling to 100,000 with additional hardware and licenses.
2. Easy to use, graphical user interface that allows end users to view targeted content and easily navigate to pages within the portal using  either an organizational or functional page taxonomy.
3. Provide portal administrators with the ability to secure content to groups, organizations, and individuals.
4. Provide a WYSIWYG rich text editing interface that allows users to create and edit content, based on their permissions and group membership.
5. Provide a single search interface that allows users to search for content that is target to their account based on assigned permissions
6. Provide a workflow tool that allows content to be reviewed and approved prior to publication
7. Provide a customizable portlet or widget-based interface that allows end-users to customize their experience.
8. Provide portal administrators with a flexible design and administration interface that allows administrators to create page templates that standardize on some page elements (e.g. header, navigation, mandatory portlets).
9. Provide functionality to interface with an enterprise Identity Management Solution.
10. Provide analytical reporting that details usage activity, content quantity, and hyperlink status (e.g. number and location of broken links)
11. The ability to integrate with existing enterprise applications such as the document management system, time reporting system, and expense management system using a Services Oriented Architecture.

Like I said, these were the high level requirements that we looked at. We actually had more than 300 specific technical and functional requirements, but these hit the major functionality we were looking for.

As you can see, though, these portal requirements are based on an “information-push” concept, where a core group of individuals (maybe 50-75 for the entire corporation) create all of the content and push it out to the masses. While we did have requirements for collaborative items like forums, they were listed as optional and we weren’t quite sure whether we wanted to allow end-users to start creating content on their own in a forum environment. Pretty much typical information control tactics that are present (even today) in many large organizations.

Changes To The Portal Requirements In 2009

While many of these requirements would still hold true, an information portal in today’s culture would definitely focus more on collaboration and content management than the pushing information out to the masses. Based on my experiences with some of the popular social networking platforms, my top requirements for the same sized organization would probably look more like this:

1. Enterprise scalability, with current requirements at 25,000 end-users, but scaling to 100,000 with additional hardware and licenses.
2. Easy to use, graphical user interface that allows end users to view targeted content and easily navigate to pages within the portal using  either an organizational or functional page taxonomy.
3. Provide portal administrators with the ability to secure content to groups, organizations, and individuals.
4. Provide both a rich-text content management system that allows portal administrators to deliver content and a WIKI environment that allows end-user to create their own page content
5. Provide a single search interface that allows users to search for content that is target to their account based on assigned permissions
6. Provide content creators (both in the CMS and WIKI environments) the ability to review content additions and comments if they choose to enable the feature.
7. Provide a customizable portlet or widget-based interface that allows end-users to customize their experience.
8. Provide portal administrators with a flexible design and administration interface that allows administrators to create page templates that standardize on some page elements (e.g. header, navigation, mandatory portlets).
9. Provide functionality to interface with an enterprise Identity Management Solution.
10. Provide analytical reporting that details usage activity, content quantity, and hyperlink status (e.g. number and location of broken links)
11. Provide the ability to integrate with existing enterprise applications such as the document management system, time reporting system, and expense management system using a Services Oriented Architecture.
12. Provide end-users with the ability to create custom application and information widgets that can be shared across the enterprise.
13. Allow users to easily share updates with others on their work through personal status updates
14. Allow users to create and manage groups/networks that can collaborate through a WIKI interface or a discussion forum interface. Users should be able to store and review documents as attachments within these groups. Users should be able to collaborate and version these documents and the applications should maintain an audit trail.
15. Allow users to create custom events and invite users and groups to those events. Individual and group events should roll up to a common corporate calendar that displays events to users based on their permissions and group memberships.
16. Allow users to share digital media including photos, audio files, and video files. Users should be able to collaborate and version these files and the application should maintain an audit trail.

So What Just Happened? Those Don’t Sound Like Portal Requirements!

Basically, in the process of writing those new requirements, I changed my RFP from being one focused on a portal, to one focused on an Enterprise Content Management system. Not an ECM as we know it today (which are primarily focused on Web/Intranet content management, document management, and digital asset management), but to an ECM platform that requires the following:

• A customizable presentation layer (the portal)
• A flexible content management system (traditional WYSIWYG content management and collaborative WIKI)
• The ability for end-users to create application mashups
• A lightweight document management system
• Social networking capabilities through collaborative groups/networks
• A lightweight digital asset management system
• Enterprise search functionality

Previously, ECM players such as Stellent, Documentum, and OpenText have not offered a portal interface to their products. Instead, they focused on their ability to interface with portal such as WebCenter Interaction (formerly AquaLogic User Interaction (formerly Plumtree)), IBM WebSphere, Microsoft SharePoint, and Vignette portal.

As a result, some of those solutions are being gobbled up by the portal players in hopes of creating the true Enterprise Content Management System of the future. Some of the portal players, like Vignette and Microsoft have anticipated the merging of portal and CMS, and have opportunities to add social networking to their platforms. In the end, the days of offering a standalone portal are probably long gone and we’ll soon see the horizontal portal players roll into the ECM magic quadrant.

Thoughts or comments? I’m always open to additions and constructive criticism in you comments.

Sean R. Nicholson

Who isn’t interested in accomplishing Single Sign-On? You know, that nirvana of Identity Management where users only ever have to sign on to their local workstation and then have completely unfettered access to applications throughout the enterprise. While this concept may sound great  to end-users and executives, it’s an absolute nightmare concept for IT personnel and application administrators.

The Wild, Wild West In An Enterprise With No Identity Management Infrastructure

If you have ever been in an organization with no Identity Management infrastructure or strategy, you probably know how bad it can be…and the larger the organization, the worse it gets. When working with one Fortune 100 company in recent years, I found myself with 15 different User names and passwords on my first day. After asking around whether I was doing something wrong, one of my co-workers indicated “No…that’s just the way we do things here.” Let’s see, I had a login for my desktop, one for the Intranet portal, another for the expense management system, one for my project tracking system, the list went on and on. And to make things worse, each of these different applications had separate password expiration policies, so I was anticipating a future where my passwords were quickly out of sync.

Soon, I was relegated to having to manage my passwords in a password utility called KeePass. Obviously not ideal, but it beat the heck out of having to reset my passwords every time I tried to login because I couldn’t remember my password or getting locked out of the application due to failed attempts. On a side note, I had a conversation with an exec who informed me that most of the corporate executives were keeping their passwords on a piece of paper under their keyboard.

Putting All Your Corporate Identities Into One Basket…A Potential Single Sign-On Nightmare

The flipside to the wild, wild west is a highly organized, very restrictive identity management strategy, but even this scenario can have its downsides. While working with a customer recently that used a common enterprise IdM application to manage a single sign-on environment, the entire enterprise was brought to a grinding halt when the identity policies for their application were corrupted. The end result, no users in their enterprise were able to login to any application in the environment. Basically, their back-office business was brought to a grinding halt until the policies were able to be restored.

The real kicker? This particular organization had also tied their website customer portal accounts to their IdM system, so their entire business was brought to a standstill. Not only were employees irritated at the outage, but customers began flooding the call centers with calls and the call center reps weren’t able to access their CRM system. While watching this fiasco unroll, I began to clearly understand situations where the concept of single sign-on can actually be a bad thing. Every egg in one basket just doesn’t seem like a good idea.

The other downside to true single sign-on is that once an account has been compromised, the hacker has access to your entire infrastructure. This means that users who walk away from their workstations without locking them present a MASSIVE risk to your enterprise. It also places more accountability on your IT professionals who are working on users desktops. Think of the desktop technician who assists an executive with an issue and, during the course of the their assistance, is able to access systems using the executive account. Obviously, these professionals have a high level of accountability in the first place, but having unfettered access to all information inside the enterprise can be a risk.

Simpler Sign-On – The Middle Ground

So what’s the solution? Obviously “single sign-on” isn’t necessarily the silver bullet that execs often think it is, but requiring users to manage disparate user IDs and passwords creates a usability nightmare. The middle ground, then, is a balance of what I commonly refer to as “simpler sign-on”. The idea is to make the authentication process as easy to use for your end-users while maintaining a level of security and application stability that meets your organizational needs. The strategy I often suggest is not a complex one and can be leveraged by any organization, no matter how large or small.  The suggested strategy is as follows:

1) Classify your applications by information risk. Clearly understand and document what risk the information would pose if it were exposed to everyone inside (and potentially outside) your enterprise. While your classifications will be unique to your organization, a guideline to start from might be:

• Low risk applications – Those that surface benign information that is of low risk if it were exposed. Think of the daily lunch menu being posted on the Intranet.
• Medium risk applications – These are systems that often contain a combination of low risk data with high risk data. Intranet portals often fall into this category because they might have the daily lunch menu, but also contain strategic sales, marketing, or organizational performance information that might be risky if it were exposed.
• High risk applications - These systems contain highly sensitive data and often include (but are certainly not limited to) performance management systems, Customer Relationship Management systems, recruiting systems, and corporate records management systems.

2) Assign an appropriate identity management strategy. Decide whether each application should use its native authentication or whether a federated IdM strategy would be appropriate to secure the data.

3) Provide a secure, enterprise methodology for employees to secure their User IDs and passwords. If you’re going to require that your employees have disparate user IDs and passwords, give them a way to secure them. It’s better to provide clear guidance and, ideally, and enterprise application, to store their passwords as opposed to letting them store them on a sheet of paper or spreadsheet. You’d be surprised how cheap and enterprise license for a password storage tool can be.

4) Attempt to synchronize password expirations and document the process. If your employees are going to be required to reset their passwords on a periodic basis (a best practice for information security), be sure that you attempt to synchronize the timing of the password expirations and provide your employees with clear instructions on the process for resetting them. It’s amazing how much simpler the process can be with a single sheet of instructions.

5) Educate your employees on the importance of information security and the reasons behind your policies. Employees are much more likely to accept your IdM strategy if they understand that there is a reason behind it. The fact that the simpler sign-on strategy has been analyzed, streamlined, and employee usability has been considered will help them adopt the process and adhere to the policies.

In the end, it’s always better to be over-protective of your information and access to your organizational systems, but keep in mind that taking employee usability into account can increase employee satisfaction and reduce security risks that occur when employees write down their passwords or store them in unsecured electronic formats. The chase for single sign-on can often lead to additional security and application stability threats, while a more reasonable standard of “simpler” sign-on might achieve the security needed while driving user adoption.

Thoughts or comments? I’d love to hear your experiences with simple sign-on, IdM applications, and constructive criticism of the thoughts in this article.

Sean R. Nicholson

One of the strengths of a good Intranet portal is the ability to integrate the disparate applications that exist within an enterprise. Just because links to the applications are presented in the portal or, in some cases, even natively surfaced in the portal doesn’t make them effectively integrated.  Take a look at the following tips and see if they indicate that your portal has mashups or messes.

User adoption will be low if your end-users have to login over and over again!

Some portal vendors are already integrating Identity Management functionality into their portal applications, but don’t be tricked into thinking these solutions are a magic bullet. Legacy applications often use hidden authentication fields or tricky redirects to ensure that they aren’t being “spoofed”. In one recent situation, my Development team spent a couple of weeks attempting to use BEAs Aqualogic User Interaction portal to federate authentication to applications like Peoplesoft and Concur Expense Management. Each of these applications use a specific redirect functionality to ensure the security integrity of their application. As with this situation some application IdM may not be able to be addressed by a portal or IdM suite. The goal, however, is to minimize the number of times your users have to login by federating wherever possible.

A Customer Service Mashup

5) Usability – Nothing screams “MESS!” more than a hodgepodge or information hastily slapped together on a page. Care should be taken to understand how your users expect to use the mashup before placing the content onto the page. Your end-users can often describe the flow of information they use, which will guide you in arranging the mashup appropriately. For instance, in the case of our customer service agent, do they often ask how the weather is in the customers location? If so, having the weather information prominently displayed may assist establishing a relationship with the customer. During a heaving outage period, however, it might be better to relocate the outage information to the top of the page and allow the weather to be secondary.

Creating a good mashup isn’t just about bringing together commonly-linked information. To avoid a mashup mess, take the above tips into account and you’re sure to produce something worthwhile to your end-users.