INTRODUCTION
First of all, as part of this article: DOWNLOAD Business Requirements Document Template FOR FREE! We use it all the time to deliver SharePoint projects.
Hi everyone, in this particular opportunity I would like to share with you some of the pitfalls that we may encounter during our Sharepoint engagement. This is a series.
The very first part of this series is called The Catch 22 “Design then plan or plan then design”. A lot of the times I notice that clients want to see what Sharepoint can do first before implementing it fully which is fair enough. But how many times this happens that the “prototype” model suddenly becomes production version?
I give you an example:
One of my clients asked me about the greatness of Sharepoint. I obviously could explain to them. The meeting went about 1-2 hours and the agenda of the meeting was really to just going through Sharepoint features one-by-one, from My Sites, lists, document libraries, versioning, InfoPath, User Profile, etc etc etc.
At the end of the meeting the client came to me and said, “Mate, that looks awesome! I think it can help us a lot. However, before we fully implement it, we have to first find out whether the product can really help the other employees out and make the business more efficient or not. So, why don’t you create a prototype based on the requirements that I gave you, then we can go from there?”.
Well, here I was building the prototype. Several sites and sub-sites have been created with just OOTB look-and-feel, some content types and fields have also been developed. They’re all done through the UI because – let’s face it – it’s only a prototype!
The client then tried it out for few weeks and….. THEY LIKE IT!
I then came back to them and asked them to do a proper scoping and re-build the portal/Intranet (whatever you want to call it) properly. By this time client said to me, “Mate, we cannot lose content because people have been using it and they’ve uploaded documents, etc etc etc. If we have to re-build the portal from scratch and losing the content then we can’t have that.”.
So, in the end I had to work with the prototype and developed it from there which was a mess. Well, since it’s only a prototype to try out functionalities, the site structure wasn’t really thoroughly planned, the UI hasn’t been properly developed, the content types and fields (meta-data) haven’t really been thoroughly thought off, etc etc etc.
After all, the project costs client more money than if it’s rebuilt from scratch.
HOW TO DEAL WITH THE SITUATION
Some of the things I can share/suggest are:
– Keep reminding the client that it’s only a prototype and should not be used for day-to-day business use.
– Tell the client to not to work with the documents that are uploaded to it. They’re all purely for testing out functionalities such as versionins, etc.
– Give them timeframe to test out functionalities, eg. 2 weeks. If the client needs an extension then be it but at least we (the service provider) are being pro-active and following up the client.
– Never let the prototype to creep out and grow itself bigger than Ben Hur. Keep communicating with the client and ask them whether they’ve been more familiar with Sharepoint or not.
In any project, planning should always come first before designing. Therefore, without a proper planning, Sharepoint projects can cost a lot of money. I shouldn’t say that it (SP project) will fail but at least it will cost a lot more money than if it’s properly planned.
