I’ve been building Intranet Portals in SharePoint for decades and argue that the key to success is to start out with a simple and basic concept for how information is going to be organised, structured and managed.

In this article I will outline what I have learned over my 25 year jouney of doing this. I’m not arragant enough to push this as the only way, or even the best way in all cases, to build an Information Architecture (IA). Every organisation is unqiue and that uniqueness is important or else everyone’s Intranet would be identical. However, I am confident enough to state that the concepts I oultine in this article are enough to set you off in the right direction.

Designing a workable IA is not rocket science, it is just about having a plan for what documents should go where and how that information should be secured or made accesible to users. Once you crack that, the rest just falls into place. Let’s talk about a few key concepts.

What do I mean by “Document”?

Let’s start at the beginning by establishing a clear understanding of what I mean by the use of the word “document”. In this context I use “document” to mean an information product in a general sense, regardless of format and medium rather than limiting ourselves to simply Word and PDFs.

This wider remit would include site pages, news article, video recordings of meetings and PowerPoint slide decks in addition to spreadsheets, Word documents and PDFs.

But at the same time I am narrowing our focus to exclude what I can Transient Documents, which are those information products that simply oil the machinery of how we work but which have no long-term standing value to organisation. Probably some 90%+ of email and chat messages fall into this category.

Don’t get me wrong. I’m not saying these products have no worth. An email notifying me that there has been a last minute change of meeting room for that important customer meeting might be invaluable! But, such products have no long-standing worth and therefore don’t need to be formally managed with in our IA. The should be disposed of as soon the become obsolete but too often they are not and simply add noise when users try to find relevant content via the search engine.

The focus for our AI can safely exclude Transient Documents and focus on the 2 other principal classes of documents:

• Controlled Documents: Those documents used to govern business processes, which typically include Policies, Procedures, Form Templates, SOPs, Guidelines etc.
• Transaction Documents (Records): Those documents received into the organisation or generated by the organisation, which collectively record the execution of a business process, and hence why there are often simply referred to as Records. Think of a procurement process which might involve RFQs, POs, Invoices and Receipts.

If you want the read more on views my views of document types and classes, please check out this post All documents are created equal, but some are more equal than others! – Innovations in SharePoint

Spaces

I argue that conceptually, there are just three spaces in which we (should) store documents.

The above graphic is technology agnostic, in that it still applies regardless of whatever products you might be using, and consists of:

• Consumer Space: When users go to find information and access online services.
• Production Space: Where users work collaboratively to execute business processes which involves processing information and creating new documents.
• Archive Space: Where obsolete documents should be retained for reasons of regulatory compliance or because they have historical value.

However, my context is SharePoint/M365, and so here I am taking about the sites in which you might store documents in SharePoint Online. Remember that even if you file based upload documents to MS Teams, they are stored in the SharePoint Team Site that sits behind every MS Teams Site.

NoteSharePoint Team Site and Microsoft Teams Sites can be confusing for users because they are different and distinct entities but which are related and have similar sounding names. I can’t help but feel that Microsoft might have done better job of product naming here, to minimise user confusion – personally, I would have called Teams, MS Collaborate but we are where we are.

SharePoint Team Site and Microsoft Teams Sites can be confusing for users because they are different and distinct entities but which are related and have similar sounding names. I can’t help but feel that Microsoft might have done better job of product naming here, to minimise user confusion – personally, I would have called Teams, MS Collaborate but we are where we are. SharePoint Team Site and Microsoft Teams Sites can be confusing for users because they are different and distinct entities, but which are related and have similar sounding names. I can’t help but feel that Microsoft might have done better job of product naming here, to minimise user confusion – personally, I would have called Teams, MS Collaborate but we are where we are.

Lines

When engaging with customers I talk about these different spaces but in an attempt to make things easier to understand I introduce the concept if “lines” which might logically separate the digital spaces their IA.

Above the Line

This is the space for consumers, and the documents stored here will include authoritative published versions of organisational Controlled Documents and some Records such as news articles or recordings of Town Hall meetings or position-vacant notices for internal recruitment etc.

This is typically what most organisations call their Intranet. For a small outfit, this might be a single SharePoint Communication Portal site but for larger organisations, the modern way is to split the Intranet across several separate physical sites, but logically think of it as a single entity, in what is commonly referred to as a Hub and Spoke architecture.

The key points to note here are:

