SharePoint Intranet Implementation Critical Success Factors

19 May 2011, 6:58 pm

There are many factors that will play in to the success of your SharePoint Intranet implementation. Below you will find the ones I have found to be the most critical; meaning, if you fail at these, the chances of your implementation succeeding are significantly reduced. I will take a deep dive in to each of these critical success factors in separate articles; each article describing what the business and technology needs are, common implementation mistakes, how you can avoid those mistakes and implementation examples.
1. 2. 3. 4. 5. 6. 7. 8. 9. Thoroughly understand what it is you are building Focus on solving business problems/needs Implement and roll-out in small incremental cycles Simplify the contribution and management of content Promote findability Implement technology and solutions that promote the agile evolution of information use Promote trust and confidence Govern the implementation, use and change of your implementation Educate all levels of users

Filed under SharePoint Adoption, SharePoint Intranet Implementation, SharePoint Use Tagged SharePoint, SharePoint 2007, SharePoint 2010, SharePoint Adoption, SharePoint Design, SharePoint Information Architecture, SharePoint Information Management, SharePoint Project Management, SharePoint Roadmap, SharePoint Use

CSF Thoroughly Understand What it is You Are Building

I know, this sounds somewhat ridiculous right? Of course you know what you are building; an Intranet! One thing I have learned over the years is to not assume everyone has the same understanding of what an Intranet is. Ask 25 different individuals in your organization and you are likely to get 25 different answers. In most cases, the old Intranet was implemented as a .NET/ASP.NET application and was managed entirely by IT. When new documents and pages needed updating, typically an e-mail would be sent to the resposible individual/party in IT and the Intranet would be magically updated. Is this the same goal for your SharePoint Intranet implementation? Do you wish IT to continue with the responsibility of managing and maintaining page content, links and documents on your Intranet? That certainly is one approach but not the normal. Most IT individuals have a vision of reducing this burder, pushing the responsibility and accountability of information management back on those who own it. Okay, back to my original question; so what are we building here? If your goal includes pushing content management responsibilities back in to the hands of those who own that content, improving the sharing of corporate information assets, improving corporate collaboration and so on, it sounds like you are building a Corporate Document Management or Knowledge Management solution. I dont personally have an issue with you continuing to call your implementation an Intranet. However, it is imperative everyone in the organization has a consistent and clear understanding of what that is. If your old Intranet has some corporate bad vibes, consider calling it something else. Regardless, make certain everyone thoroughly understands they will

be taking back the responsibility and accountability of their information assets (documents, page content and so on).
Common mistakes

The biggest mistake you can make, regarding this CSF, is to underestimate the amount of education that will be required to reduce ambiguity and promote a clear and consistent vision for your Intranet.
How can you avoid these mistakes?

Educate, educate, educate! I cant understate the importance of educating your culture as to their roles and responsibilities with regards to moving off the use of file shares to managing their content in a new document management solution. If you are a technical wizard, you may find this change to be quite simple. However, most non-technical users will not. As you begin working with the members of each department or division in your organization, I recommend educating them first. If you have ever been exposed to the incremental implementation lifecycle I use, the first and last elements of this lifecycle are education. Start by educating the individuals, telling them what it is you are building, why you are building it, what roles they will have in building the new solution and what on-going responsibilities they will have once it has been deployed.

CSF Focus on Solving Business Problems/Needs

It is critical that you focus on solving business problems, not rolling-out technology widgets. As I have indicated in other articles, you must detach the non-technical user from the technical details. Simply rolling-out a site, blog or wiki doesnt necessarily solve a specific business problem. And, if we arent solving business problems, the culture is less likely to get excited about our solution and use it. Take the time to understand who the users are and what their dayto-day business problems are; then speak to them. For example, if the Procurement department is telling you they are having difficulty delivering their training materials to the organization, dont provide them with a wiki, provide them with a training solution that solves their problem. Once again, you must remember; if your solution isnt adding value to the day-to-day operations of your organization, users will not get excited about it and may not use it to its fullest potential.
Common mistakes

Common mistakes include rolling-out technology instead of solving business problems. Simply providing users with sites, web parts, blogs, wikis and so on, doesnt solve business problems.
How can you avoid these mistakes?

Take the time to understand your business needs. Meet with real business users and listen to what difficulties they have conducting their day-to-day business operations. Determine what can be done to help them out and discuss how it can be accomplished; try and use non-technical terms! CSF Simplify the Contribution and Management of Content

Many Intranets I have seen over the years have been implemented with the focus being on a single consumer audience. This model may work well for an Internet (public facing) site; however, I contest it is a model that doesnt work well for Intranet implementations. First and foremost, we have to implement a consistent model that makes the contribution and management easy for those who are performing updates and managing content on a day-by-day basis. This requires us to separate the content contribution model from the visual representation of that content.
Common Mistakes

If you focus on the visual representation model first and use it as the basis for your contribution model, you will most likely have the following difficulties: 1. Your visual representation will most likely only solve a single contextual need; meaning, it is quite common we have to re-purpose content to aid with different contextual business needs to support aggregation, search, dashboards and so on. 2. Targeting content to be stored in a single location will require addition security, governance and maintenance. I will explain more below. 3. Content contributors will have to remember, or bookmark, all the various locations on your Intranet needed to get their jobs done. Lets first take a look at the single location for storing, managing and visualizing content of a specific type. This is the common implementation model I see most often and the one I rarely use on Intranet implementations. Corporate policies are common throughout most Intranet implementations, so I will use this as a basis for the following examples.

