Showing posts with label InfoGov. Show all posts
Showing posts with label InfoGov. Show all posts

Saturday, March 21, 2015

Using Document Sets to manage document based processes

The right tool for the right job

In SharePoint, I use a couple tools to manage the processes within my organization.  In the case of process automation, my default is to use Nintex, automating the process where it makes sense and improving the user experience where ever possible.  When I have a process that is document based, I will employ document sets, managed metadata and content types to automate the document provisioning for the process and then employ Nintex for additional functionality.

Today, I want to write mainly about Document Sets and how we can use them to make Document management easier within your SharePoint ecosystem.  One of the greatest difficulties we have in document and records management is the classification and application of Metadata; it is the holy grail, so to speak, of document management and is an area where many third party tools exist to perform auto classification.  In reality with Document Sets, Managed Metadata and Content Types and the support of Nintex workflow and forms, we can do almost anything you need for document classification.

Content Types

I first want to talk about Content Types.  Why? Because a Document Set is a Content Type for one and also because part of the reason we use Document Sets is to manage Content Types within a container.  So, let's get to it...
What is a Content Type?  A Content Type is a piece of reusable content that has a predefined selection of attributes (Metadata) assigned to it.  Think of it like a document template, because in reality, that is what most people use content types for.  Something many users do not realize however, is that with content types, you can build a Taxonomy (Hierarchical Structure) of Content and Metadata and that the taxonomy is explicitly required.  Understand that when we deal with content in SharePoint, there is an understanding that an Information Architecture should be designed and created and you need to do it using Content Types and Metadata. So lets quickly go through Content Type creation so it makes a bit more sense, the following steps were created using Office 365, but they are the same for On Premise or SharePoint Online.

Creating a Content Type

  1. Go to Site Settings
  2. Choose Site content types
  3. In the Site content types screen, you will see all the content types applicable to the site, arranged into groups.  At the very top you will see the Create button, Click it.
  4. Create the Content Type
Notice when we created the Content Type, it asked us for the Parent Content Type?  That is the implicit Taxonomy I referring to.  We can choose any content type as a parent and like real parents, their attributes are passed on to their children and we can then choose what is important, making the information architecture and the result much easier to manage; that even includes Document Templates.

Now this blog is about Document sets, so that is all I am going to talk about Content types for now, but stay tuned in future blogs, I will provide more insight into Content Types and how to use them.

Document Sets

Now you may be wondering what a Document Set is? well simply put, it is a folder within SharePoint that is used to apply shared metadata to all the objects within that folder.  So for example, lets say you have a project, the project has a project name, a project manager, a project number, a sponsor, a status and perhaps a region or other metadata that tells you about the project.  Some of this information is information you would want to associate to your documents, like to project Name and Project Number. Other information, like the Project Manager and Sponsor are not that important at the document level and don't need to be associated.  A Document Set has the ability to decide what is assigned and what is not when you configure the document set.

Another feature of the Document Set is the ability to assign specific content types that can be created within it, much like you would do in a document library or list.  You can pick and choose what can and can not be created within the document set.  Each content type within the document set has two portions of metadata, the assigned metadata from the document set and the content type metadata that was assigned when you created the content type.  Now you may ask, should I add the document set metadata I want to share to each content type I am going to use?  The answer is No, they are independent and your Document set management will be easier if you don't do that extra work.

Finally Document Sets (and this is the reason for the name) allow you to automatically provision a group of documents as a set.  In other words, every time you say > [Document Set Name] it will create a set of however many documents you decide, all ready for collaboration and all with the document set metadata already assigned.  Okay, so enough about all the things we can do with a document set, we created one when looking at content types, lets see what it can do...

