Had a chat with a friend in the pub talking technical over a whiskey and rum, and got into a reminiscent of the good ole days of writing databases in DOS (Nantucket Clipper and dBase – remember that?! Wow). I was asked about SharePoint and the coding for that and then someone piped up saying it was an application, and that started a whole new discussion. How do you take SharePoint as an application? Is it one? How does it ‘develop’? Hrm… Time to get theoretical and a blog is brewing…

SharePoint in an organisation is not data independent like an application may be. It is a centralised platform and therefore defined as a core system in an organisational information processing environment. A software application is designed to perform singular or multiple specific tasks to solve problems, like accounting software, office suites, graphics software, media players. Is SharePoint any of those? Nope, it’s a platform that allows users to create manage their own online content which could include output from any of those applications I’ve just mentioned.

Now, SharePoint of course can be made to produce transactions based on sharing and can even be defined to produce workflow like responses and outputs, such as sales, shipment of goods etc.). And because this is ‘created’ from organisational requirements as a part of the way they collaborate and share data, that transactional work in producing documents and records for sales is simply one aspect of the platform. And it is this platform that provides all of this data reporting, statistics and analysis for management and aids the decision making process.

SharePoint grows in an organisation as do all the entities with in (e.g. sites, repositories, workflows, connected databases, forms etc.). Even though these applications are interrelated, not all are developed at the same time. Priorities are set.

As a person embarking on implementing SharePoint there’s no point in saying “YAAAY, install it straight away and deal with the integrations later”. You can guess that is not going to solve any information or management challenges the client has (as I’ve described in my book a great deal J )

So, when you develop your SharePoint project plan, make sure that you follow a Design, Plan, Build and Operate format. Whilst you build on that plan you will be amazed to see how deep your SharePoint implementation has to be. Not only does the implementation need to capture the essence of collaboration in the organisation. The implementation must also serve as an evolutionary step to ensuring SharePoint grows with the organisation and stays integrated with the clients’ vision and applications.

I’ve provided a Project Planning Template designed in Microsoft Project format so you can download that and modify. It is located here:

https://serviceautomation.online/project-plan/

This has been made generic so that you can modify and detail the relevant tasks associated with your implementation of SharePoint, and bears no direct relationship to any implementations I have managed, neither do the resources assigned directly match and I would strongly suggest that you review the plan with the client to ensure their requirements are encapsulated.

Of course, this template works in close conjunction with my book (Managing and Implementing Microsoft SharePoint 2010 Projects) so make sure you get a copy from here:

http://www.microsoft-press.co.uk/scripts/product.asp?ref=189322