BACKGROUND TO THE KNOWLEDGE DATABASE PROJECT

The project to create a Knowledge Database (KD) using SharePoint came about as our current KD, consisting of a SharePoint document library, was quickly becoming obsolete. It was simply not being used due to various shortcomings. From the outset the new initiative had two major constraints: extremely limited budget and time. For various reasons this project needed to be done in a matter of a few months, using the technology already available to us, which in this case was SharePoint 2010.

One point to mention is that this tool would only be available to one area of the business and would be rolled out very gradually to other teams, with further improvements in later versions as user take-up increased. This was a trial of sorts.

We did some background work, speaking to users on their views of what they would like to see in a Knowledge Database and we could see what was going wrong with the current system. This article concerns the next steps we took in building the Knowledge Database itself.

INTERFACE

Throughout our project we were concerned with the question of how we could best ensure that employees used the Knowledge Database while it was restricted to the confines of SharePoint. To clarify, our team was of the view that if governed properly, with all the available document search and storage functionality deployed, SharePoint had ample potential to be a useful database tool. The problem we were finding was that SharePoint was not meeting requirements from a user perspective. From talking to our colleagues, one of the main themes that arose was around having a tool that was easy to use, ideally bearing close resemblance to popular public search engines such as Google. We could not replicate Google with our technology, so our main challenge was to create a database that users could relate to and that was user-friendly, within SharePoint.

Those who have used SharePoint will be aware of its document libraries. Working in a similar way to an Excel spreadsheet, documents can be stored in rows with various metadata for grouping and sorting and allowing for useful search and retrieval. However for our users, document libraries and their functionality did not appeal. When employees were faced with rows and rows of documents, even if they were grouped adequately, they shied away from properly interrogating the library, especially if they were in a rush, as was commonly reported. They were also not able to use the search adequately, to quickly find what they were looking for, despite training sessions. This was a further indication of it not looking or working like the search engines they were used to, i.e. simple, intuitive and easy. We realised that we had to move away from the traditional look and feel of a SharePoint library. We therefore decided to put an interface over our database in order to ensure user engagement.

Our Knowledge Database therefore consisted of a SharePoint site with a document library. The front page of the site was what the users would see and would contain all the search tools needed to help the users retrieve knowhow. As we couldn't replicate Google's complex search algorithms, we decided we should give users options for different types of searching, but laid out in a simple and clean way. The end result was for our front-end interface to consist of an advanced search box and below that a keyword filter search, with search results appearing on the same page, all of which we discuss later in this article.

Figure 1: Pixelated screen-shot of the front-end Knowledge Database.

In essence we decided to make our database look removed from traditional, out-of-the-box SharePoint. With all the customisations that companies employ today for their intranets or search tools this is not a novel idea, but we believe that our finished result was very successful given the constraints we had in our strict time limit and budget.

CREATING THE DATABASE: WIKIS AND DOCUMENT LIBRARIES

Numerous online articles suggested creating a Knowledge Database site based on the enterprise wiki template, so we tried in our UAT (test) SharePoint environment. An enterprise wiki template allows you to create new wiki site pages based on, for example, knowhow topic terms. It is known for being an ideal way to collect, capture and share information in a collaborative manner. We were hopeful that this template would fulfil our Knowledge Database needs and specifications.

Whilst the enterprise wiki site was relatively simple to create, with online articles offering step-by-step instructions, we ultimately found that the look and feel of a KD based upon the Enterprise Wiki template, as well as its search functionality, did not entirely meet our requirements. It soon became clear that there would be a need for significant customisation, particularly to the front-end user interface and its search functionality, which we, unfortunately, did not have the IT skills or time to fulfil.

After further testing and much discussion, we soon recognised that we could simply create a complex and intricate document library for our knowhow, giving all documents large amounts of metadata. This, from our perspective, would fit our needs and specifications adequately.

As well as including the standard or default columns for the document library such as name, author and document date we decided to create some new columns, specific to the Knowledge Database document library to, not only capture the knowhow's metadata, but to also to improve the search and search results experience for our users.