In the example above, all contributors and consumers visit a single site where corporate policies are managed. This is, by far, the easiest implementation approach in SharePoint; however, not the easiest to manage. The biggest problems you will encounter with this approach are forcing the contributor to go to this site to manage their documents and the management of policy document security. First, an employee who works in the Human Resources department should be able to go to a single Intranet destination to perform all of their day-to-day duties. Approaching the contribution and management of content using this type of model will make the contributors and owners of that content much happier. Secondly, if you store all corporate policy documents in a single document library on a Corporate Policies site, you will need to manage item level security. If you dont do this, every contributor will have the ability to modify other departmental policies; and it will happen, I guarantee it. I know, you can overcome the item level security maintenance nightmare in a few different ways; use folders (doesnt promote findability, ugly navigation), use a document library for each department (doesnt solve the problem with simplifying the contribution and management of the content). Also, dont forget about the different contextual needs you will encounter with regards to content consumption.
How can you avoid these mistakes?

Now, let me introduce you to a couple of alternative implementation models that will solve all of the problems described above!

The alternate approach displayed above uses a model where corporate policy documents are stored and managed at the department level. Meaning each department is responsible for managing their own corporate policy documents. This in itself solves the security model problem; you only need to manage the contributors for each department at their specific site level. In addition, each departmental employee goes to their specific departmental destination to manage their corporate policies; thus simplifying the contribution and management of their content. Another note; this also aids with solving that age-old question where do I store and manage my content? This approach also provides you with the All Corporate Policy document view found on most Intranets. The key to this approach is to uniquely identify documents of type Corporate Policy. We accomplish this by using SharePoint Content Types. Most Intranets I implement have a Content Type named Corporate Policy Document. I assign this Content Type to each of the departmental specific document libraries where corporate policies are to be stored and managed; the difficult work is done! You now have corporate policy documents positioned in a manner that allows you to aggregate them in many different ways too. For example, its quite easy to create a search scope on all documents of type Corporate Policy Document, located in the Operations department or Finance Department.

The second alternative approach displayed above has the same basic site structure, contribution model and use of the Corporate Policy Document Content Type. The only difference in this model is the documents being published to the Corporate Policy aggregate site in a PDF format. Again, this is only an alternate approach and will cost additional budget to implement. However, some companies would prefer published corporate documents be delivered on an Intranet in PDF format; thus reducing the read/view tools required by the consumer.
Conclusion

The suggested models I have provided above are not difficult to implement or complex in any way. My goal is to change the way you think about separating the storage, management and visual representation of content. If you have any questions or comments about the implementation approach suggestions above, drop a comment below and I will respond!

SharePoint Design: CSF Trust: Giving users a sense of trust with in the information they are using
21 October 2010, 8:40 am

Many do not realize the bridge business users must traverse when moving their documents from local drives and file shares to a new document management solution; this can be overwhelming

to many. Thus it is imperative to implement a solution that promotes consistent trust in the technology. If users find the solution difficult to use, they tend to revert to what worked in the past. One goal of most document management solution implementations is to reduce the amount of document duplication in an organization. For this to become a reality, users must trust your document management solution as the single source of truth. Changing a cultures thought process around the management of documents and trusting they are safe, secure and the most recent version must be accomplished to satisfy this goal. Means of accomplishing this include:
1. 2. 3. 4. Driving governance, evangelism and adoption techniques from the top down. Implement consistent site structure and data taxonomies. Implement a consistent (federated) security management model. Deliver on-going education.

SharePoint Design: Findability: Promote the dissemination of information (content) through navigation, aggregate views, dashboards and search
19 October 2010, 11:34 am

The term findability refers to a solution that provides meaningful and accurate information to consumers (personas) that proactively supports business decisions. Once CSF #1, simplify the storage and management of content, has been addressed and solved, it will then be important to aggregate, disseminate and deliver that information to consumers in a meaningful and accurate manner. At a minimum, findability should address the following:
1. A consistent taxonomy for navigation through sites and content. 2. Aggregate views of information to support common business contextual needs. 3. Produce relevant search results within the scope and context of business users needs.

Navigation As the results of user interaction and usability tests have shown, Intranet users have a tendency to point and click their way to content versus using search. For users to quickly and easily navigate an Intranet, it is imperative consistently structured navigation and content taxonomy be deliberately designed, implemented and maintained. As noted in CSF #1, if users are unable to quickly locate their content, they have a tendency to revert to old habits; which can include duplicating the content by storing it in a local repository. Aggregate Views and Dashboards There are many common business contextual needs that can be easily satisfied through aggregate views and dashboards. Some examples of this would include Policies & Procedures, FAQs, Glossary of Terms, New Employee Resources, My Project Tasks, My Collaboration Sites, etc.

In the example figure above, each department is responsible for storing and managing their own content, Policies & Procedures, FAQs, Glossary of Terms and so on. This type of content, when modeled appropriately, can easily be aggregated to views and dashboards thus satisfying various business contextual needs. Search As an Intranet solution matures, user adoption increases and the amount of content grows, there will inevitably become the need to produce accurate, relevant and meaningful search results. Unfortunately, we cannot rely simply on the full text search within documents or the default (out-of-box) search configuration of SharePoint to produce these types of results. However, SharePoint does provide us with the technology we can configure to accomplish these goals. The technology and techniques we can use to obtain these goals include:
1. Structured approach to using Search Scopes. 1. Search scopes to limit content based on destination. 2. Hierarchical search scope implementation to automatically limit content based on current location. 2. Use of metadata to support specific contextual needs. 3. Configure common keywords and best bets.