Back in November, I gave a presentation to the New York Smalltalk User Group at which I explained why our need to connect our business applications to SharePoint almost drove us away from Smalltalk. The presentation generated a number of comments and one that I liked was from Richard Sargent:
“I have to admit, I was wondering what the fascination with SharePoint is ‘out there’. The examples I have seen in the last few years are rubbish, nothing but repositories for randomly disorganised junk…if there is anyone using it for anything different than a document dump and a web-based spread sheet, I’d like to know!”
Of course, I pointed out we are using SharePoint for more than that, and that our site isn’t rubbish. A few emails later he selected one of my earlier comments and sent it back to me. I said: “We work hard to define the requirements” and I could almost sense a little smugness when he replied: “I think that is what sets your SharePoint sites apart from the garbage I have encountered… It’s funny how that works, eh?”
Systems developers know how important requirements are and we all tend to feel a chill when we hear the words “end-user development.” SharePoint isn’t the first end-user development environment I’ve encountered, I think that was dBase III, and what always scares me is the implication that ‘anybody can do this’. I want to add a disclaimer like Adam and Jamie on MythBusters – “Don’t try this at home”. If you are going to avoid rubbish, you have two choices: 1) Train your end-users, or 2) Don’t give them anything more than Contribute permission.
Train Your End-Users – That sounds simple enough, but it’s more than teaching them where to find the Create menu. You have to make sure your users understand the various platform components: Sites, Libraries, Lists, etc. and their various incarnations. They need to know the difference between a Document Library, a Document Center and a Publishing Site. They need to know how to add Custom Columns to a library or a list and they need to know when and why they need to add them. They need to know what the company vision is for ECM and SharePoint and how to map their requirements into that vision. It follows that you need to have a company plan for SharePoint in which you establish that vision.
Lock Them at Contribute – This approach may make you feel better but it isn’t going to work unless you are prepared to build everything your users need. People know what SharePoint can do and they want those options to be made available. If you don’t let them build their own sites, and you don’t build those sites for them, you are going to watch SharePoint fail, or worse, spawn home grown solutions either on workgroup servers or in the cloud, or much worse, more rubbish in file shares.
We have opted to chart a course in between these two extremes, albeit we are closer to the “contribute” shoreline. We respond quickly to user requests for SharePoint resources, either on our internal or our Internet facing farm. But, as I mentioned in a series called Timeless Lessons, responding quickly doesn’t mean building sites quickly. We take the time to understand the users’ requirements and to satisfy those requirements. At the same time, we invest heavily in training. We have an in-house training program featuring a new topic every month. Some of those topics are SharePoint specific but all of them address any SharePoint implications. For example, if we are teaching a class on PowerPoint, we include a few minutes on our SharePoint Slide Library. Since we use SharePoint for ECM, we conduct ECM training too. We have examples of end-users who design their own sites, customize their sites and we’ve had a few successful end-user constructed sites. But, in each case we have been close by, like the Fire Department during a taping of Myth Busters.