Supporters of End User

SharePoint: Empowering the End User

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.
Categories:SharePoint Designer; SharePoint Saturday; General Knowledge; MOSS; WSS; 2007; 2010

You may also be interested in: Smartdesk Advanced ECM Apps


Editor's note: Contributor Christian Buckley is the Director of Product Evangelism for Axceler. Follow him @buckleyplanet

An increasing trend at SharePoint events around the world is a shift toward end user content, rather than developer or administrator-focused sessions. As the platform matures, more and more business users are reaching out to the community to better understand what SharePoint can do, and how to get the most out of the platform.

In a session at SharePoint Saturday Twin Cities, Kerri Abraham (@KerriAbraham) and Wendy Neal (@SharePointWendy) discussed this shift toward the end user in a session entitled "Empowering the Power User" that focused on the often-overlooked need for "citizen developers" within the end user community, many of whom have the ability to shape the platform for the rest of the organization. Kerri brings to the table a background in health care and working within a very restricted environment, where SharePoint business requirements were going unmet and her efforts to modify and configure the platform were often blocked by management and IT. Wendy, on the other hand, brings a background in financial services where she has worked as a .Net developer, more recently moving into an architecture and business analyst function within a very supportive environment, where she has been able to stretch in her role as a SharePoint administrator.


Together, the two walked through some of the cultural differences between their respective backgrounds, discussing the impacts to change and innovation between a restrictive and secretive organization where minimal training was provided by IT, and an empowering and open team where communication and learning were emphasized. As one of their primary themes, they asked why many organizations are still talking about locking down SharePoint designer. Their guidance? According to Kerri, "You don't want to be the "SharePoint Nazi" in your organization. To move things forward, you need to mitigate fear about what can be done -- and how it should be done -- to improve concerns from IT, improve definitions and goals of the power user, and clarify boundaries for what should be done by the user, and what should remain within the control of the administrator.

Wendy explained that you need to clarify roles, because a power user is not the guy who just comes into SharePoint to do basic functions. Most power users have a specific skill set. Not every power user is a site owner, but most site owners are power users. Power users spend the time, have the interest, and have the right abilities to do more than your average end user, who may only be interested in uploading and consuming content or performing basic business process management tasks. Wendy talked about spending much of her own personal time to develop her SharePoint skills and knowledge, above and beyond what her company provided. Kerri and Wendy both agree that these are the people to work with, and develop along the power user path.

Kerri outlined some of the basic areas that a power user needs to understand:

  • Set creation
  • Permissions
  • Navigation
  • Filtering
  • Sorting ootb workflow
  • Alerts
  • List library management
  • Metadata management
  • Content types
  • Site maintenance

One idea that the two introduced which really resonated: Developers first need to be power users so that they really understand what the business is trying to accomplish, and understand the needs and real world scenarios for end users. Once you understand that power users are attempting to map SharePoint to the business requirements, so developers are not out there reinventing the world, it helps put the role into perspective. Much of the vision that people are sold on with SharePoint is precisely within the realm of the power user -- they speak the language of the business, of the end users, and translate those requirements into the more technical language. They are the masters of out-of-the-box (OOTB).

Why is this role needed? As stated by Kerri and Wendy, real adoption happens when end users are able to do more business, when they start actually using SharePoint. You can't force end users to adopt. They adopt when you improve their experience. SharePoint is all about change, and change is scary. We need to mitigate fear through documentation. We should document the change requests, and as we make changes to the platform so that we can better pan, better mitigate risks.

Going back to their SharePoint Designer argument, they agreed that there are risks with giving people access to SPD: downtime, server crashes, loss of content. A real-world mistake might be losing a site due to modified master pages. Creating a SPC workflow with endless loops is extremely unlikely, but has happened. That's why learning takes place in a test environment, and why access should only be given to those who have had additional training. Kerri briefly mentioned the issue of configuration management. It's a problem with SharePoint. While it can be done using Visual Studio TFS (Team Foundation Server), most organizations do not use it (unfortunately), and don't follow best practices for managing changes within SharePoint. Far too many orgs don't document their code and their changes. One things Kerri and Wendy have learned is that change management is hugely important in SharePoint.

But the bigger issue, they believe, is understanding what is business critical versus what is user-dependent. Kerri mentioned her article about Laura Rogers on, and how she (Laura) should be considered a developer, not just an admin or a power user. What she discovered in the days following her post is that the subject of who is a SharePoint developer is a very touchy matter in the community. All she meant was that Laura, while not a formal software engineer, was in fact developing SharePoint. While a semantic point to some, people got caught up in the dialog, and it spurred many other posts and community conversation.

At this point, I commented that much of the function of the power user is because the business is not meeting the needs of the business, and someone has to step up to meet this need. If the platform were designed to meet business needs, or were more responsive, then the role would not be needed. But the requirements of the business are a moving target. Power users are needed not as the only solution, but as part of a more responsive organization. It's all part of an ongoing support and sustainability model. Most of what power users do is out of the box, but by having them involved, they help the business to get more out of the box with SharePoint. In short, they help drive a return on investment.

As they concluded their presentation, Kerri and Wendy focused a bit more on the importance of documentation. They stressed the importance of documenting why you built what you built, what it was meant to solve. They advised that you should make the documentation quick and to the point, and document where your solutions and scripts live, what they were meant to solve.

Kerri then raised her right hand, and read through her "combat script stupidity vow." Her guidance: People need to understand what a script will do before you launch it, and understand what it will do if it breaks, and what will happen without it in place. She concluded with the advice to go into changes with both eyes open...which is also why power user role is not for everyone. It takes passion and dedication and knowledge.