A typical example of our added metadata fields is the summary column. The free text column offers a succinct overview of the knowhow itself, including any keywords or phrases. The search results are configured to display the knowhow summary underneath the title of the knowhow. This is particularly useful for users as each piece of knowhow yielded within the search results offers a concise digest of its content.

A further example is the addition of a ‘Go To Person’ column to the document library. The choice or group column type allows us to assign each piece of knowhow to our internal subject specialists. In our company we have a group of subject specialists in all topic areas who provide advice on those topics and keep abreast of issues. These are all senior personnel in the company and we call them the ‘Go To People’. The properties of the search box have been configured to allow users to search by Go To Person, thus allowing them to yield results on a particular topic. This is advantageous to the users as topical search results are not only grouped accordingly, but point users to the appropriate individual should they need to seek further advice on a particular piece of knowhow or topic.

TAXONOMY

As information professionals we were certain that one of the best ways to store and search materials on our Knowledge Database was by employing a taxonomy. SharePoint 2010 has useful, if slightly limited taxonomy functionality, in the form of its managed metadata service and term store management tool.

To give a brief overview of the SharePoint managed metadata service, SharePoint 2010 allows you to create hierarchies of terms that can be local to one document library, or global to the whole site. They can also be managed centrally by one team, usually for taxonomies, or opened up to the users themselves to allow for social tagging, or folksonomies. The term store management tool allows you to create a hierarchy tree of terms, with which you can create groups of terms, move terms, delete and structure. You can also assign properties such as descriptions. While it has functionality for adding synonyms to terms, you are restricted in creating related terms. To add the terms to a document library, you need to add a column in the library settings, called managed metadata. Once you have selected the correct term set for the document library, you will then have a field in the document properties for entering your terms, or ‘tagging’ your documents, with predictive text functionality.

We were very grateful to our predecessor who had left a helpful set of key terms already on our SharePoint intranet that we could work with. As this project was confined to one area of our business we also knew that our taxonomy would not have to be as large as say the Westlaw taxonomy, as it was restricted mainly to maritime and specific law and insurance terms. However, we felt we still didn't have enough terms to adequately serve our knowledge database and the range of materials that it would store. We knew we had to gather more terms but could not buy in a taxonomy. Therefore we turned to the people working in our firm, specifically to the subject specialists, or Go To People. We employed the Go Tos to send us keywords related to their area of expertise, which would be added to our taxonomy. Obtaining the keywords was no mean feat with a group of busy senior managers, but we had buy-in from the senior subject specialist, having worked with her on previous projects, and she was a key stakeholder and advocate of the Knowledge Database. It would be a crucial instance in which we would draw from a pool of employees from around the business to help push this project forward. Having senior personnel on board with the project was a great help. The subject specialists were ideal stakeholders for this project, particularly for the taxonomy, as they could provide the terms and sign off on them. We liaised continuously with them, using materials they submitted to glean more terms. Once we felt we had a useful set of terms, we organised them into the hierarchy based on the structure we already had, deleting duplicates, shifting terms around and creating new groups where necessary. Overall it was a successful way of obtaining the key terms for the taxonomy.

TAXONOMY NAVIGATION

SharePoint 2010 has functionality to incorporate a taxonomy into document libraries and lists, allowing users to access the taxonomy and search by filtering or clicking on terms. The taxonomy will appear on the left-hand side of the document library. The majority of articles we had read on how to best use SharePoint for knowledge databases promoted incorporating the taxonomy into the document library in this way. Additionally, for our team, allowing the users to have access to the taxonomy themselves and use a keyword filter, felt like the best way for them to search. As stated above, the firm's employees were not adept at searching using their own terms, and wanted an easy way to find content, so we felt that this matched their requirements. The problem was that we could not allow the users to see the taxonomy without it being situated within the document library, instead of on our interface. We therefore needed a solution that was beyond SharePoint capabilities.

We researched numerous SharePoint forums, articles and LinkedIn Groups for a workaround. The solution we eventually decided on was a web part that displays taxonomies called the Tag Navigation Web Part, from a company called Layer 2. The web part was attractive as it was simple in its design, flexible in how you could choose to display it, reasonably priced and provided the easy navigation we needed. The web part allowed the taxonomy to be displayed cleanly to the users on our interface and enabled them to click on a term and be taken to the related search results.

