Need a little help: What is a SharePoint End User?
From Mark Miller
Founder and Editor
EndUserSharePoint.com
Joel Oleson and I were talking after our broadcast this week about how to define a SharePoint End User. The problem we are coming up against is “End User” doesn’t seem to be a broad enough term for what we are trying to describe.
We’re looking for a new term.
At EndUserSharePoint.com, we think of SharePoint End Users at three levels when writing articles: Information Worker, Power User and Site Collection Administrator. Let’s open up the discussion and see if the descriptions cover all aspects of the End User Community and then try to agree on a term that encompasses them all.
SharePoint Information Worker
I envision the Information Worker who uses SharePoint as someone who, in the process of their day to day work, must use it to manage their information. This might be something as simple as contributing or using information in a Document Library, or as complex as using a customized SharePoint list for managing data that has typically been stored in an Excel spreadsheet.
An Information Worker is not concerned with SharePoint, they are concerned with getting their work done. Any talk about “web parts”, or “create a view”, or “collaboration environment” is met with a little wave of the backhand and a comment of “Please come back when you are speaking English.”
Information Workers don’t care how it all works, they want to know why they should change their existing work habits to accommodate this new way to store their files.
Power User / Site Administrator
Typically what I have seen in large companies implementing SharePoint is that people are “volunteered” to be Site Administrators. These are usually the people who have an immediate need for some functionality in SharePoint and choose to start working with it on their own. When the company sees this type of self-motivated initiative, the person is promoted to Site Administrator: all the responsibility and no authority!
The Site Admin becomes hellbent on grasping as much knowledge as they can through reading, user groups, online forums, workshops, web sites… any content they can use at the moment. During that process of learning, they become more and more proficient at SharePoint.
When you think about it, that paradigm is upsidedown: you’d think someone would be a Power User before they become a Site Administrator!
Site Adminstrators are the first line of support for Information Workers. The problem? In a large company, many people will not know who the Site Adminstrator is. Even if you’ve agreed to take on the responsibility of a site(s), how will people know? I’m off on a little tangent here that is deserving of a seperate article, but it all comes full circle: who is responsible for what?
Site Collection Administrator
Site Collection Managers are an odd group. In order for sites to be created in SharePoint, there needs to be a site collection to store them and people to manage the site collection. Where do these people come from?
From my experience, having taught hundreds of SharePoint workshops, Site Collection Managers come from the same pool as Site Managers. Sure, there are exceptions, but in general people will choose to accept the title because they need a site within the site collection, not because they want to be a Site Collection Administrator.
The strain on this position is tremendous. Where are the resources for learning Information Architecture? How much authority do they have once they have designed a structure? Who is setting the governance policies and how are they being enforced? Once again, there is a ton of responsibility, but very little in regards to authority or enforcement.
Conclusion
Titles are useful for helping mentally group ideas under a single heading. As stated above, the three groups described do not have access to the SharePoint server, can not deploy features or workspaces and are limited to out-of-the-box solutions when using SharePoint.
This gives you a brief overview of how I mentally break out SharePoint End Users and the roll they play in any SharePoint implementation. When I develop workshop material, if I can design for these types of groups, I can pretty much hit the entire audience.
Is there a descriptive title for all three? Is SharePoint End User enough of a title to get by? If I were to create a three day conference for this group of SharePoint users, what would the conference be called?
Seriously, I need your input, flames, agreements, comments… all accepted below.
Thanks,
Mark
Mark Miller, Founder and Editor
EndUserSharePoint.com
on
Don’t forget the Lead Architect… I see this as a position more inline with the business rather than IT.
SharePoint Lead Architect:
Responsible for translating business needs addressed by the Strategy Team into initiatives for SharePoint solutions, coordinating & approving Administrator efforts and overall SharePoint vision.
Responsible for approving global SharePoint Solutions and SharePoint Services configuration, policies, procedures.
•Gather initial business requirements w/BA’s
•Seek out new opportunities within LOB’s to provide value using the SharePoint platform.
•Design the initial architecture for successful development
•Provide architectural guidance to development
•Lead consulting team for initial release
•Manage project risks, and escalate incidents to the team as necessary
•Work with the Infrastructure Team to develop infrastructure and operation best practices
•Work with System Administrators to develop best practices
•Works with SharePoint Administrators as Advisors
•Coordinates with SharePoint Governance Board
Mark,
I very much like your definitions and levels of each. With that;
I believe the lowest level will contribute but never modify a list or view etc. for fear of not knowing what they’re doing. That’s most of my user community. SPD is out of the question but no risk as they’ll never open it.
Your correct that site administrator seems to beget power user. That’s how the world is working. I have a couple of those. I’d submit this level of person is willing to tinker w/ lists and views etc. Yet posting stuff into a content editor web part, or using any of Paul’s jQuery objects is still a bit of stretch for these folks. They want it, they’re not confident nor do they have time to learn what that stuff is. SPD is questionable and worthy of debate. These folks might open it, get hooked on workflows etc. but probably still won’t break anything for fear of doing so.
Site Collection Administrators as you’ve defined them are quite the conundrum. Lot’s of enthusiasm or responsibility from the business. May or may not have any IT experience. I suspect that in smaller organizations these are the folks w/ server side access too. That’s true in my organization. That is my IT admins are doing this role too. I allow these folks to add WSP and features, but NEVER modify the webconfig or MS default style pages. SPD in these hands is either quite the great tool, or a disaster waiting to happen. Probably depends on if organization has a dedicated IT dev staff or not. I don’t so the Site Collection / Server admins have it.
Was that any help to the discussion?
Kevin
Mark,
I like your definitions. Here’s my name suggestion.
How about plain “SharePoint User”? I know, it’s not snazzy and cool, but in my opinion those are all of the above. They’re not just end users but everyone between administrator and reader.
Manny
In my experience I’ve definitely seen two levels of end users. 1) is there for the minimum and not very interested 2) wants to explore and try the features out. I like Manny’s comment … maybe “SharePoint User” for the basic grab & go audience? The other … maybe “SharePoint Power User”? It doesn’t map directly to a product security level as that needs to vary by resource.
Thanks for keeping up the thought provoking posts and tweets, always fun to read.
- Jeff
Mark,
We have our DOD hospital staff ‘trained’ to call anyone that is involved with SharePoint to use the following terms:
1. SharePoint/Web Administrator – System Admin/Over all dude.
2. Content Managers – Site manager from the department/section (43), able to build sites, permissions help me to give classes.
3. Enduser – ‘worker bee’ just wants to be able to get their work done. The hospital staff total is around 4,000, (Job security).
How about Sharepoint Coordinator, or a Sharepoint Collaboration Engineer, and/or maybe Sharepoint Project Leader. Someone more than the end user but just below the Site Collection level. I think I would attend a Sharepoint Coordinators Conference.
I like your three definitions, very much spot on. And I’ve always like the EndUserSharepoint title, but have also thought that the content here was more Administrator level. Most of my Sharepoint experience came with all three roles and the only person who held them. Small company, small farm, really didn’t use Sharepoint to it’s potential. I’ve just recently moved to a very large organization with lots of sites both Enterprise 2007 and WSS 3.0.
The first level, Information Worker or End User, I think is just that. They don’t (and really shouldn’t have to) care about Sharepoint or Sites or Libraries or any of that. The admin assistant wants their spreadsheet where they can find it with a click and start working. The CEO wants their dashboard where they can find it with the information they needs for the next meeting. And they both want Search to be simple and to work.
The third level, the Site Collection Administrator role, I think this should really be in the hands of someone who is not just part of a department or division whose job includes Sharepoint, but someone whose primary role is IT or better yet a Sharepoint Admin. I just think that someone who has access at the Central Admin level should really know their way around Sharepoint more so than a Power User. An example is just what I’ve seen here, both Enterprise and WSS. And everything’s a Site Collection. And a most of those consist of one Team Site with a library, an Announcements part, and maybe a Calendar. And now they want to combine and bring everything up to Enterprise. Good idea, finally. I just think that the Governance of creating Site Collections deserves more attention and a higher level of Sharepoint expertise and focus.
Now the middle level, the Sharepoint Coordinator, Collaboration Engineer, or Project Leader, the Power User. This is the role I think best fits the definition of a person needs more out of just the day to day task list. First of all, I’d be sure to give them this link: http://www.endusersharepoint.com. Then after the Site Collection is created, this person would be responsible for everything else. They should be the ones creating sites, adding/monitoring content, security, web parts, etc. And they should be given access to Sharepoint Designer, mostly for additional web parts but more so for workflow. Once they grow with these responsibilities, get comfortable and want to continue, then they can move on to Site Collection Administrator.
Admittedly my Sharepoint experience is fairly narrow up to this point, but I hope this helps add to the discussion.
Hmmm… I tend to think of it this way:
Users: some one gave you a link to a SharePoint site and you actually have permission to connect to it and possibly contribute list content. Congratulations! You are a user!
Power Users: some one told me that I have to give you access to SharePoint Designer so you can manage content, layout and design. I’m going to be spending half my time supporting your every question and helping you fix what you muck up.
Site Owners: you raised such a fuss that I needed to add you to the site owners group. Now you can really muck things up — but only your own sites so I don’t really care. Have fun! When you need help go to EndUserSharePoint.com.
Site Collections Owners: you are part of a small group of knowledgeable SharePoint users who actually get it and whom I trust. Let me know how I can help because you are actually taking work off my shoulders.
Farm Administrators: keys to the kingdom. If you have gotten to this level, you should really know what you are doing.
SharePoint Architect: the guy everyone else in the organization comes to when they can’t find a solution. Hey wait a minute… that’s me!
Thanks for letting me have a moment of levity. But as to your question, I’m not so focused on coming up with a common system to labeling these groups. I just need to know (within my own organization) the powers that I have entrusted to my groups of users. And in defining roles so that my management understand the resources I need to support the environment. If industry standard labels help in this effort then I’m all for it! Please let me know where this lands!!
I agree with alot of Al’s comments. I am a Site Collection or Portal Administrator managing an enterprise portal that includes administration of each Site collection from the root site down. I would say my responsibilities and role is far greater than a business Site Owner who may manage just a business and its hierarchy.
I don’t manage the web application or infrastructure but have read-only access to Central Admin level. From Central Admin up is the Portal System Administrator’s domain.
I have worked in this level of role now in 3 different companies that are all using the same approach.
I’d say that the roles will depend on your architecture.
For example with a well structured Intranet the site collection administrator will have a specific role. While in the case of a collaborative environment with self-creation enabled, the site collection administrator will actually have a profile closer to your site owner/site administrator.
As Jeff said in his comment. SharePoint End User is as the name suggested the User who Ends up using SharePoint. There is such a variety of SharePoint Users that its very hard to fit every one in SharePoint End User. May be we can categroize SharePoint Users in two groups
1) SharePoint Dev Users (Technical staff ie Owners, Administrators, Developers)
2) SharePoint End Users (End users who have very limited knowledge of technical stuff, they just want to get their job done)
Kashif
http://www.sharepointperth.com
From all the comments made here, it sure sounds like one of those “it depends” kind of answers, and having reviewed each of the comments made here thus far, the “depends” seems mostly on the size of your organization and how your IT department may be (dis)organized. So far, I think Rick’s contribution yesterday describes my experience as well, and Rick, we may even have the same job (and the same sense of humour, too! – thanks for your levity and the laughs).
In the organization I work for, we have a SharePoint End-user community of around 20,000, and to help them out, our IT shop (where I sit and sometimes work) has;
(i) 2 SharePoint gurus who take care of our SharePoint farm and answer all the heavy-duty technical problems that can’t be answered by anyone else;
(ii) an Application Support Team who try their best to solve all of the technical problems that users call in about so that our 2 SharePoint gurus above don’t get swamped;
(iii) a local “SharePoint Administrator” on the business side for each and every line-of-business client group we have (setting up this role is mandatory for each and every business group or else they don’t get a SharePoint site – period), and these people serve as our first-point-of-contact to the client, answer their (business) colleagues’ “how to” questions about their SharePoint solution, and have the permissions granted to them so they can do user administration; and
(iv) Me.
Now, in addition to this full-time job, I’m also a part-time SharePoint course designer, author, and teacher, and so I’d like to offer my idea of “What is a SharePoint End-user” is from both of these perspectives.
SharePoint End-users are those who use SharePoint (duh!) but care nothing about it other than how it impacts their jobs (and they don’t have jobs that are in any way related to SharePoint technical work, of course). Some examples are all the employees in your organization’s business groups, and all employees in your IT shop whose primary role has nothing to do with SharePoint, like senior executives, senior managers, and the administration staff). Well, that’s it really … that’s my definition of SharePoint End Users. The only other breakdown I would suggest is SharePoint Power Users. They are a subset of my SharePoint End-users group above, but what distinguishes them from the rest is that they have fallen in love with SharePoint enough to pursue it way beyond their colleagues, AND, their pursuit is NOT because they want an IT job doing SharePoint; rather, it’s because they believe they can get their jobs done so much more effectively and productively the more features and functions of SharePoint they learn about and adopt.
As for all of the other ones mentioned in the main article, my training experience suggests they can all be lumped into a SharePoint Technical User group. I say this because I don’t like doing the technical courses that these folks seem to want, but I love to do the courses my SharePoint End-users (incl. the Power Users) seem to want. For me, it’s that simple. In fact, if you look at the curriculum for most of the SharePoint courses on offer, 98% have technically-oriented subject matter, and as for the remaining 2%, their End-user subject matter is almost always combined with tech stuff as part of an introductory course. There are the odd exceptions that are truly SharePoint End-user courses only, and one of them is the one I have done.
Anyway, I can’t believe I’ve written this much. So for those of you who are still awake and/or who haven’t yet clicked off my contribution, thanks. Hope this helps. Most of all, I hope my perspective is not so provincial as to be irrelevant.
Rob Kronick
Funny that you bring the topic of SP Titles up at this time. I was thinking of these titles the other day and while I agree with much of the iteration and reiteration of the comments above, I’d like to present a different approach to the Sharepoint title conundrum.
Bear with me just a moment while I digress. We know it takes both IT and business units working together to provide the outcomes and achieve business goals. If we think of the business units as collaborative partners, we think about the merger of business and IT as a way to thrive, not just survive.
We need to get our heads out of IT nomenclature and think business services management (new name for IT but don’t tell anyone I said so. Oh and for some of you, it is not meant to damage the territorial IT egos out there). To achieve business services management (BSM), business and service (IT) must be in agreement with respect to each others’ goals. Ok, where does that leave us?
It leaves us with collaboration thru partnership, both internal and external.
The suggestion below shows a breakdown of a Sharepoint Services Management Team to include Sharepoint Business Partners and Sharepoint Service Partners. Each of these groups is then broken down into the various roles determined by the enterprise to support their SP environment.
Sharepoint Services Management Team
- Sharepoint Business Partners
o SBP Site Collaboration Team
- Sharepoint Service Partners
o SSP Site Collaboration Team
When IT partners with business through collaboration then we achieve a recursive process where two or more people or organizations work together; intersection of common goals by sharing knowledge, learning and building consensus.
All of your suggestions describe levels of users and not actually “End Users”. I believe the true end user is a view only user seeking information from SharePoint. All other users are middle layer users.
All of your suggested users do something in SharePoint to present information to a viewer/reader, this by definition is a middle user and not an end user.
Rod,
Pretty obvious I disagree with you there. What you are describing to me is a basic Information Worker who has contribute and consume access.
The other “middle users” as you describe them are still part of the SharePoint usage group that I define as End User.
If you can help create a term encompassing all three groups, that would be helpful.
Mark
So, which am I? I am a staff person who works with an IT person to set up a database for our department. She knows SharePoint but HAS to work with me to learn what we are trying to accomplish in setting up a database to make it work for our department. I set up a database in another environment at another firm, but do not know SharePoint. So, we have been working together to make this database work. We are tweaking it now. I have editing rights on certain things. I call or e-mail her when something isn’t working correctly or an addition to the database is needed. She tells me when something on her end isn’t right. So, I want to know more about SharePoint from my end, but I seem to run mostly into articles for people on the IT end. Can you tell me what search terms would be most helpful for me to use? I will be the primary manager(?) of the database once it is fully functional, contacting IT to new “fields” (or whatever you’ll call it) as new information needs to be added or changes made, so it will be a continual collaboration. So far, in all my web searches on SharePoint, I’ve only found a handful of helpful information. I just don’t read much about that collaboration on any websites I’ve seen. And, aside from my limited needs in SharePoint, I have no clue what else it will even do that would enhance the database being created. I have to depend on IT. And she has to depend on me for what I need for the database to work properly for our department.
I am training one person in another office on how to use the database. Once created, I will be responsible with that other person for keeping the data up-to-date and creating a lot of Excel spreadsheets (our ultimate goal of managing information).
I think when two people have to work together to accomplish a task and neither knows the other’s field of expertise, there are a lot of “aha” moments and then you make changes as necessary.
I think I am probably all 3. So, what’s the best way for me to search and learn more, knowing I will never need to learn the IT side of things. But I do want to know more. Thanks very much.