SharePoint provisioning - code name "Steph"
Blowing the budget for something simple
A common trend with adoption of SharePoint online is to get confused about the lack of useful business centric advice and starters.
Partners are making great in roads into enabling customers to use the services, but when it comes to SharePoint online and OneDrive for business they appear to be as confused (or guilty) as the customer.
Why? What's the challenge?
The issue for all users of SPO, is there are no useful business patterns or templates which provide value. So we make them.
Then users use them, ask for refinement or improving the tools and its immediately Development exercise.
So what happens with the new templates? How do manage the deployment and updating of them?
Well the common misconception is, we need a provisioning engine! Makes sense - ish. Where is the tool that deploys your business templates - particularly if you. When everybody was on premises, the developers role in et voila! 12 months and $1m later we have an engine, which captures the request and deploys a template…
Hmmmm, wrong.
Using a cloud service is like using electricity, you go and buy pre-packaged tool (e.g. A kettle), plug it in and make tea. You don't immediately rush out, employ miners, designer, and build a smelting plant and manufacturing factory to build a kettle from first principles (by digging out ore and smelting iron, then processing and pressing it to a kettle template)
Unless you are Phillips or Brebantia there is no need. We just want one kettle, but lots of cups of tea over time. Buy the kettle, and train your teenager to boil the water and make tea. (I'm English, this analogy is going to run...)
Wrenching the analogy back to SharePoint land, hiring a team of developers to write a provisioning engine to deploy your required site templates is exactly the same thing. Except most people have not realised that SharePoint IS A PROVISIONING ENGINE.
We just need to press the process pattern for our different business needs into templates, then train our admin or users to select the flavour of site / function they need. (Darjeeling or Earl Grey...)
So do we need the whole manufacturing chain for our business to use SPO to get business use? No, we need the retail shop which provides the range of electrical appliances we need.
What about the repetitive task of creating the sites, recording who wanted it? (what flavour, which size mug etc?) Surely we have we need extra tools for that!
Sure, but what you have described now is not the engine, but the register and reporting for a job. You can do that easily using far simpler tools e.g. a List register.
You see the problem is a non-problem, for most companies. How many sites do you actually need to deploy? How often do you have to service that business request?
At the extreme end a large multinational professional services company I know (their output is delivering projects and IP for clients) want to run everything using SPO. They successfully run up to 11,000 projects a year globally. This means that they produce cups of tea (sites) on an industrial scale!
Let's do the math
Sites
So 11,000 sites per year is...
· 230 sites / wk, or
· 45 sites created per working day
Average time to full in form for a site (6 fields, 3 check boxes): 3.45 minutes
· Time to fill-in and process 45 sites per day - 2.63 hrs
Cost of building a new site template
This is the same regardless of how you deploy it - therefore I am not factoring this into the ROI model here
Which provisioning engine
SP is a provisioning engine.
Putting aside creating, naming and sorting the template, effort to fulfil a request is still the same as above.
Person-based (Codename: Steph)
This reviews the equivalent action delivered by a self-service UI form on a list and corrective action by helpdesk person e.g. Steph
· Time to navigate to 'add site' option, search gallery for your template and fill in the deployment page - 2 minutes, (including screen refresh)
· +90 min per day processing time for the sites creating
This is not a cost as its the machinery of SPO engine configuring stuff in databases
this is the same regardless of you approach
Custom built site provisioning engine
So let's be conservative and assume that using competent SP developer we create, test and deploy our new uber engine, and that takes only:
· 9 months effort
· cost of $350k
Supplemental time incurred but not costed in the equation
· +90 min per day processing time for sites to create
· +1min / site (45 min) - custom reporting logging (assumption is included
Therefore cost for new site equates to an additional $31/project over a year, or $648/day
NOTE: We still have document and run the process - regardless of which "provisioning engine" I use to drive process
Balance of benefits vs. cost
Person $ rate
Assumption: we have gone for an experience, and capable support / admin person - not a SharePoint expert
· Cost for help desk person $90,000/annum
($46/hr unadjusted. $67/hr adjusted)
· 3.5hrs per day to process requests
Being generous and accounting for lost time
· $67*3.5= $234.5/day
($164 / day unadjusted)
this effort does not change regardless of the use of engine to deploy a site.
Custom-engine equivalency test:
For the cost of 3.9 operations staff, I'm doing approx 2 minutes less activity per project site provisioned....
AND I now I have to maintain a custom development code base over the life of its use in our business (staff, testing and regular remediation because I'm on a cloud service which can change underneath me at months notice)
For everyone else
Looking at what the implications are for the vast majority of use? Well based on a mid-sized organisation (New Zealand mid-sized, Global small) and assuming we have a number of common business sites for internal functions i.e. workspaces for:
· Intranet home-page (comms channel),
· Dept team areas (ICT, FIN, LEGAL, SALES, MKTING, BUS SVC, HR, BOARD/EXEC),
· Controlled/Quality docs area and a
· Public community area.
..we have upto 13 core solution sites, plus business specific solution areas and / or projects.
Will you change these much once they are setup? I would argue no. Maybe add/extend or replace every 3+ years.
So just how many extra solutions (which need new sites or templates) do you need that you will create 45+ sites per day? (as per my example above)
For a busy organisation maybe 100 - 300 a year, if you push it.
Conclusion
Personally I just cannot see a justification for the short-mid term TCO for undertaking this approach
There are so few scenarios which will show even a modest return-on-investment that I do not see this being a successful path for most organisations.
Summary
There are good reasons that may justify investing in a creating custom solutions, and building extensions to the SharePoint Online model for Site provisioning. I know of a couple - they are extremely involved and constitute a competitive advantage - for a Cloud service provider, a Systems Integrator/Hoster and a software solutions company.
For nearly everyone else out there I would suggest some basic documented processes, a little training for internal staff and WELL COMMENTED form/list UI will provide the same outcome at less than 10th the cost.
The lessons in this story are 2 fold:
1. Cloud service solutions are not the same as on-premises. You should learn the capabilities and the boundaries, before you undertake any customisation or development
2. Treat O365, SharePoint online and other Cloud service applications like electricity to your house
don’t ask your supplier to change the pinage on your sockets, and don’t build your own kettle
The moral of the story:
Just because you can do something, doesn’t mean you should.
Understand your problem, and do a basic cost/benefit review before proceeding.