Source: Layer2 website http://www.layer2solutions.com/en/products/Pages/Tag-Navigation-Web-Part-SharePoint-2010.aspx

Figure 2: Tag navigation web part

Our relationship with IT became relevant at this point as we needed them to help install the new web part quickly. Access to the central administration tool in SharePoint is also necessary for installation of this tool. Like many knowledge and information teams today, we rely heavily on IT for even small initiatives and projects, so it is important that we maintain a good rapport with them. After getting our request prioritised, we employed IT to, check that the tool would not pose any risks to our systems, set it up in a test environment for us to trial and then install it on our live SharePoint site. We highly recommend this approach as installing this web part was not completely straightforward. It was useful to test it out in a closed environment to ensure we had it set up correctly. The Layer 2 team were very helpful during this period in answering our questions. The tag navigation web part now works very well in helping users to search via our taxonomy.

ADVANCED SEARCH CUSTOMISATIONS

To enable the users to have a flexible way of searching we decided to use an advanced search box on the front page of the KD which would hopefully suit their individual search needs. Additionally the intention was to allow them to search all of the metadata options we had employed on the back end document library.

As a result, we employed the SharePoint 2010 out-of-the-box advanced search and made some customisations. The advanced search box from SharePoint had the search options we wanted, including Boolean searching, allowing the user to search for phrases, any words or all words, in easy to understand language. The search box also allows the user to pick certain properties to search from. The default properties include author and date but were limited for our purposes. We had ensured that each document had a large range of metadata including the subject terms, as part of our taxonomy, and a summary field. Therefore we wanted to ensure that users could search all of these.

There are various articles on how to add properties to an advanced search box web part which we used and have added to the appendix in this article, but we will briefly summarise the process here. It is important to note that to do this you need access to the SharePoint central administration tool and a basic knowledge of XML. Firstly, in the central administration tool you will need to add a new managed property, such as subject term, author or summary. This will give you a recognised new property in your SharePoint site collection. You will then need to edit your advanced search web part and navigate to the properties section where you will see the XML. You will now need to add your new managed property to this XML. There will be other properties present, so make sure to follow the structure of your XML for the outcome you want. We would recommend doing this in a test environment first and IT would be best placed to help you on tasks like this. The end result was that users could search additional, useful properties in addition to the out-of-the-box ones.

One more crucial customisation was needed to limit the search to our Knowledge Database. When adding an advanced search box web part in SharePoint it will default to searching all of the content in your whole site or intranet. We therefore needed to restrict it to only search one document library. There are different ways of doing this - we edited the XML properties of the advanced search box once again. We recommend that you find the query tag in the XML and enter the Knowledge Database site name there, whilst ensuring that you use the correct XML syntax. An article on this is referenced in the appendix.

RESULTS CUSTOMISATIONS

Further customisations were made to how the search results were displayed for our Knowledge Database. In keeping with our theme of having the KD work similarly to public search engines, we decided to display the results on the same page as the search box and tag navigation. This also supported usability, as one can run multiple searches without having to press the ‘back’ button, as SharePoint usually displays results on a new page. This is easy to achieve, simply by adding a results web part to your page next to your search web parts. Additionally we ensured that SharePoint's search results filtering web part was also available to users.

Furthermore, IT was employed once again to help us make the results cleaner and clearer. SharePoint search results normally appear with a url and with some confusing metadata referencing the search terms used to find the result.

Talks with stakeholders revealed that these looked too cluttered and did not yield enough useful information. With help from IT we removed the url and displayed the summaries we had written as part of the metadata for each document, rather than only the search terms. We also took steps to ensure that the search results would pick up the proper title of the document, as SharePoint can pick up the wrong property here. Our results look like screenshot in figure 3 which is clear and easy for users to scan through and quickly see if search results are useful.

Figure 3: Screenshot of an out-of-the-box SharePoint search result.

Figure 4: Screenshot of a customised SharePoint search result.

QUALITY CONTROL

Quality control was a key element to not only creating the Knowledge Database but ensuring that the content housed within the database is of a high standard, has value and is of use. Furthermore, it became crucial to ensure that said content is, at all times, current and up to date. Our guiding principle remained that if such controls were enforced, the Knowledge Database would continue to fulfil its requirements.