• Documents stored above-the-line are readily accessible to everyone in the organisation – if they need securing to a reduced audience, they have no business in this space.
• Most users require read-only access as they are simply consumers of the information.
• Specific users, will need to manage content and so will require read and write access, but generally not everywhere – they might be granted edit permissions selectively (on different spokes) depending on their role, knowledge, and experience.

The most significant consideration for the design of Above-the-line spaces, is that design should be functionally based and not built simply to reflect the org-chart. That is to say, it should align with what the organisation does and not with how it happens to be structured from a managerial perspective.

Building an Intranet that aligns with the org-chart might seem logical, and it is indeed what we pioneers used to do before we learned better.

It is also what amateurs tend to do. I love to recall a government department I work with which had based their SharePoint IA around directorates. This resulted in HR, IT, Finance and Procurement documents all being stored not just in a single site but within a single library within that site. It took over a year to unpick this!

Aligning you Intranet with your org-structure is a bad idea for the reasons that I outline below.

Organisational structures are volatile

Management structures are volatile and can be changed dramatically, seemingly at the whim of senior management. In the above-mentioned government department, the directorates where restructured 3 times within and 18 month period!

If you build you Intranet around business functions, the structure will be far more stabled and won’t require constant ongoing reorganisation. What an organisation does, might change over time but think of this as glacial change to the landscape rather than volcano!

There is not always a 1-1 mapping between function and department

In some cases, there is an obvious one-to-one mapping between business function and business unit, for example all IT support is provided by the IT Crowd.

However, there may be business functions that transcend organisational boundaries. For example, procurement might be handled by different departments depending on whether you are trying to buy paperclips, laptops or forklift trucks.

Furthermore, some functions like Work Health Safety (WHS) might have a lead department or team, but are considered everyone’s responsibility and the contexts will be very different. WHS for workstation ergonomics (might be HR’s responsibility) is a decidedly different context from emergency/evacuation (Buildings and Facilities) and from warehouse management (Logistic Operations).

Different purposes

Intranets are where users go to find information and access online services and not where they go to create new content, and so should be designed with that objective in mind.

If I need to buy paperclips, I should be able to navigate the Intranet space unaided to find the information I need. It should be designed based on helping me achieve a business outcome (buying paperclips). I shouldn’t need any prior knowledge of the organisation to get me to where I need to be.

Below the Line

These are collaborative working sites which are typically SharePoint Team Sites or MS Teams Sites (the latter using the former for document storage). Collaboration generally occurs within a managed subset of users, in just 3 distinct contexts:

• Business Unit/Team: Where are users belong to the same business unit or working team, such as the Finance Team site.
• Communities: Cross functional collaborative working. Think steering groups, committees and management boards, or even staff social clubs.
• Projects: Collaborative working within the context of a project.

The only discernible difference between a Community and a Project space is that Projects have a lifecycle in that when the project is complete, no further collaborative working goes on, whereas Communities tend to continue indefinitely.

The key points to note here are:

• Generally, users will be granted both read and write access to documents. Indeed, in MS Teams (or more accurately M365 Groups) there is no such thing as a read only (visitor) role. You are either in the team, or you are not!
• Accessibility is tightly restricted to the relevant sub-set of only the users who have business within that space.

Beyond the Line

Sadly, an archive space is missing in most SharePoint IAs that I come across. The Archive is where obsolete records should be preserved for reason of regulatory compliance or because they have some long-term historical value to the organisation.

The key points to note are:

• This space (if it exists) is likely to be managed by Records Managers and may be structured differently to how the documents were stored in the above-the-line and below-the-line spaces.
• Normal users may have no direct access to the archive and can only retrieve content by request to the Records Managers.
• Records are only be disposed in accordance with retentional and disposal schedules as governed by the Records Managers.
• It is more likely that records will be archived from the below-the-line spaces as that is where most records will reside.
• Documents in the above-the-line spaces will more likely be published renditions of source documents stored below the line, and so these renditions do not need to be treated as records or retained and so can simply be disposed of when obsolete.
• A common exception to this would be news articles as they a normally created in an above-the-line space directly.

Of course, your organisation might not manage records in SharePoint at all. It could be that you are using some other Electronic Document and Record Management System (EDRMS) and if you ask any professional Records Manager the will tell you that SharePoint in not an EDRMS because it (currently) lacks the tools necessary to implement and manage retention and disposal schedules in standards-based way.

I tend to agree that currently Microsoft do an excellent job with providing tools to create and share documents but don’t yet provide a toolset that adequately covers the records management part. That might be changing with Microsoft Purview but Microsoft have some way to go here. What RMs want is a way to import an RM standards (and not just US ones) which are then used to monitor and govern document retention and disposal.

