Over the past few months, well years really, it has become evident that SharePoint is viewed very differently in organisations. Some businesses see it another product from Microsoft that they can purchase and install along with their current system and others see it as more strategic platform that can be built upon and give them great business benefit.
SharePoint – The Product
In theory yes SharePoint is a product. It has been built by Microsoft and you have to pay for it. Yes you can simply buy the license, pop the CD in the server and hey presto with a few clicks here and there build a SharePoint Server. It may even function really well and may fix your collaboration or even document management problems. However all you have actually done is install something but not actually built a solution. In most businesses where this approach is adopted, two things tend to happen. Firstly it is not configured correctly and just becomes a glorified extension of the Shared Drives and secondly the business does not see any benefit of the system at all and often it is not adopted. I am not saying this happens for all customers, however based on my own experience this happens in more cases than you think.
SharePoint – The Platform
This is when you get the deeper understanding of SharePoint, that even though it is sold as a product it is actually a platform that needs some tender love and care to work the way you want it to. In businesses where time and effort has been taken to design, develop and deploy the system with all the content types defined and a good taxonomy, it is normally adopted and becomes a business critical system very quickly. Now we know this doesn't always work this way, so how can we make sure it does.
I am not going to talk about this in this post as there are many articles and posts that talk about this topic. However what I want to write is what I think the steps should be for a great implementation.
- Get the Experts in
- Evangelise the Platform within the Business
- Get the business involved
- Set expectations
- Test and Test again
Get the Experts In
This is when you ring me up and say Liam come and help me!! Just kidding, but realistically getting someone in who designs, develops and Deploys SharePoint as their full time job maybe expensive but will accelerate your deployment faster than you may be able to internally. Experts in SharePoint have been there done that, got the T-Shirt etc, they will often know the pitfalls of doing something one way as against the other way. My Advice is get someone in who can assist where possible, this might not mean all the work is done by them but get them in to help you engage the business with yourselves and make sure that no mistakes are made in the initial design stages.
Evangelise the Platform within the Business
When Microsoft develops a new product, part of its life cycle is beta testing in the community, possibly Technology Adoption Program (TAP), Rapid Deployment Program (RDP), Events, Tech-Ed Sessions, Webcasts and lots of Articles. Why do you think Microsoft do this?
Simple it is all about getting feedback and getting people excited about the new technology that has been developed. I remember going to the Vista, Office and Exchange events, and seeing how excited Microsoft were to present about this fantastic product range. This is how we should be within our organisations when deploying SharePoint. I am not saying we should start having all the above as this would be slightly overkill and would cost a fortune. However to get business buy in you need the business to be excited about what you are doing. If SharePoint is being implemented by IT and they have chosen it as the product to use, then by default most users will not like it. This perception has to be changed, yes it maybe an IT decision but make the business believe it is there decision because they can't live without it.
Get the business involved
As with the evangelising, getting the business involved is critical to success. As a SharePoint Consultant, the success of a project is really down to me being able to capture the requirements for a business and then delivering something that they want to use. If the business is never involved then in effect I am almost second guessing the business and saying you want to do it my way!! Sounds like a dictatorship to me. J
As part of the work I do, I am engaged in Design and Scoping sessions where the ratio of Infrastructure work to Business Analysis work is dramatically different. In a normal solution the Architecture and Infrastructure design can be sorted out very quickly, however capturing the business needs for Human Resources let's say could take twice as long. The key here is get them involved in the usability and taxonomy of the system, then you will be successful. Think like a business user.
Question: "I already have 10 systems I need to access for content, why would I then want to access another one?"
Answer: "Because this is the presentation layer to all the systems and also allow for full lifecycle management of documents and content"
Set expectations
This is just as important as capturing the requirements itself. Setting the expectation can make or break a project. Too many times I have seen the system built, demonstrated and then simple comments made like, "you will be able to access a read only view of your SAP timesheet on the system", end up causing the system to fail as the business realises they do not have the enterprise license and cannot use the Business Data Catalog. It sounds funny I know but it is true.
Be realistic, if say you are going to deliver a timesheet system built on SharePoint that will automatically feed into Payroll and Project Server, then move heaven and earth to do so. If you would like this to happen but realistically are going to struggle do not promise it or even mention it in passing as business users will hear something and take it as the gospel. Set the expectation by breaking the delivery into phases, and then by all means publish this to the business to see. On a project I have been working on, this is the approach that has been taken, not only is it broken into Phases that equate to time, but also waves of functionality within each phase. This allows for the project management team or yourselves to manage the deployment in smaller chunks. This will make the deployment more successful and then the business has a road map of when functionality will be issued to them.
Test and Test again
This for me is one of the most important steps. Let's say you have built your system, all has gone well and it is ready for deployment to the business on Monday morning. Monday morning comes along and all is well for the first couple of hours then it falls over, errors in the event log and users being denied access or getting very slow response times. Then you think, if only we had tested the system to the full extent, then we would have found these problems and now how to fix them. On many projects I have seen that testing or stress testing does not even factor into it anywhere. User Acceptance Testing (UAT) seems to always be done but it is normally only a handful of chosen people and not the full complement of users within the business. To ensure that your solution is capable of scaling and that there no bottle necks on your new system, testing needs to be done properly.
These steps are not the exact science to implementing SharePoint; I simply write these as a way of sharing what I have seen and what works well when you decide to implement SharePoint into the business. If you have anything to add, or you disagree with anything, then post a comment here.