Using a Document Set

 I am going to pick up where we left off from the last example as we clicked OK, if you closed out of it, not to worry, you can get back into the document set by going to site settings, choosing Site content types and then clicking on the content type you originally created.

  1. Create all the metadata for the Document Set
    I will add three pieces of Metadata for the demo, Category, Status and Keywords, all from the Core Document Columns Group.
  2.  My intent is that the Category and Keywords are both Metadata fields that are important to the documents that exist in the document set, while the status is only important to the document set itself.  So now I need to go into the Document Set settings (under Settings) and modify the Document Set.
  3. Now to describe the Document Set Settings and what each section does, I have labelled an image and will go through each section, it's purpose and what you need to do.  The only one out of order is the Shared Columns, I want to go through that section first.
    1. Shared Columns -  As I mentioned, I wanted to have Category and Keywords included with all my documents in the set, this is where I do that.  Checked columns are shared to the contents of the document set, unchecked are not.
    2. Allowed Content Types - This is where you choose the content types that are available for creation under the button.
    3. Default Content - This is where you add the documents (not templates) that will automatically be added to every new document set created.
    4. Welcome Page Columns - Document Sets have a custom welcome page layout, at the top of the page is a folder icon, project name, description and any additional columns you want to add.
    5. Welcome Page - The Welcome page can be customized by you, allowing for additional web parts and content.
You now have enough information about Document Sets, start playing with them and you will quickly see way to use them in your organization.  Some additional functionality can also be realized through the use of Nintex forms and workflows and also through the use of Managed Metadata. Stay tuned for future post on how we can use Metadata to create taxonomies, folksonomies and vocabularies, to further add value and structure to our solutions through proper information architecture.

I would be happy to provide answers to this or anything else to do with SharePoint, Information Governance and Information Architecture.  Comments and feedback, good or bad are appreciated, if you like what you see, follow my blog or follow me on Twitter, LinkedIn and Facebook:

Friday, February 27, 2015

Governance Series - How to create a Single Source of Truth in SharePoint

I was in the SharePoint Community site last night and someone asked about maintaining a single source of truth.  One way to do it is to have a central repository for documentation; in SharePoint we would use a record center.  But it brings up a good point of how you would distribute those documents out to the team sites where they are actually used and manipulated.  The answer is simple, we create a new type of document library that can only contain links to documents.  We template it and save it as part of all our site templates instead of a regular document library.  In addition, we could add form and workflow functionality that would allow the users to upload files, but they would automatically be routed to the document repository; but that is for another time.

So how do we do this?  First we are going to need two sites with two document libraries one we will use as the source, the other as the link. In my example I will start with the "Linking" site first, but it really doesn't matter which site is first, only that the document exists in the repository prior to creating a link.

Linking Site

Ok, so we created a new site, lets say it is a team site template.  With a team site and most sites you get a document library named "Documents",  I am going to modify that library and make it a "Link Library".  Now don't confuse this with the "Links" app, which is just a list of hyperlinks.  At the end, I will add the steps to make it into a "Link Library" template so it can be reused.

Creating a Link Library from a Document Library

  1. In the Document Library Click the Library tab then Click "Library Settings"
  2. In the Settings page, Click "Advanced Settings"
  3. In Advanced Settings, under "Content Types", "Allow management of content types?", Select "Yes", then scroll down and Click "OK"
  4. Under "Content Types", Click on "Add from existing site content types"
  5. Scroll through the list and Select the "Link to a Document" content type, Click "Add" and then Click "OK"
  6. Under "Content Types" Click "New Button Order and Default Content Type"
  7. Change "Link to a Document" from "2" to "1" and Click "OK"
  8. Under "Content Types" Click "Document"
  9. Under "Document" Click "Delete this content type"
  10. When Prompted, Click "OK" to delete the content type
Your Library is now configured to create links to documents rather than documents themselves, but I have not addressed the issue of the upload button, but it is simple enough to hide the button or if you want a complete solution you can create a workflow to move uploaded files to a designated location in the repository; to me that is a much better option.  One caveat I want to point out is that the "Link to a Document" uses a URL, not a navigation pane, so you need to know where the document you are linking to is located, the advantage to this is it allows you to cross site collections and farms, but does not provide a great user experience.

Repository Site

The Repository site, like the Linking site contains a Document Library, unlike the Linking site, however, we are not going to manipulate it in the same way.  Instead, we are going to configure it to make it fit for our purpose, which is the storage of documents.  Now I am not going to tell you have to do that, because everyone is different, but some things that you might look at doing include setting up folder containers to classify documents that are uploaded. creating retention and disposition workflows and of course version control.

