Hello,
on Thursday we are facing discussions, what will be the future of Sharepoint development in the company I work. Our department of the company has 200 people – not all would need Sharepoint though. (For the note we have Sharepoint Online (2013).
There are basically two ways:
- Use only the tools provided in web and in sharepoint designer. No code editing, no javascript, no programming. And rely fully on what was built. Everything we can not do with this approach would be moved to programmers department to do it somewhere else in their way.
- For the beginning write and use javascript modifications: for content query, for lists, for design purposes maybe. In the future consider starting to modify aspx code, hire a programmer and modify the Sharepoint to specific needs.
What is your view at this topic? Dont you consider “clicking” possibilities too low? For what purposes do you use Sharepoint in your company? What skills do people have to work with Sharepoint?
The pool would be nice here.
Hi Jan,
Great questions. I’ve been working with SharePoint since 2008. In my organization, I am THE SharePoint person – designer, developer, administrator, end user trainer, etc. A consulting company was hired to install and configure our original SharePoint deployment (before I was hired). We use SharePoint for document storage (wouldn’t really call it “management”… though I’m trying to get users going in that direction). We also use it for automating business processes via forms/workflows (Infopath and SharePoint Designer). Our first 3 forms/workflows were written/developed by the consulting firm that set up our SharePoint farm. Since then, I’ve developed 15 more forms.
We’ve also recently migrated/upgraded to SharePoint 2013. We have no programmers. Everything is done with CSS, minimal JQuery, OOTB web parts, and SharePoint Designer. We’ve purchased a couple of 3rd party products (VisualSp for in-context help and DocRead/DocSurvey to be used for faculty/staff training/policy administration).
From my own experiences, I would say before you look at custom code requiring a programmer, explore the possibilities out of the box options allow you. I know there’s a lot that can be done with DVWP, SPD, and little jQuery; sometimes custom code is needed, but not always. We’re using Sp2013 OnPremise, so your mileage may vary.
When we first started using SharePoint 2007, our users were resistant to “new technology”. Before we moved over to 2013, we did a lot of in-house questioning (focus groups) to share what departments were doing currently with SharePoint, what kind of daily pain points they were experiencing, what they liked and disliked in the current system, etc. What we found is that a lot of pain points revolved around “paper processes” and slow response times with our existing environment. So my focus in the new system has been to increase the stability/mobility of current solutions and systems while rolling out new solutions and providing end user support.
We migrated a small diverse group (diverse across campuses/divisions) to the new environment in January as beta testers. We migrated everyone else in June. I spent most of the months of June and July providing end user training sessions (one-on-one and in classroom trainings) and just cleaning up things that didn’t migrate well. Since the June rollout date, I’ve published 4 new forms/workflows and have 6 solutions (some are custom lists, some are Access databases, and some are forms/workflows) in early development stages.
Prior to taking this position with the college, I was a Computer Information Systems instructor and had developed database solutions (primarily with FileMaker Pro), done desktop publishing and technical writing, and developed multimedia training materials for various softwares.
The official reasons the college gave me when hired for using SharePoint were to “go paperless” and improve communication/cooperation. Our then President honestly believed that all of our paper processes could be converted to “workflow processes” in a year’s time (not hardly). From my experience, no one really knew what was really needed/wanted from SharePoint.
So in planning for the 2013 environment, we looked at actual business needs of the school and this is where the focus has been. More and more of our users are seeing the possibilities that developing business solutions in SharePoint can provide. it’s no longer just our corporate intranet.
Things in the works for us: mandatory training will be “handled” through KnightShare (what we’ve named our SharePoint 2013 implementation…) Users will go to KnightShare to view the documents, videos, links, that they are required to understand for their jobs and through DocRead/DocSurvey verify completion/understanding. Project management pieces for IT and Maintenance – starting small with task lists and timelines, but looking ahead to possible Helpdesk/WorkOrder systems. Room reservation/fleet reservation system for the college as whole. Web Content Management – we plan to use SP2013 as a staging piece for editing and approval of items to go on the college’s website (which currently isn’t a SharePoint site at all).
What skills do I need as one-woman shop: SP Admin, SPD, InfoPath, CSS, jQuery, HTML, soft skills like customer service and writing abilities, ability to gather business requirements, and a desire to learn more everyday.
Hopes this gives you some thoughts of things that can be done.
