Most people in IT, especially the Microsoft oriented side of it, know the potential of SharePoint.  It’s clear that this product is on the rise and demand for it from customers is at an all-time high and rising.  One of the reasons is what I described in an earlier post, the fact that almost anybody can use it without too much trouble.  This includes business people or even customers.  This is also the number one pitfall of SharePoint.  Because it’s so easy to use and has so much features out-of-the-box, in many cases it’s treated as a plug-and-play application.  You have IT install it and then release it too the crowd who can “play” with it as much as they want.  Wrong … except if you like chaos.

So what can you do to prevent this?  How can you make sure that you’re SharePoint site(s) don’t tumble into complete chaos?  The answer is quite simple.  But because the base set-up of SharePoint architectures is mainly done by IT pros, one not everybody might be too happy with.  The answer is you treat the installation and set-up like if it was a development project. 

What happens today, is that business people or management decides they want SharePoint, because it will enable them to share documents, have version control, have workflows on documents etc.  STOP, REWIND! First of all, what they “want” is the solution to a problem, not a problem itself.  Now I know that sometimes the customer is king, so SharePoint will be chosen anyway.  Fine, but even then you shouldn’t just start installing and creating sites.  You should do … wait for it … functional analysis on the problem.  Find out what problem they want to solve with SharePoint.  It sounds easier than it is.  This is not something anybody should attempt.  Developers and IT pros will always start thinking in technical solutions and therefore might not be the best people to do this.  Try using an actual functional analyst to do this job. 

Of course, my opinion it a bit biased, since I am a functional analyst, but indulge me just a second longer.  Once a functional analyst has gathered the functional requirements, the discussions, brainstorming and eventually the technical design can be started.  The big advantage is that you have a smaller group of people in the discussion.  You’ll have the functional analyst, and technical architect, one or two IT pros and some developers (if custom work is necessary).  The end result of these discussions and meetings should be a well structured technical design and SharePoint architecture that accomplishes three things:

1)      Cater to all the functional needs

2)      Provide one solution that is consistent in look and feel

3)      Minimizes the need for people to “play” with SharePoint to get what they want

Design and document the architecture before installation, create site templates for the different groups of people that will use the SharePoint environment or types of sites you need to have and above all provide a security model that is transparent to the users.  If you can accomplish this, you can release a something to your business people or customers that will no longer be just a SharePoint site, but a complete business application.

So please give it a try.  Include a functional analyst and maybe even an entire project team to set up your SharePoint.  The result will be a site or portal that not only tailors to the needs of business or management now, but will have the ability to grow without resulting in chaos.

Oh, and if your business people really want to “play” with SharePoint and test the most ridiculous color schemes in site … that’s what “MySite” is for ;-)

By Ronny Gabriels, Functional Analyst and ex-.net Solution Architect