Bid Content Libraries - part 1
Technology is not necessarily your friend
You regularly respond to requests for proposal (RFPs) or invitations to tender (ITTs) and you know that having some content ready before you start is a good idea: it saves you time and by using material you have had plenty of time to prepare, you get better quality. However, knowing in principle that it’s a good idea is one thing, putting it into practice can be a world of hurt. This article and its companion pieces will give you some ideas on how to start a good library, how to maintain it, what to put in it and, by no means least, what a content library can and cannot do.
Don’t rush to implement an expensive system. There are many software solutions to the problem of keeping a library of bid content and they all work pretty well, given two pre-conditions:
1. You know exactly what content you want to store
2. You know exactly how you are going to use it
If you implement a bid content system before considering these factors, you run the risk of automating a bad manual process to produce a worse automated process. Start with a halfway house: something that can be implemented cheaply and easily, experimented with and used to inform decisions about what content to keep and what processes to follow to create it, use it and maintain it. Then when you come to implement your full scale, industrial strength system, you will know exactly what you are looking for and how you want it to work.
How to build a halfway house
One very straightforward method of keeping content is to organise it into files and store them in shared folders on your network. This allows you to keep the content in whatever format you first produced it (Word documents, Excel spreadsheets, PowerPoint, Visio etc), so it is easy to edit and to customise. At this point, however, we run up against two problems, one to do with human nature and one that comes under the heading of “Ye canna change the laws of physics, Captain”.
The laws of physics problem is that a given piece of content may be relevant to more than one topic. For example, if you offer defined service levels for your service desk, does a document describing these service levels go into a folder called “Service Desk” or into one called “Service Levels”? We could create both folders and put a copy of the document in each, but that way lies madness, both in terms of disk space needed and in trying to keep multiple copies of a document in step with each other.
The human nature problem is that people rarely agree on how a document should be filed and what one person stores may be functionally inaccessible to another, who would never have dreamt of putting it in the same place –if you have ever tried to find something in someone else’s kitchen you have already encountered this problem. So, simply creating the folders and expecting people to be able to store and retrieve material won’t cut it.
The answer is to have an index – look up what you want in the index and then go where the index points, just the way you would look up something in a reference book. Windows can already find files by keyword. Type some search terms into the search box in File Explorer and it will produce a list of files that contain the words you were looking for or have those words in the title. This is already very useful, but it’s a rather indiscriminate tool for what we want. Not every document that contains a particular word will be useful. (I once worked in an organisation that included all RFPs in the same large SharePoint system as the bid collateral; every search produced a list that prioritised the RFPs asking for the information over the collateral with the answers, so the first few screenfuls of results were generally useless.) The answer is to tag the files to show the topics they cover. This solves both our problems: one file can have several tags and, provided it is tagged and shows up in the index, it doesn’t matter where the file is actually stored – someone looking for it will find it through the index.
Good, we’re making progress. We don’t need to do anything special about the index itself, Windows already does that for us. We just need a way to put tags on the files. There are two ways to do this: add words to the files themselves or add custom properties to the files. Both are simple and both are transparent so far as searching is concerned.
First, let’s think about the tags themselves. We know that the File Explorer search facility will find documents that contain the search words we use, but we need some way of limiting the search results to just the tags – a list of every document containing, for example “service level” won’t be much use. The trick is to make the tags so that they can’t be confused with ordinary words. An everyday example of this is the hashtags used in Twitter. If we tag a document with “#ServiceLevel” and search explicitly for that tag, we can be sure of getting only the tagged documents and not everything with even a single mention of “service level”. It doesn’t matter how we make up the tags, provided the result is not an ordinary word. Any symbol added to the tag will make it stand out, so such forms as “#ServiceLevel”, “xServiceLevel”, “tag:ServiceLevel” or “+ServiceLevel+” will all work.
Now let’s think about adding the tags to the files. The first way is to add the tags by editing them into the documents themselves. For example, at the top of the first page of a Word document, on the front sheet of an Excel workbook or the front slide of a PowerPoint presentation. You can actually put the tags anywhere, but putting them at the front is simple and it also makes it simple to check whether the file has been tagged correctly, or at all. The disadvantage is that you need to open the file to do it. The second method avoids this at the cost of a slightly more involved method of applying the tags in the first place.
Microsoft Office documents have a set of properties associated with them. You can see them by opening a File Explorer window, choosing a Word, Excel or PowerPoint file and right-clicking on it. At the bottom of the list that pops up, click on “Properties”. In the properties window that appears next, click on the “Details” tab. At the top of the details list, in a section called “Description” you will see a list of items: Title, Subject, Tags, Categories and Comments. So we have a place to put tags already. To add a tag or tags to a document, open the folder containing the document in File Explorer, open the document properties and click on the word “Tags”. Start typing and what you type will appear in the tags field. You can add as many tags as you like, just separate them with semicolons. When you have finished, hit return, click “OK” and the job is done.
The File Explorer search facility will find documents that have “#ServiceLevel” in the tags property just the same as those that have “#ServiceLevel” at the top of the first page. If you want to be really smart about it, you can frame the search as:
(note the quotes around the tag itself). This makes File Explorer look only in the tag property of each document and on a big set of folders, this can make the search run much faster and more efficiently. As a further bonus, you can directly view the tags on all the files in a folder or a search by adding the Tags column to the display in File Explorer – just right click any of the column headings on the display and click on “Tags” from the drop down list that appears.
The mechanics of tagging and retrieving documents really start to deliver benefit when we go on to think about the meanings of our tags and the way we are going to use our library. In the next episode: how to control the process, what to tag and what tags to use. More on this next time.
