UPDATE An interesting time to revisit this question. Is perception still the same now that SharePoint 2010 is beginning to take hold? Certainly implementing 2010 is not without its own challenges, but is business perception one of them?
UPDATE: Our implementation is now kicking into high gear with some high profile projets going live in the coming weeks, so I am quite interested to see if the environment has changed out there.
Original Question
We have an issue within our working environment where the perception of SharePoint is either:
a) The golden bullet, the answer to all our problems.
b) An application which either does or does not solve a specific problem.
c) A frustrating tool which does not deliver their exacting requirements.
Now in my opinion SharePoint (or more specifically in our case Microsoft Office SharePoint Server 2007) is a framework on top of various lower level Microsoft technologies (IIS, ASP.Net, WSS 3.0, .Net Framework, Windows Workflow Foundation amongst others) and as such can be developed to do most anything (given time and resources).
The attitudes that have been formed in my organisation (and others I'm sure) is a combination of the Microsoft Marketing Machine and an organisaton's desire to get the 'golden bullet' in front of as many people as possible wihtout saying 'What for?' or 'Why?' or in some cases even 'How?'
Is this an attitude and perception shared by other SharePoint devs?
In the organization that I work for, it completely depends on the level of technical understanding that a person has. The business staff look at it as an opportunity to take a pre-built platform and slap on some minor changes with relative ease. The reality of it, however, is that for the technical staff, it's a nightmare to work with. The trade offs are often from one extreme to another, meaning that if we do something using the built in functionality, it's relatively easy, but the end user experience is far from satisfying. On the other end of the spectrum, we can usually come up with a better user experience, but at the cost of an extreme amount of intensive labor.
Personally, as an individual on the technical side, I wouldn't recommend SharePoint for any environment because when you factor in the cost of licensing, in addition to the development time to make anything worthwhile (which, in my experience, always takes more time than a custom ASP.NET application) you end up with a ridiculous net loss. Most intranet sites are able to get by with the free version (WSS) with relative ease; however, they typically aren't doing a lot of customization and just use it as a document repository.
For whatever reason, the business staff have a completely warped opinion of the product. They believe that SharePoint ultimately saves them money. I say that this is a warped opinion because every single project that I have ever seen that used SharePoint has far exceeded my estimates for a custom ASP.NET application (both long and short term). In one particular case, I have been involved with a project that would have literally taken one month at the very most (including development time, QA, etc.) in a custom ASP.NET application. The same application in SharePoint, however, has been under development for almost a year. The bottom line is that the project simply did not belong in SharePoint, yet the business staff refused to accept this until they had no choice to.
If you are considering SharePoint for your organization, I would strongly advise you to do your homework, first. Expect a very large learning curve and a lot of frustration. Most of your technical staff will immediately recognize the flaws of the product and point them out with extreme frustration. This is normal in a SharePoint development environment. If, in the end, you're willing to make these sacrifices with little or nothing to gain, SharePoint is the right solution for you.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With