Craig Roth“How many SharePoint personnel will I need given a company of our size?”
This is a common question we get, both in the IT Leaders and IT Practioner’s group. In fact, the ITL folks (Karen Shegda and Mark Gilbert) did some great research in that area that has multipliers for various complexity factors such as whether you’ll use it for portals, have multiple geographies, will be doing custom development, and so forth. ITL clients can find this information in the toolkit “Estimating the IT Staffing Impact of Microsoft SharePoint”.
I’m starting to wonder if turning the approach around may also be useful in some situations. Rather than asking how many admins you need for a given level of complexity, what about asking how much complexity you can provide for a given admin team size? When talking about time, project managers call this approach “time boxing” – for example, given 6 months to get the project done, how far down the feature list will you be able to deliver? Maybe with admins it’s called “people boxing?” (I know that without governance it’s called “ultimate fighting” <rim shot>)
Here’s what it would look like: if you are deploying SharePoint to 12,000 users and have a team of 4 sysadmin-types, you can now design the service and service levels you’ll provide. You can provide social software, but clearly can’t moderate or approve profile entries with that staffing. You can provide a master page and maybe a few templates, but without a developer you won’t be providing consulting support for custom development. And without a library-science type person, you probably won’t have a managed taxonomy or rich metadata definitions. Being clear up front about what your service will and will not offer should make everyone happier.
The reason this approach may be needed so often is that people boxing works well if you don’t know what SharePoint will be used for with much certainty. If you’re not sure whether dozens of teams will start developing web parts or none, or whether business connectivity services will be demanded by your intended audience, it’s hard to figure out how many admins you’ll need. But many SharePoint owners do know how big their team is and can work backwards from there.
Ideally an organization would do a good job of requirements gathering and feeling the pulse of the business to know what their needs are, and have a rollout strategy that doesn’t rely on random serendipity. And in those well planned cases, the first approach (calculating admins given the complexity of the site) will be more useful. But when reality bites and you’re more sure of the staffing than the usage, try defining the service based on the team size rather than the other way around.
Comments Off
Category: Microsoft SharePoint Tags:
