Prototyping in SharePoint

Organizations can have many reasons to implement SharePoint; centralized document management, the need for an intranet, file sharing between disconnected organizations or automated forms and workflows for business process improvement, just to name a few. The fact that SharePoint can cater to all these needs out of the box gives an indication of the versatility, flexibility and complexity of the tool. The possibility for endless customization through custom web parts and custom code development only extends that.

But all this versatility, flexibility and complexity makes SharePoint a hard tool to implement right. To make sure you get it right you should try to keep it as simple as possible. Customization possibilities are endless but the more customized the functionality gets, the harder the SharePoint sites are to maintain, govern and eventually upgrade. And the SharePoint out of the box feature set is very rich so it should work for 75-80% of your needs. It’s just a matter of configuring all the out of the box features you need, right?

Before you get going you’ll need to know what the goal of the SharePoint implementation is and the high level requirements are. While the goal will probably be quite clear, for example “we want to manage all our documents in one location” or “we want to enable and encourage collaboration”, the requirements may be a lot fuzzier. The stakeholders in your organization could have trouble articulating requirements because it can be hard to envision what the solution will look like in SharePoint especially when your organization is new to it. At this point in time you need to get two things clear at a high level:

• Who will be using the solution
• What do they need to be able to do on the solution

In a typical software development process you would now probably have Business Analysts do a deep dive to find the detailed requirements for the solution. But because the components of SharePoint are highly configurable, it will be more productive to build a working prototype at this time.

A SharePoint prototype should only contain out of the box functionality (so anything you can do in the regular SharePoint interface), no branding (except for maybe a background color and logo change) and very little data and/or documents (just enough for demonstration purposes). Unless security and/or localization are important requirements, not too much effort should be put into defining roles and audiences. But the prototype will be fully functional so stakeholders and users will be able to play with it and get a feel for where the solution is heading and provide their feedback. If it is hard to get clarity of high level requirements and there could be multiple solutions, it may even be advisable to build more than one prototype so that the stakeholders can decide which route they like best.

When the prototype has been commented upon and approved you can start work on developing the final solution knowing that the end result will fit the needs of the organization and will not come as a surprise to the users.

How to preserve Digital Signatures when moving documents between libraries

I recently came across a situation where a customer has a large document library with policies and procedures that have all been through a review process and in which most of the documents have been digitally signed by members of the executive team. The site where this library lives was the first attempt at capturing these and other documents but it was found that it didn't meet the customers needs.

So we're developing a new site based on the customer's requirements but when I started looking at migrating the documents to the new site and library I found that digitally signed Office documents loose that signature in their new location when you move or copy them (regardless whether you use OOTB SharePoint functions to do this or a third party tool like CopyMove). After this move, the documents do indicate that they used to be signed and by who. So the published location is considered a part of the signature for non-repudiation purposes. As these policy documents need to be strictly controlled for compliance reasons, this presented a challenge.

The workaround I found was surprisingly easy. It turns out that when you download a copy of a digitally signed Office document from a SharePoint document library, the digital signature(s) are retained in the document. And the same goes for copying the file(s) from the Explorer view of the library to a local drive. Which is very handy if you have lots of digitally signed documents to move.

And when you then load these digitally signed documents up to the new document library, they still retain the digital signatures.

There is however a big drawback to this approach. If your document(s) had metadata and/or approval statuses in the original library and you want to retain this information when moving it to the new library, this approach will not work as metadata is only retained if you move documents within SharePoint between libraries with identical columns.

So it's a choice between getting all documents signed again or resetting the metadata and approvals. In this case I decided with the client to retain the Digital Signatures and use this product to do batch check-in and metadata updates for the files we'll upload to the new library.

Going from the shared drive to SharePoint

For the longest time, shared drives were the way that enterprises preferred to store and share documents. The down side of using shared drives is that there is no version control for documents, no search beyond the filenames, and the folder structures get convoluted over time, making it very hard for users to find and work with the right documents. Using SharePoint for your document management can resolve all of these challenges.

As Documents Management comes out of the box with SharePoint, many organizations that implement SharePoint for the first time don't put too much thought into setting up their document libraries. They will often focus on the look and feel, the colors, put in the company logo, setup a few libraries, maybe add some metadata columns and open it up to their employees. But what they often find is that the acceptance of SharePoint is very low. This could be because:

• The shared drives are still available
• There is no clear ownerships and/or governance of document libraries so users keep creating new folders to store documents that really belong in a different spot
• The document library and folder structure is/grows just as convoluted as the structure of the shared drive was but with a different structure (and SharePoint doesn't show the tree view as in Windows Explorer) so users have even more trouble finding documents
• SharePoint Search isn't setup properly

To avoid these pitfalls and enhance acceptance of SharePoint as a document management system you should take the following steps when implementing document libraries in SharePoint to replace the shared drives:

• Setup a clear library structure with a limited set of relevant metadata tags
• Define clear governance of the libraries and makes sure only a limited number of users can create folders
• For large libraries, use one or two levels of grouping to get a better overview
• Make sure that search works properly. When it does, users will even be able to search in the content of all documents in the libraries
• Train users on how to use the libraries, use sorting, filtering, checking documents in and out and using search to make sure they understand the advantages of using document libraries over the shared drives
• Migrate all data out of the shared drives and close them for good

SharePoint offers more functionality and possibilities then just document libraries. But when replacing your shared drives is your first objective, you'll need user acceptance on this step in order to successfully move forward on your next SharePoint projects.