You can find a copy of their presentation here.


Thank you for highlighting our topic!

I'm hesitant to point out that you've directed folks to that "Laura Rogers, You ARE a Developer" article, but since you linked it in, I thought I better restate what I stated in our presentation:
This is not a pot needing to be stirred, but a recipe needing to be shared!
I feel very strongly that by adopting a respectful attitude among all involved, we can put Designer lockdowns behind us. Teach power users to document as a junior developer should, respect their ability to connect to the end-user in a way that IT sometimes misses, and realize both sides have the same goals: Business Success!
The PowerPoint was intentionally put together for users to present to their IT departments to help them win their fight for SharePoint Designer. The chapter I wrote in 'SharePoint 2010 at Work, Tricks, Traps, and Bold Opinions' should provide them all the amunition they need to present the topic to those enforcing those restrictions.  Keeping folks with SharePoint passion from the tools that expand their skill set is just wrong!
Wendy and I were honored to have you sit in on our session and even more so that you would take the time to highlight our topic this way.  Thanks Christian!

Posted 12-Nov-2012 by

Combat Script Stupidity Vow

Thought I'd share the vow - I learned a tremendous amount from the use of and manipulation of client-side scripts - they shouldn't be blocked...but their use SHOULD always be documented for future sustainability! So here's the vow:
I will test all scripts I use on my site outside of the production environment.  To the best of my abilities I will make every attempt to understand the code in the script and what it is doing before I test it.  There will be documentation surrounding the use of the script, why it is needed, the origins of where I copied it from, and any and all edits I make will be included in this comprehensive documentation. I will educate myself on best practices, attempt to follow them at all times, and share that advice with those in my environment that may use this library. While my goal may be third tier, I will fully recognize that I probably should stick to client-side manipulation until I have a better development background.  I will promise to follow the approval process for use of new scripts in my environment as outlined by my SharePoint administrator/architect.

Posted 12-Nov-2012 by


I'm all for documenting ALL sites. When I came into my role (basically a SharePoint Business Analyst in my division) there was no documentation for anything. They have been using SharePoint as a catch all for the last 5+ years and it's crazy. Working on cleaning that up, cleaning up permissions, creating processes and documenting has been a task.
I am working on a standard template for documentation for the sites I work with. They are almost all OOTB, but some might have custom HTML or javascript. Does anyone have examples of the documentation they use for SharePoint sites?
As for the power users, we have several in our company, who want to do more, but can't. Even I get frustrated because I can't do a simple custom workflow because only a couple people in IT have the permissions to use SPD. I do sometimes get frustrated with the fact that I can't always do what my users really need to make them more efficient and fit their business needs. Not to mention when they upgraded they only really upgraded the server. It still looks like 2007, but some of the functionality is different. Things like excel services which they really could use, are not enabled, because they aren't using the ribbon and the 2010 full template. What's worse is, that if someone needs to know how to do something, I have to do custom documentation because the steps are not like 2007 or 2010. It's pretty crazy.

Posted 12-Nov-2012 by LHD
Darren Hemming

Why this presentation was important

Kerri and Wendy's simple presentation of how power users can transform the use of SharePoint will change the world. In years to come, students will trace back revolutions in business, IT and project management to this very session.
The reason is that this presentation represents a significant change in the roles of IT workers. No longer will end users be (totally) dependent on code developers and engineers to provide them with functionality. Through SharePoint, with the encouragement of gamechangers like Wendy and Kerri, power users will begin to build their own functionality.
As Christian's article recounts, it really is a case of managing lists, views and permissions, perhaps with some occasional workflow within SPD. Though in the future I can see more and more 5th generation software appearing to help power users create their own SharePoint apps, even without code. Microsoft Access 2010 and Access Services is already a powerful illustration of that.
But this isn't just about reducing frustration for power users. Allowing non-programmers to develop SharePoint functionality will have real implications for businesses, large and small. Principally, processes will be streamlined with a minimum of fuss, and with high degrees of agility. In short, a business which uses SharePoint effectively, where power users are encouraged to design, develop, test, and document their own solutions, is likely to see major improvements in efficiency and productivity.

Posted 13-Nov-2012 by Darren Hemming
Kerri Abraham

Thanks Darren!

For the record...those top two comments are mine, but they don't show my name. :)
Darren, I'm humbled by your comment.  I doubt that anything so grand as changing the IT/business world will occur related to our presentation but if we can help even one user win their battle with IT will feel triumphant! 
The per user budget requirements for supporting SharePoint continues to grow and industry-wide IT is taking notice of what it takes to manage SP.  My concern is that within the SharePoint community we are not giving enough thought to sustainability of the platform. 
Imagine power users like me in every organization, building hundreds of undocumented solutions for their end-users (not corporate HR...those workers in the trenches...the ones IT so often overlooks because their plates are just too full to handle those needs) and processes change, employees leave, Microsoft changes SP in ways that leave old solutions unsupported (Design View!) WHO supports that?  How do you support solutions when you have no idea who built them and why?  OOTB or with Designer...we are missing vital information!
As a community I think we are being neglectful to not recognize that every single solution on the platform needs documentation of some sort.  As a COMMUNITY it is our responsibility to spread the word since the very reputation of the platform we are all so passionate about is at stake if we don't.
Thanks always for your support Darren, means a lot! ~Kerri

Posted 19-Nov-2012 by Kerri Abraham

Notify me of comments to this article


Add Comment