Test out the solution and let me know what you think.  Based on writing this, stay tuned, I think I like the idea of showing you the Nintex workflows that would go along with ths.

Follow me on twitter @DavidRMcMillan and @DevFactoPortals.  Feedback and suggestions are appreciated and encouraged.

Saturday, February 21, 2015

A Tale of Two Governances - Part 1 Health Benchmark

When you read about governance, it is often focused on what I call the foundational governance.  In the case of information technology (see my definition) we focus on foundational information governance, or the way we intend to use our information within the organization.  This however is only one of two parts of the actual governance needed for the management of our information. The second portion which is often not considered as governance, encompasses the processes and procedures needed to maintain the systems that are used to manage and transmit information.  I refer to this governance as operational governance and it consists of the structure, policies and procedures to ensure a stable and consistent information management solution.

Operational Governance

The governance of the sustainment processes within an organization are typically hit and miss.  Most organizations will have some type of backup and recovery process, but how many have a process for the creation of sites in an ECM like SharePoint?  Now don't get me wrong, some organizations are very dutiful in creating what they perceive as needed for processes to maintain and administrate their systems, the problem is that many do not, and those that do, don't necessarily get everything they need. As a consultant I come into organizations that are experiencing pain, usually in the governance of their solutions, my job is to determine the gaps and remediate them.  Now one of the best ways to evaluate gaps in the operational governance of a solution (regardless of the technology) is to interview the administrators and key business users, perform a health assessment of the system and make recommendations on best practice based on the gaps; in some cases we would then move to remediate those gaps as a final step.  These steps serve to quickly identify what exists and what does not exist and helps me understand the technical skills of the administrative team.

In this first part we will walk through finding our current state, then in a future post we will look at the rest of the operational governance that should be considered to ensure a properly sustained environment.

The Interviews

The first steps in the process are the interviews, in a SharePoint solution I like to site down with the farm administrators, the site collection administrators and the service desk manager.  These three groups or persons can provide insight into pain and into items that take up a significant portion of their daily activity, here are a few questions I will typically ask and why I ask them.  It is also important that you are clear with them about your purpose, as a consultant coming in they may perceive you as critiquing them on their job, but we are there to help them be heard and to fix their pain.

In other solutions, you may have different roles, as long as you can extract the pain and issues for the solution, your interviews can be with whoever can best provide the answers.

Farm Administrators

Farm administrators are your best source of information when it comes to issues with operational governance.  They know the solution better than anyone else and have to deal with everything and anything that goes wrong.  Often it is easiest to just sit down over coffee and a notebook and ask them what is wrong with the solution and what they would fix, then sit back, let them vent and take notes; but I like to have a plan so I typically compile a list of questions to ask before hand (let me know if you have some good questions and I can add them).
  1. Do you have anything that maps out your daily routine? This is asked to first establish the existence of a "Run Book" or standard operating procedures (SOP).
  2. Do you have any tickets assigned to you that are more than 30 days old? If yes, what are those tickets and what is preventing you from closing them?  This will help identify not only gaps in knowledge, but also pain areas in architecture or process.  There is often an in depth conversation into cause and what they would like to see happen to help resolve these issues.
  3. Are there any issues that keep recurring or that never really go away?  This provides insight into pain areas where they may have a work around or an area where they have decided to perform something a specific way and it is not working.  This is another area we will have additional conversations about how they think it should be.
  4. Do you have any performance issues with the current farm?  if yes, do you know the cause? and have you researched a solution? performance issues identify issues with the farms architecture and/or configuration that may be hampering the solution and preventing it from performing as intended.  Also it helps gauge knowledge level and root cause problem solving capabilities.
  5. Which group or groups are the most active on your farm? This will identify who to interview from a site collection administrator perspective, concentrating on the site collections that are the most active and the most need of support.
  6. Do you have remote offices that access the farm?  how good is their connection? Do you get performance tickets from those offices? Often remote connectivity is an issue, identifying where these connections are occurring and if there are issues up front will save you time and effort.  Follow the premise that it is easier to ask the question than search for it, tools are great, but the farm administrator will have insight the tools can't provide.
