Last Updated on July 24, 2024 Sarah Gayda
Part 3: Creating a usable Information Architecture
This is the third and final short article in our series “A Practical Guide for Metadata Implementation in SharePoint.”
In the first article we covered the basics of what metadata is and the practical benefits of using metadata to improve the accuracy of search and retrieval.
In our second article we looked at the foundations of metadata as implemented in SharePoint starting with the concept of a “Content Type.”
- Part 1: What is metadata? Show me, don’t tell me
- Part 2: Metadata content types
- Part 3: Creating a usable Information Architecture
Equipped with a basic understanding of the Microsoft 365 plumbing under our belt, we can move on to implementation. This is where the rubber hits the road. However, this is also where many IT pros get a little overconfident with their newfound knowledge. Simply having the knowledge of the Microsoft 365 machinery for configuring document metadata does not mean you will be able to successfully implement Content Types and metadata for your entire organization while garnering full adoption.
Having been around the block, we can assure you that at this stage, 80% of the work is consulting and change management, despite the fact that success requires the pre-requisite of a good technical foundation. You will need to use all your soft skills of negotiation and persuasion to be successful in implementing a document management solution that becomes core to your business processes.
Based on our initial past failures which eventually yielded to a higher success rate as we learned that change management, not technical proficiency, is the key to success. We will give you a basic framework for your journey.
The topics we will cover are:
- Pre-sell the benefits of a metadata-backed document management strategy
- A methodology for planning your document management strategy (Tip: It’s user driven)
- Change Management – Agreeing to use what we agreed to use
Selling the Benefits of a Document Management Strategy
Implementing a Document Management Strategy is not an IT upgrade. This is a significant project that will affect your company’s operation for years to come. As a high initiative that will touch every employee that creates or uses documents, it should be run by your Project Management Office with a highly placed sponsor, ideally an executive. IT can influence and train, but the driver must be a business leader. The sponsor is critical since most IT driven initiatives fail if they are not tied to the strategy of the executives who can sponsor the projects that they see are beneficial to the success of the business.
Paired with that sponsor’s authority to drive change, it is critical to clearly communicate the justification for the changes. If your communities of business users do not also understand the tangible benefits of implementing metadata in your document management strategy, you will be spinning your wheels, burning time and fuel. And this will make a future attempt even harder.
The benefits of a document management strategy that you can communicate are numerous, but they will only be relevant, and gain traction if they are presented as benefits to your communities of users who will be doing the actual daily work of creating and saving documents. We refer to them as “communities” because each community has a different perspective and needs. Salespeople will have a different perspective on their document management needs than the marketing team, the administrative team, the production team, [fill in the blanks “team”], and even your corporate executive group. Each community needs to be approached in a way that is relevant to them. Thus, we recommend you roll out changes on a department level wherever possible and take in learnings to implement document management into adjacent departments and so on until you have completed the enterprise’s digital transformation. Obviously, where there is overlap between groups where you will need to adjust this template.
At a high level here are some of the benefits you can communicate, tailoring them to the needs of each group.
Legal, Audit, and Request for Information Benefits
It can be challenging to communicate the benefits when the document management requirements are driven primarily by outside parties like government regulations and legal compliance. But even these can be communicated as benefits to the user. For example, when an audit is being performed or a legal request for information comes through (which it inevitably will) no one wants to be disrupted and taken off their regular job and be thrown into the task of digging through reams of documents to fulfill audit requests.
If we simply filed those documents with the correct metadata in the first place, those exercises could become relatively routine will not create job stress and disruption for your users.
Other benefits for managing documents based on externally defined regulations is the need to dispose of documents/records that are no longer required and could even become a legal liability. Again, nobody wants to have the job of sorting through archives for documents that should be disposed. A well-labelled repository makes it possible to automate those requests that otherwise do not really provide any business value.
Time-Saving Benefits
Aside from those outside requirements, you should communicate the huge benefits of working in an environment of well-labelled documents throughout the organization. While workers have no problems finding documents that they are actively working on, they all understand the challenge of finding documents they last used months or even years ago, and especially those documents they have never worked with personally.
Knowledge Reuse Benefits
A company’s proprietary knowledge is the engine for innovation. Some even say a corporation’s knowledge is the lifeblood of the company. A well-labelled repository of documents makes it easy to mine for insights and leverage the analysis captured previously by others. This enables a company to respond quicker to market opportunities. Many times, in the past, when we were given a project, and the prior knowledge was buried and scattered far, deep, and wide, about 30% of the project timeline was deferred until we were able to locate all the information about a current system or process. Most projects cannot proceed until you have all the information about the current state of the system or process you intend to upgrade, migrate, or replace. Gaps in knowledge always lead to delays, frustration, and can substantially affect the quality of the results. The faster you can pull together the information, the sooner your team can get started in making business benefiting changes.
This is not intended to be a complete list of all the benefits of a metadata-backed document management system but should be enough to get you started. Once there is a consensus on the need and benefits of change, you can proceed with user communities who are engaged and motivated to work together with the IT team.
A Methodology for Planning a Document Management Strategy
As mentioned earlier, where possible, work through your document management strategy on a department level and expand out to adjacent departments and so on until completion. The reason for this incremental approach is to ensure you avoid the “one size fits all” trap where you create a mediocre architecture that does not closely fit the needs of the different parts of your business. Trust that your users understand their corner of the business and that they are best positioned to tell you what Content Types and metadata makes sense to achieve the overall goal which is to optimize the search and retrieval of information.
Let us suppose that the first department you will tackle is Marketing or, for larger organizations, a subset of that department which is focused on ad campaigns. AFTER these stakeholders understand that benefits of implementing a new document management system and are sufficiently versed in metadata such that they can tell you what it is and why it is helpful, you are ready to start defining the information architecture. Under the authority of the sponsor, we recommend starting with a small advisory committee of 2-3 people that can represent the needs of that corner of the business.
It is best to plan a series of meetings where you identify the types of documents (or files e.g., Images) that their department regularly uses. Any file type that will need to be found again is in scope. This may take a few sessions where the team will need to go away, do research with their team, looks at the existing file systems, and then come back to continue the discussion based on the real business needs.
The goal of these initial meetings is to come up with a list of types of distinct Content Types that could be applied to most documents/files they use. Keep saying the phrase, “What is it?” You should be able to ask the question and get a concise categorical answer for every type of document they use.
The most successful organizations capture this on a spreadsheet in a Content Types column, similar to below ahead of implementing.
Physical Storage Location Mapping
The next step is mapping to location. We are assuming you will be creating new Libraries, and possibly new Sites as well where the documents will be stored. Related Content Types should go together. You will also separate document types into different sites and libraries based on practical issues like which team practically needs to have access to the documents. For example, a knowledge worker in charge of buying advertisements likely does not need access to the original photos that are used in those ads. Similarly, the photographer or graphic designer probably does not require access to the budget files for ads or P&L for the division. These physical organizational decisions are more managerial decisions than information architecture decisions, so be sure to consult the appropriate managers to complete the first column in the spreadsheet above for the libraries and for the sites that will contain those libraries which in turn contain the Content Types.
Drilling Down to Metadata
Now that you have identified the Content Types and grouped them into proposed storage locations (you should not have done anything with SharePoint thus far), your next challenge, in consultation with your advisory group is to determine what metadata you should be capturing for each Content Type.
Keep in mind the main goal and repeat it to your group. You need just enough metadata to be able to identify and retrieve a document. If you end up with more than one screen of documents all with the exact same metadata, you may not have been precise enough. But be careful not to fall into the trap of “Nice to Have” metadata. Ultimately, these columns, will be ignored and will clutter your user’s screens. This is a very important step in the implementation’s success.
The best way to do this metadata inventory is to go through each Content Type and brainstorm. Put it on a chart like the spreadsheet above, then go through it multiple times whittling down to the necessary metadata columns.
A very helpful indicator of metadata you should include is to look at the folder structure where the current documents are stored. Those folders are often precisely what should be converted to metadata.
For example, if your budget files are stored in subfolders like this:
You likely need metadata columns for Department (Engineering), Content Type (Budget), Fiscal Year (2019), Fiscal Period (1), Status (Approved).
In the spreadsheet above, you can see columns added for each metadata property as well as what type of column this could be in SharePoint.
Key Types of Metadata Columns in SharePoint.
As you complete the matrix of Metadata and Content Types, look for commonalities in metadata columns that can be used in multiple Content Types. This will make managing the Content Types more efficient.
What About Microsoft Labels?
If anyone raises the need to have metadata columns for the purposes of identifying a document’s security level or retention requirements, please look alternatively at Microsoft’s 365 Sensitivity Labels and Retention Labels. Microsoft Labels is a complementary, but adjacent technology intended for a different purpose. Metadata should be primarily focussed on improving the searchability of documents. Microsoft Labels are not a substitute, nor a replacement of proper information architecture based on Content Types and metadata.
Once you have your matrix chart completed, ensure nothing was missed and no redundancies or obsolete content types or metadata exist. Getting sign-off is always a good idea before you start to create the Content Types, metadata site columns, and build libraries. Involve your sponsor before you do any work in SharePoint.
After the libraries are built take some time with the team to create helpful Views. A SharePoint View is critical since the exposed columns can be used for filtering files.
Change Management
If you build it they will come? According to the movie “Field of Dreams” after a period of disappointment, just keep believing and people will come. That is fantasy land. To gain adoption of a newly minted document management system requires more that simple faith.
You have started on the right foot by building a system in consultation with representative of your users. Now, the key is for that group to become the champions in the presentation, training, and monitoring of the system. Your expectations are that the group will use what they agreed to use.
It also helps, since old habits die hard, if possible, to make the prior libraries or file share read-only after training is complete. All new documents should thus be created in the new system. Over time, the important documents from the prior libraries can be moved over, starting with the actively used documents and then going back in time.
Here is where a tool like Colligo Content Manager is helpful for ingesting files from file shares into your new SharePoint libraries. Metadata can be set for groups of documents at the same time to save time. Also, since email is the source of the majority of key new records, a tool like Colligo Email Manager is invaluable to copy or move emails and attachments into SharePoint fully tagged for shared access.
Monitoring the success of your first department is essential so you can fine-tune and adjust before you “Wash, Rinse, & Repeat” the process for an adjacent department and so on until your entire organization has a robust information architecture in place for all their documents.
In conclusion, the keys to a successful deployment include:
- Pre-sell the benefits of a metadata-backed document management strategy
- Work with one department or workgroup at a time
- Engage an advisory committee within that workgroup to design the architecture
- Plan the design “on paper” and fully socialize and vet the design before implementing a single change in SharePoint.
- Use change management to ensure full adoption or the system
- “Wash, Rinse, Repeat” for the next workgroup
This concludes our brief series on practical guidance for implementing metadata in SharePoint:
- Part 1: What is metadata? Show me, don’t tell me
- Part 2: Metadata content types
- Part 3: Creating a usable Information Architecture
We do hope it saves you from committing common missteps and helps you get a clearer picture of how to tackle what can be a daunting project. We would appreciate your feedback on this series or questions which will be helpful for creating a new iteration in the future.
Whether it’s capturing emails to SharePoint and adding metadata to Microsoft 365 files for discover, retention or compliance purposes, or bringing SharePoint into Outlook to make workflows more productive and efficient through collaboration, Colligo can help your organization improve productivity and support the modern digital workforce. Give us a call to find out more!
