I've seen it time and time again - a given company needs some sort of easy, content management solution, they buy into SharePoint thinking it will solve all their wildest dreams, and it only brings misery and frustration. Why? What is wrong with SharePoint? Is it the product itself, or is it the idea of a pre-built CMS?
Well, the core problem with SharePoint (and similar products) is that it ignores a fundamental truth in software development: End users don’t really know what they want. They may think they want content management. And, if that were true, SharePoint might be a decent (albeit unnecessarily expensive) option. But typically, end users don’t just want content management. They actually want content management, pretty bells and whistles, the ability to print counterfeit money and the ability to order pizza with their car horns. Problem is, they don’t typically realize that until after they’ve run their credit card. Suddenly, they need SharePoint to do things that aren’t as simple as clicking a few links in the UI, they don’t have the time or expertise to figure it out for themselves, and that’s when they dump their implementation off on their IT team to figure it out.
Well, the core problem with SharePoint (and similar products) is that it ignores a fundamental truth in software development: End users don’t really know what they want. They may think they want content management. And, if that were true, SharePoint might be a decent (albeit unnecessarily expensive) option. But typically, end users don’t just want content management. They actually want content management, pretty bells and whistles, the ability to print counterfeit money and the ability to order pizza with their car horns. Problem is, they don’t typically realize that until after they’ve run their credit card. Suddenly, they need SharePoint to do things that aren’t as simple as clicking a few links in the UI, they don’t have the time or expertise to figure it out for themselves, and that’s when they dump their implementation off on their IT team to figure it out.
Your IT team may have a developer. But, he’s not a SharePoint developer. How do I know? Because “SharePoint Development” is a fairly niche skillset. It isn’t like jumping from Java to C# where concepts are relatively similar. It’s not like grabbing your SQL Server Admin and getting him to look at your MySQL solution. SharePoint development requires an in-depth knowledge of how all the different parts and pieces interact with each other. It’s extremely temperamental, and a good deal of massaging is required to get it to cooperate. Simple tasks like preforming site collection backups or implementing custom web parts are an incredible pain in the ass. They rely on everything existing in an ideal state (from database options to Windows updates to minor variations in SharePoint builds). If you’re like the bulk of business owners who buy into SharePoint because Microsoft told you it was an “easy solution to content management,” then you probably didn’t know that. And, if your IT department doesn’t know that now, they will soon find out.
Your developers are going to become extremely frustrated because, not only are they dealing with the typical aggravation and frustration that comes along with software development, they’re doing it while struggling with the SharePoint framework itself. They’re fighting with the environment, the server, user permissions, features… All the while, they’re cursing you under their breath because they know that your requirements would be much more manageable had you come to them in the first place for a custom application. It's a lot like asking a contractor to build a garage, then handing him a pile of Legos with which to build it. This is where Microsoft has completely failed. The very existence of SharePoint rests on a marketing strategy that intentionally takes core fundamentals of the Software Development Life Cycle and tosses them out the window. SharePoint is made for the sole purpose of making your boss think he can implement a complex solution with minimal investment in IT. The requirements gathering stage is where your development team determines what you need an application to do. If you need to order pizza with your car horn and SharePoint can’t do that, THIS is the point where your development team will drag that out of you, stand up and inform you that you should probably seek options that don’t involve SharePoint. Microsoft’s marketing strategy for SharePoint is specifically designed to skip this crucial step. It’s designed to sell you a lemon, then when you drive it off the lot, it’s your mechanic’s problem.
So, you bought SharePoint as a round hole for your round peg, you realized your peg is actually square, and the hole you bought is in a mold of Jell-O. You passed it along to your IT team, but they can’t do anything with it unless you pull them off of their current projects and send them to special training classes to learn all of SharePoint’s little bullshit nuances. What do you do?
Enter the SharePoint Developer. This guy makes a living by going into organizations who have bought into the SharePoint lie to fix their implementations. Oh, and by the way, this is a full-time developer who you’re probably going to pay around 150% what you’re paying your in-house developer. You know, the one who could have built this application himself using a reasonable solution had you just consulted with him beforehand… seeing as how that’s his job and all?
SharePoint Developers make a lot of money because they’ve pretty much relegated themselves to SharePoint development – a fairly lucrative skillset that your current developers haven’t bought into because they’re real developers who know that SharePoint’s existence pretty much relies on the ignorance of business owners who don’t know what they’re doing, but bought into the flavor of the week.
Now, your SharePoint guy is gonna get the job by telling you the sky is the limit and that he can accomplish anything. Once he’s in the door, he’s going to accomplish half of your tasks, and then tell you the other half of your tasks are impossible with SharePoint. When you question his expertise and/or call out SharePoint’s limited capacity, he’s going to get defensive and put the blame on you because you bought a solution to accomplish tasks that are outside of its scope and that your implementation sucks, not SharePoint.
Get used to that line. It's part of a pretty convenient little web of bullshit that the SharePoint community has woven. They tell people “it can do anything,” then when you get into it and find out you can’t accomplish tasks that you would think should be fairly easy, they blame it on “your implementation” or “your expectations.” To them, it's never SharePoint's fault. It's your fault. It's your systems' fault. It's your IT teams' fault. It's George Bush's fault. It's everyone else's fault but SharePoint's. This doesn't make sense for several reasons; but if nothing else, you bought a pre-built, cookie cutter solution to accomplish a specific task a specific way. Does it NOT make sense that some things just won't be possible? How/Why the hell did Microsoft convince you that "you can do anything?"
The very first step of software development is requirements gathering and analysis. This step is crucial for obvious reasons, but most important because it gives developers the opportunity to remind end users of particular restrictions and potential requirements they haven’t thought of. This is where the feasibility of requirements is studied and analyzed. This is where a GOOD development team brings you back down to earth. If SharePoint is not a viable solution, THIS is where that needs to be determined. You NEED an experienced developer present to analyze your requirements and give you the best options for your needs. A promotional video from Microsoft is NOT a good alternative to this step. It simply is not. It’s not your fault for not knowing what SharePoint can’t do. But, it is your fault for not actually consulting with someone in your company (someone you pay to have your best interests in mind) to find out what your options are.
Implementing SharePoint and then passing it off on your IT team is like inviting a reformed sex offender to live with you and then expecting your kids to play nice with him. It is a curse upon your house. In theory, SharePoint is a great solution. It provides a reasonable means to achieve strategic content management... as long as you stay within the SharePoint box. In practice, it becomes overly complicated and clunky, and by the time you've decided to take it out behind the barn to shoot it, you're in over your head. You've invested way too much money and manpower, and it's now an integral part of your system.