Notice I didn't ask them questions like how many farms, the servers on the farm, the number of content databases and their size.  These can be asked, but typically you know those things before you begin the engagement and even if you don't, reports from SPRAP or any other health assessment tool will clearly give you all this information.  At my office we have developed our own health assessment tool to answer all the farm questions and to touch over 100 different areas in the farm.  I have included the areas in my post, What should I Check With a Health Assessment? and would love any feedback you have on the points and questions.  With your help I can make it the most complete health assessment list available.

Once we completed we can move on to the Site Collection Administrator questions.  Site Collection Administrators have less knowledge of the configuration, but provide a direct point of contact with your key stake holders.

Site Collection Administrators

Based on question 5 above, you should have an idea on which Site Collection Administrators are needed for this portion of the questions.  In smaller organizations, the Site Collection Administrators may be the Farm Administrators, you should be able to figure that out quickly when beginning the engagement.  The Site Collection are a SharePoint solutions first line of direct contact and problem solving in the business, they are the most likely to know what the users want changed and what issues are recurring the most from a User Experience perspective.

  1. Do you have anything that maps out your daily routine? This serves a different purpose than with Farm Administrators, here you are looking for what is taking up most of their day.  If they don't have it mapped out, you should sit down with them and ask what a typical day would look like.  They may have trouble providing it, so another approach is to ask them to do some logging activities for a couple days, recording what they are working on.  You can then review it and confirm if the tasks are typical or not.
  2. Do you have any requests from your business users you have not been able to fulfill?  If yes, what has prevented you from fulfilling them?  This will often identify issues with configuration, policy or knowledge level, use it as a sounding board to ensure the architecture meets the business needs.
  3. Are there any issues that keep recurring or that never really go away?  This provides insight into pain areas where they may have a work around or an area where they have decided to perform something a specific way and it is not working.  This is another area we will have additional conversations about how they think it should be.
  4. If you could change anything about the solution what would you change?  Site Collection Administrators often have good feedback on improvements specific to user experience and functionality, make note of the changes, then identify them as future state requests for remediation and road mapping.
Remember these are really meant to draw out the pain points and issues with the environment.  You may hear the same answer from many different people, that should raise the importance of the issue.  Some of the answers may be symptoms of a deeper problem, it will be your job to determine that before attempting to remediate it.

Service Desk Manager

The Service Desk Manager can provide you tangible numbers on where issues are occurring, open tickets and typical complaints that users have made about the system.  They are the support of what has been discussed with the farm and site collection administrators and will provide additional insight and numbers behind the importance of certain issues that have been identified.

  1. Can you provide a report of ticket opened for SharePoint in the last 6 months?  This should provide ticket count, time to close and total percentage of tickets for each category.
  2. What are the main complaints your team hears in regards to SharePoint?  The Service Desk is the first line for support, so they hear most of what the users like and dislike about the solution.
  3. What would you change about SharePoint if you could?  This is an open ended question and should elicit conversation on improvements and pain that they feel from their environment.
Remember the questions above are a starting point, you want to draw out their pain experience.  In some cases it might be better to talk directly to the business units, but always remember these are about insight into issues about the environment.

Health Assessment

As mentioned above the Health Assessment portion is usually done through a tool that compiles all the information about the environment.  I analyzes your solution and provides feedback on all areas that need to be considered.  Please refer to What should I Check With a Health Assessment? for actual check points and complete it in whatever manner you wish.


Report and Remediation
From the interviews and health assessment a report of gaps and issues with the design can be created and presented to organizational decision makers.  From the report you will also be able to identify the criticality and with discussion, the priority of the issues involved.  Use this information to build a remediation plan, that includes the issue, it's criticality, priority solution to the issue and the effort needed to resolve the issue, then sit down with the decision makers and work out the remediation plan to resolve the issues.  The plan should provide a timeline for each resolution and the resource allocation needed to resolve it.


Next Part
In the next part of this series, we will look at other parts of your operational governance and what it takes to ensure your environment has the operational governance it needs.  Feel free to read my other posts and follow me on Twitter: @DavidRMcMillan and @DevfactoPortals.