Implementing SharePoint

In many regards SharePoint is remarkably straightforward and flexible for developing solutions with; very many applications can be developed by simply selecting appropriate features such as lists and libraries, configuring them using metadata and views and aggregating these within a variety of functional sites within a portal. All this can be done by super-user staff (rather than a technical expert or developer) directly through the browser without the need for a separate development and environmental tools.

However the very breath and flexibility introduces complexity and a depth of knowledge and experience in order to effectively plan and build solutions in an efficient and supportable way. There are many ways to make mistakes and while SharePoint itself is a resilient and forgiving environment, badly built solution will both fail to meet the business needs and disappoint or disenfranchise users.

Finding the right people?

When building sophisticated solutions it is best to start with someone who already has the skills and experience to deliver configured SharePoint applications; ideally they should have some knowledge of the solution that needs to be developed as this both exonerates the availability of the solution and minimises the risk of building it wrong. To this end it is often appropriate to engage a partner or highly experienced contractor, if they have existing experience. In order to ensure the solution is supportable in the long term it is also appropriate for knowledge transfer to the internal team to take place during the development. This way they understand it and can develop it further themselves without resort to 3rd parties.

It is also appropriate to develop the business analyst skills required to assess, triage and specify new solutions internally, as well as be able to provide guidance and support to users. Keeping the partner or contract on hand has value but it makes more sense to have internal skills backed up by external experts.

Making a plan

Of course it’s really important to plan your SharePoint project and specify the application trying to build. However SharePoint projects are not best suited, in my opinion, the pure waterfall project approaches and rigid specifications. Although you can get reasonable clarity on functionality and features required it’s difficult at the outset to define exactly how that will be achieved, or the user experience should be like and how best to mould the feature set to solve the problems or address the needs. SharePoint projects lend themselves to agile processes. There is much to be gained through iterative development with ongoing user input and evolutionary definition of the requirements. The simple reality is that the users really don’t know what they need in detail until I can see it and touch it, at which point they will think of new things that they want, change the things previously stated as requirements and rearrange the things that they see or have prioritised. The trick is to see this is a healthy activity and build it into your development plan. Fortunately SharePoint is largely very forgiving of this kind of development model, however there are still things you need to get right at the outset, such as defining the overall site structure and information architecture and really understanding the combination and quantity of lists and libraries required to store the different types of information and the relationships between them. Don’t be afraid to build a proof of concept and throw it away, but don’t be surprised if your proof of concept tries to involve itself into production environment. Know when to stop.

We also recommend trying very hard indeed to avoid writing any new code. It’s amazing how many business solutions can be solved simply by configuring the capabilities that SharePoint already has or, with a newer versions, by plugging in a SharePoint app or third-party technology. Custom development is fully supported in SharePoint that brings substantial issues around ongoing supportability and upgradability, often with little benefit.