I have a customer who has third party developers enhancing their SharePoint platform; their questions surrounded the control of these developers from the perspective of how their products end up running in SharePoint. We all know that SharePoint is pretty ‘laissez-faire’ about any products on the servers it runs, whether they be SharePoint workflows, Visio workflows, Site Features, Automation and the list continues. SharePoint doesn’t care whether you have details about how the product is supported or managed. So, as a SharePoint manager, you will understand that SharePoint infrastructure requires protection of its integrity; particularly since there are levels of SharePoint applied (i.e. Production, Pre-Production and Disaster Recovery platforms are usually kept in sync). Not doing this or at least being proactive results in an uncontrolled, and chaotic environment where no-one really has a handle on what is installed, who did it, and why – worst case scenarios include not being able to even find the original developer who created the product now running on your company-wide SharePoint implementation.

So, this means that it’s very important that these environments have adequate change controls in place to ensure that any third party applications developed can be supported by internal SharePoint staff.

You will need to be happy that the product says what it does and has been tested and this shows in the documentation; critical before the product ends up in your SharePoint Production land.

As as rule, you should ensure that all products that are not defined as ‘out of the box’ SharePoint that has been developed, and whose intention is to be deployed to Production should have the very least clear and unambiguous documentation to support it. Best thing to do if you have not already done this is to get a list of anything that is not out of the box, verify and validate its existence. Try to get a handle on exactly how much information you have about the product – it will make you more comfortable about the state of the platform and prepares you later for any migration issues when they occur (and they will).

So what should developer documentation for SharePoint entail?

1. A full statement of what the product does and its scope.
2. A full step by step installation guide including prerequisites (what needs to take place post install), where the product is to be installed, who is expected to do the install (what kind of permissions).
3. A full testing guide that indicates what needs to be done to validate and verify the product has been installed as in (2) above.
4. A troubleshooting section that details any issues that may come about and what to do if the product does not work as intended, including contact numbers and names of anyone who needs to be contacted if there is a problem.
5. Lists of the product (what are the titles and location of any MSIs, WSPs, and any other product used to aid the installation).
6. Lists of any contact information for the Developers

This all sounds obvious when you read it, but it is an area which is overlooked because the customer onus on getting something on SharePoint does not always engage on making sure there is support after the product has been deployed.