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
- Sorting ootb workflow
- 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 NothingButSharePoint.com, 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.