It was therefore decided that whilst submitting potential knowhow to the database was welcomed with open arms, we needed to keep a tight rein on the uploading process. Experience has taught us that an initial idea of a large collaborative document sharing environment soon has the potential to become a dumping ground for mismatched and chaotic information. Often the willingness to share information does not correlate with the willingness to spend time indexing documents correctly or in the most user-friendly way.

Therefore all knowhow, prior to being uploaded to the knowledge database, was to be vetted by the Knowledge and Information Team and – if in any doubt – confirmed by the Legal Director that the content was indeed useful and relevant. It would be our responsibility to not only vet, but upload and index all knowhow. We appreciated that this would slow the upload process down but, upon reflection, decided that this was a worthwhile exercise to ensure all content was of use, indexed correctly, of good quality and without duplication.

It was clear that taking time here, even over the smallest of details, would greatly improve the database's capabilities in offering a user friendly knowledge tool. In keeping with quality control, we designed a cover sheet of varying file types, including Microsoft Word, Excel, PowerPoint and Adobe PDF to correspond with and attach to the differing knowhow. Containing key metadata about the knowhow, the cover sheet offers our users a snapshot of its content including key title, author and date information, as well as a brief summary of the knowhow itself. The idea for attaching a cover sheet to every item of knowhow stemmed from prior experience in previous firms with knowledge database tools already in use.

Figure 5: The Knowledge Database Coversheet.

The use of a cover sheet was fourfold. Firstly, a cover sheet offers a uniformed approach to our database. Users can be safe in the knowledge that knowhow uploaded with the attached cover sheet has been vetted and approved by not only the knowledge and information team but by senior personnel. This not only demonstrates enhanced credibility but, also improves the -brand recognition- of the knowledge database and in turn promotes the knowledge and information team's service. Secondly, it gives users the opportunity to briefly review the knowhow and its contents without committing to reading the entire document. Thirdly, the cover sheet is displayed as the document preview within the search results alongside the knowhow title, author, date and summary. This enables users to briefly view a succinct breakdown of the knowhow by using the magnification tool to show a graphical preview of the document It should be noted that the preview tool software was installed on our entire SharePoint platform by our predecessor, but is a particularly useful device for users to quickly browse and identify knowhow. Finally, the coversheet offers a health warning to users making clear that whilst knowhow will be reviewed on an annual basis it is ultimately the responsibility of the user to ensure that the content of the knowhow is still relevant or valid and any queries or concerns should be put forward to the Legal Director or Go To Team for clarification.

A key requirement of the Knowledge Database is to facilitate an annual review of all knowhow housed within the database. A workflow has been set up on the review date column with the document library alerting admins (the knowledge and information team) as to when knowhow is due to be reviewed and kept or weeded, as appropriate.

By managing quality in the first instance it is hoped that this will reap dividends in the long run, allowing the future knowledge database to be a continual source of high quality, useful and readily-available information for our colleagues in years to come.

ROLL OUT AND MAINTAINING USER ENGAGEMENT

Our aim was to roll out the Knowledge Database in a gradual process, team by team, gaining constant feedback along the way.

Promotion of the Knowledge Database emphasised its advantages and fundamentally, highlighted how the tool would be of considerable benefit to the users. A minimum input for maximum output was adopted to further raise enthusiasm – ‘send us your knowhow, and we'll do the rest.’

Prior experience in organising projects, as well as involvement in our previous firms, with knowledge databases already in place, told us that a simple ‘submit your knowhow’ competition would further spark interest and promote conversation between employees. With prizes available, we found that the competition really engaged our users and simultaneously promoted the Knowledge Database throughout the wider firm. Our ‘guinea pig’ team submitted a little less than 800 items of knowhow in a four week period – a fantastic result.

Maintaining user engagement is key to sustaining interest in the Knowledge Database and ensuring that the knowhow is kept current and up to date. Our team's plan is therefore threefold: firstly, to continue running knowhow submission competitions; secondly, to circulate weekly updates to users regarding the latest submissions and highlighting interesting content; and thirdly, to maintain our quality control measures, ensuring all content is useful, relevant and up to date.