I shan’t dwell on Records Management anymore in this but will save my more detailed thoughts for another day.

Reading between the Lines

It is a common scenario that documents, ultimately destined for the consumer space, are drafted in collaborative working spaces. This implies that there is an approval process. Somebody decides that the draft is ready for consumers. This typically means that the document is “published” so that consuming users can access them. But what do we mean by “publish”?

This is where things can get confusing, because when Major/Minor versioning is enabled on a document library, Microsoft use the term Publish to mean when the document is approved as a major (or the next major) version.

In my article SharePoint Document Version Control and Content Approval works but… , I describe how you can set things up so that consumers only have access to major document versions, leaving collaborative working to go on with minor versioning in the background without changing was consumers see, until the next major version is published. On the face of it, this approach seems very attractive because we don’t need to move documents anywhere. This is a true, single source of truth!

However, in reality, this approach only works well on a small and localised scale. Things get mightily complicated when you need to permission parts of a site differently. It is just all too easy for users to get things wrong and set permissions incorrectly, leading to a greater risk that users have access to the wrong document versions at the wrong time. To put it more simply, governance becomes a nightmare!

Added to this, many organisations prefer to release most of the documents to consumers in PDF rather than their source document version, typically MS Word. There are several reasons for this including:

• PDF is more reliable when printing documents such that formatting is better preserved.
• PDF is perceived as read-only and therefore consumer orientated format.
• User perception (rightly or wrongly) is that if someone has gone to the effort of PDF’ing a document, that must somehow make it more authoritative and is therefore more trusted.

When I use the term “publish”, it means more than simply approving a document as a major version. I mean making the approved major version accessible to consumers. If that means we need to generate a PDF rendition of the source document and host that rendition somewhere else, in an above-the-line space, so be it. “Publishing” is about achieving the desired outcome of ensuing that consumers access the latest approved version of the source information. Declaring the document as an approved major version may be only part of achieving that outcome.

Bi-Polar Functions

There are some business areas which have both an inward responsibility to ensure that records they manage are secure and the wider organisation should not be granted arbitrary access but there is also an outward facing responsibility to share content across the organisation.

I call these Bi-Polar functions and HR is the most obvious example. The HR must keep confidential records such as employee contracts, training records and performance reviews secured so that they can only be accessed by key personnel. Yet there are other records such as Employment Opportunity notices which need to be made accessible across the business.

IT is another Bi-Polar function where technical specifications or configuration documents and the like are clearly relevant to the IT technical support team but user manuals need to be shared with all users.

There are 2 approaches to this. The first is to set up each Bi-Polar as a spoke in the above-the-line space and grant the appropriate staff access to upload content to the appropriate spokes. This works well if the business function must be supported by Site Pages and not just documents.

However, when there is a need for sharing consists of just a few documents the overhead of a separate site might not be justified. In which case, you can set up a Shared Resources spoke site and furnish that with appropriate lists and libraries and set the permissions at the list/library level rather than at the site.

Room for Improvement

Microsoft do a great job of providing a toolset for most purposes. SharePoint is an excellent Document Management System (DMS) although it still currently falls short of what most professional Records Managers would call an EDRMS.

That doesn’t mean SharePoint is perfect, far from it, and in recent posts I have highlighted some of the way in I think the product could be improved:

• SharePoint Document Version Control and Content Approval works but…
• What’s Missing in SharePoint Document Management
• The SharePoint Document Library Web Part – What is it good for!
• D3 Virtual Tree Visualisations of SharePoint Document Libraries

Rather than wait on Microsoft to come up with the needed improvements, we at Kaboodle Software developed a family of products, called K-Docs, that we believe address some of the capability gaps in the OOTB Microsoft offering:

• K-Docs Approve: Our role-based, state machine solution to track and monitor document approvals.
• K-Docs View: For consumer users who need to quickly find the key documents to do their work.
• K-Docs Publish: When you need to push documents, individually or in balk, to a different site and optionally convert them to PDF or publish Word documents as Site Pages as a SharePoint Modern wiki (ideal for Bi-Polar functions)
• K-Docs Acknowledge: When you want to build reading lists and record user acknowledgements from as part of a compliance management system.

All these products are Freemium, meaning they are full-functioning solutions which can simply be downloaded and used – you don’t even need to register. You only need to move to a licensed-paid tier if you decide to unlock advanced feature.

In my next post I will provide an overview of these products and describe how they might be used together as part of you IA to improve information management and governance.