If the first question is, what makes a SharePoint information architecture (IA) successful? The second question should be, how can I measure whether my IA has been successful or not?
Many organizations commence defining and implementing SharePoint with very little thought into not only what constitutes a successful IA, but also how success will be measured.
Also, what makes a SharePoint IA successful in one aspect, may not make it successful in others. For example, succeeding in having an IA that is just like what users were used to on a network drive may mean very little change is necessary but may result in an IA that isn’t sustainable in the long term.
Creating a Successful Information Architecture
Ensuring a successful IA involves articulating some different elements:
- Why do you want to move to SharePoint?
- What are the deficiencies with the current solution?
- What works well with the current approach?
- Can the organization cope with change?
- How can you take advantage of SharePoint’s functionality?
- What are the organizational requirements?
- What SharePoint implementation approach will you use?
In this post, we will look at each of these elements.
Why Do You Want to Move to SharePoint?
Asking why you are looking to implement an alternative solution is perhaps the most important question of all. Responses may include:
- Increased information re-use
- Decreased content duplication
- Single source of the truth
- Enhanced collaboration
- Enable external sharing
- Increased security and auditing
- Increased reporting capability
- Increased information discoverability
- Increased user adoption
- Decrease/eliminate information silos
- Consolidate multiple platforms/solutions/repositories
SharePoint is not a silver bullet. Without articulating the “why” there is a risk you will end up with a solution in SharePoint that has the same deficiencies as your existing solution. This view does assume your existing solution has deficiencies, otherwise, why invest in something new that’s the same as what you currently have!
In addition to not replicating the mistakes of the past, articulating the above starts to give you some success factors, or mission statements against which you can benchmark your proposed solution.
What are the Deficiencies of the Current Solution?
Identifying the deficiencies of the current solution may seem like an obvious thing to articulate. It does, however, also have a side benefit.
Articulating the deficiencies of the current solution, in conjunction with user surveys, will enable you to “sell” the proposed solution to business users to drive adoption. Without a carrot to encourage users to adopt the new way of working, users will typically fall back into old habits.
There is a saying: if you build it, they MAY NOT come! A SharePoint IA and implementation that looks great on paper may not guarantee user adoption. If user adoption is low, then the project has failed.
Typical user feedback about legacy environments includes:
- The structure I need to use to navigate content doesn’t make sense to me.
- I can’t find anything.
- When I find a document I am looking for, I take a copy and put it somewhere. How can I see it again?
- I find multiple copies of the same document. Which one is the current/approved/endorsed one that I should use?
- I need to share documents externally (and perhaps have other tools to do this, e.g., email, Dropbox, Box).
- I can’t be sure of who can view and edit the document.
- If someone modifies a document, I can’t revert to previous versions.
- I share and manage lots of documents using email. This approach makes it difficult to have a central copy for everyone to edit.
- I must complete too much metadata to store the document.
- I must provide the same information multiple times and in multiple places.
What Works Well with the Current Approach?
Capturing what works well with your current system/approach is just as important as documenting what doesn’t work well. When implementing a new solution, it is just as important to make sure you don’t TAKE AWAY functionality that people have grown accustomed to, as it is to be able to show users added value.
If existing functionality is likely not to be supported/required in the new system, it is also important to be able to explain to users why this is the case. It is even more advantageous if you do not need the functionality due to the new solution simplifying processes and therefore rendering the legacy functionality obsolete.
One of the most common pieces of feedback you are likely to receive from users is that the structure needs to be flexible in its ability to meet MY requirements. Note that this statement is from a personal rather than corporate perspective, and typically directly conflicts with the ideas that, “I can’t find anything,” and, “I find multiple copies of the same document. Which one is the current/approved/endorsed one I should use?”
The above findings usually indicate the requirement for some level of governance. Having users that are happy that they can store their information, but not find information from the broader organization is something that can be very easily replicated in a new system if not recognized early.
Remember the earlier points – if we are going to repeat what didn’t work in the past, why are we spending the money?
Can the Organization Cope with Change?
The key to a successful SharePoint IA and implementation is assessing the organization-wide requirements for information management. Once you understand these, you can define an approach can that not only meets the requirements of individuals but also meets the overall organizational requirements.
Point solutions or team specific solutions are typically not the best way to approach SharePoint. Feel free to tailor SharePoint for teams but start with an agreed corporate template.
Understanding the tolerance of the organization towards change will influence how radical you can be with your departure from the current state. Remember though; if you can get buy-in from the top, it doesn’t hurt to challenge the organization.
One example of a common theme with SharePoint is to let the organization implement folders, rather than educate users on the benefits of metadata structures. A folder structure is usually complicated to govern, and therefore grows organically and results on the kinds of themes we see in the “what doesn’t work well with the current solution section.
This approach causes a need to revisit/re-architect the information architecture in 12-18 months. Unfortunately, this is only a lesson that is learned when it’s too late.
How Can You Take Advantage of SharePoint’s Functionality?
SharePoint includes an excellent feature set. As a result, there are usually different ways of achieving the same outcome. Knowing which feature options will meet the requirements of your organization and be maintainable in the future can be somewhat of an art form, and usually only gained from bitter experience.
Typically, if you consult the user base, they will want to do things the same way they currently do. This approach is in their comfort zone. People are naturally predisposed to avoid change. With SharePoint, this may not always be the best approach. Remember, we are trying not to repeat the mistakes of the past.
Knowing what options SharePoint provides, the benefits of each, and being able to articulate this to the business is essential to ensuring you get the buy-in of users and avoid ending up with the same issues you have with your current environment.
Here are some questions to think about when applying SharePoint functionality to your business requirements:
- When to use metadata instead of a folder structure
- How are document sets different from folders? What are their advantages/disadvantages?
- When should I use specific content types?
- What are the differences between a site collection and a site/subsite? When would I use each?
- What are SharePoint views? What are the advantages/disadvantages of each?
- What are libraries? How do they differ from folders/document sets?
- What are the options for versioning, and the advantages of each?
- What are the risks and benefits of the explorer view?
What are the Organization’s Requirements?
As mentioned previously, SharePoint provides an extensive suite of functionality out of the box, not to mention the multitude of off the shelf add-ons. Identifying which to implement when is key to managing the organizational change when deploying SharePoint. Introduce too much functionality at once, and users get overwhelmed, introduce too little, and they may feel that the new system is a step backward, and doesn’t meet their requirements.
Typically, the ancillary functionality of SharePoint, like workflow, reporting, or a line of business application integration relies heavily on a robust information architecture as a foundation.
Acknowledging the requirement to introduce functionality like workflow and reporting in the future, and developing your IA will ensure that when the time comes, it will be a relatively simple task to introduce additional SharePoint functions that leverage the IA.
If you develop your IA with a narrow view, e.g., focused on a specific function, or immediate requirement, without consideration for the future, you can easily find yourself not being able to take advantage of the functionality you now need. Alternatively, you might have to embark on an exercise to re-architect an information architecture that users may have already grown to love, thus introducing more, unnecessary change.
What SharePoint Implementation Approach Will You Use?
As previously mentioned, SharePoint is a vibrant, flexible platform, that can be implemented to meet many different business requirements. It is essential that, whatever you do, you enforce some level of governance to the deployment and evolution of SharePoint within your organization. Without it, SharePoint can very quickly become like a virus, resulting in the same silos, and problems as you had with your previous environment.
When engaging with organizations, those whose users typically feedback that they “don’t like SharePoint” or “used to use it but it became too hard to find things” tend to be the ones that have adopted an organic, or ungoverned approach to the implementation of SharePoint. Typically, IT installed SharePoint and then it was up to each of the business units or teams. To figure out the best way to use it – often with little or no consideration for business requirements, or how to implement SharePoint to take advantage of the functionality, it brings to bear.
This approach is a very inefficient way to implement SharePoint. It means that the business area is not able to take advantage of the learnings and mistakes of areas that have gone before them. It also makes for inconsistent user experience across SharePoint, not to mention fostering the silo mentality that goes entirely against the collaborative aspects of what SharePoint seeks to encourage.
Alternatively, adopting a “big bang” approach to implementing SharePoint or consulting the entire business, capturing requirements and building the solution, before deploying to the entire business in one go can lead to “analysis paralysis”, e.g., SharePoint becomes such an unwieldy beast that it becomes too hard to implement, and the project never goes live.
It is for this reason that we typically see more success with the iterative approach to deploying SharePoint. Specifically, the big bang approach usually doesn’t allow for prototyping with a “friendly” area of the business. Conversely, with an iterative approach, you can work with a small area of the company. This approach enables you to perfect the IA in conjunction with these users under the apparent intent that this is what you are doing rather than setting an expectation that it is a production implementation from the get-go.
Perfecting the IA with an area of the business allows you to template it. These templates can then be used to engage with other areas of the company to further enhance and perfect them, based on the requirements of the next team, function or process, rather than starting from scratch. Also, as each subsequent phase progress, the analysis, design and build phases should get faster and faster as each team template requires less and less tweaking.
In addition to the above benefits, the iterative approach enables the instilling and refining of a governance framework for how to manage SharePoint on an ongoing basis. Individually, enhancements and changes will be handled and controlled at an organizational level, ensuring that all elements of the business benefit from the updates, and in turn lead to a consistent experience across the business and across SharePoint.
We hope that this article helps you to make a successful SharePoint information architecture! Subscribe to our blog for more ideas.