Many companies have a blanket “No SharePoint Designer” policy due to the risk the tool poses to the SharePoint environment. However, the real risk to the platform is not Designer, but a lack of development discipline. More than just opinion, this chapter introduces a model for empowering users that does not compromise the IT department’s need for strict oversight. By combining basic configuration and project management theory with the features of OneNote, a SharePoint library, and a few content types, it is possible to provide users with the opportunity to build powerful solutions and preserve judicious control for IT.
The SharePoint Designer lockdown debate is a heated one to be sure. What is perhaps most interesting is that this topic rarely falls into that standard SharePoint response, “It depends.” There seem to be two distinct camps: those in favor, typically SharePoint professionals who understand the tool and praise its ability to add another layer of sophistication to business solutions, and those against, mostly in IT departments where great effort is made to lock down and prohibit its use.
Does a SharePoint Designer lockdown in a workplace where strategic goals of engaging employees and enhancing the work environment make sense? What message is sent to users who strive to learn every aspect of the platform’s capabilities but are continually blocked from the tools that would help them further support their team and build better solutions? The ramifications of enforcing such restrictive policy extend beyond stunting an organization’s collaborative culture; ultimately, these lockdowns are oppressing future SharePoint talent.
Do we eliminate risk to the platform at the cost of crippling our most enthusiastic SharePoint evangelists? A study published in The Journal of Applied Psychology in September 2011 by the University of Iowa confirmed that workers who feel empowered experienced a higher level of morale and are more productive, and those same attributes further enhance the overall team dynamic.
Empowerment is not something one can bestow upon another, it is merely the act of removing the barriers that control an individual’s ability to take action and make decisions about how she works. Successful organizations know that empowered employees are engaged employees. Considering the demand for current SharePoint professionals and the potential for SharePoint maturity that can be achieved with the help of an engaged and capable Power User, why would any organization risk restricting the growth of an individual who shows proficiency with the platform? An empowered employee who knows the business and SharePoint is a very valuable asset!
In the same way that not all rectangles are a square, not all Site Owners are Power Users. The SharePoint learning curve can be a steep one, and depending upon the environment, the work demands, and the opportunities to problem solve, it can take some time for a user to get up to speed. True Power Users will set themselves apart from site owners by their drive to expand their knowledge.
Users with this kind of passion are self-starters, just as likely to point out every flaw with the current process as they are to come into that discussion with ideas for improvement. In addition to having a “lean” mentality toward identifying inefficiencies, a Power User is both curious and courageous, pushing the capabilities of the platform to the limits just for the sake of learning where those boundaries fall. These skills are essential to learn prior to using a more powerful tool like Designer, not just for a Power User, but for anyone developing the platform.
Power Users are those who embrace SharePoint and build incredible business solutions for their team. They do not pick up the phone six times a day to ask how to fix a broken hyperlink, delete a document, or add a column. Power Users know how to manipulate lists, sorting, filtering, and grouping metadata like a pro. A seasoned Power User can answer End User problems without ever seeing the site or the actual issue. Sticky topics like content types and permissions are second nature to these folks.
Anyone developing a skill set such as that has obviously been bitten by the SharePoint bug, and that is a hard bite to shake. These rare folks are passionate about learning everything they can, and blocking them from expanding those lessons to SharePoint Designer is a shame. The only possible explanation for keeping someone with adequate knowledge of the platform from a tool like Designer is fear.
These lockdowns are the borne from fear of losing control. To be perfectly honest, that fear is completely valid; SharePoint Designer in the hands of the wrong user can result in some rather serious damage. However, a blanket policy for a platform that was designed with the intent to empower business users to build their own solutions is not a courageous method for managing that fear.
It is widely accepted that SharePoint is not a product, but a platform. As such, it requires some customization and development to be useful. It is inevitable that every Power User will eventually come into contact with the greater SharePoint community and have their eyes opened wide to the myriad solutions that can be created, many of which require more advanced tools like Designer. For SharePoint maturity to advance, both in the skill set of the user and for the organization, some forward thinking is required where the benefits of using Designer are seriously evaluated. After all, aren’t the goals on both sides of this endeavor the same? Everyone wants to see business prosper, and absolutely no one ever wants to be the cause of a site restore from backup!
The argument that a knowledgeable Power User might possibly crash the server if allowed access to SharePoint Designer is a weak one. The likelihood of such an outcome is rather remote, especially for a business user (developers, however, might run a higher risk of hosing things). Most SharePoint experts agree that it takes an extreme set of circumstances coupled with a dangerous bit of ignorant abuse to actually bring down a server with SharePoint Designer. This crashing the server notion is little more than a deceptive rumor used as propaganda by those who misunderstand the tool.
Now, the reality of crashing a site is a bit more probable. It happens; it’s actually easy to do and it is sometimes extremely challenging to fix. However, it should never happen in production. Power Users should learn to use Designer in a test environment, which means they need to be provided one that is kept updated with production.
The use of a staging or test environment is fundamental to the reliable maintenance of any platform, but it is nonetheless true that some IT departments do not provide such an area for their Power Users. For the bulk of the customizations discussed here, a test environment would not necessarily require a separate farm or even web application; a Sandbox site collection will suffice.
Take SharePoint out of this discussion and realize that building a business platform requires a team effort. Business users should be recognized as the primary content contributors, while IT’s role is centered on creating a sustainable environment. The crux of this debate is entirely dependent upon each side respecting the other’s role and finding the middle ground that will both support and sustain the development that results in a successful deployment.
Easier said than done! How is IT supposed to ensure the future viability of countless business-critical solutions and accommodate such a varying degree of platform development? Most will reference the need for governance, but SharePoint provides an array of powerful tools right out of the box that allow Power Users to build elegant and somewhat complex solutions without ever laying hands on tools like Designer. What happens when those users leave? Who supports those solutions when they are gone? Did they leave behind any kind of documentation? Were they ever asked to?
Ironically, what should send a shiver of fear up the spine of any IT support team is not a handful of disciplined Power Users granted access to tools like Designer, but rather one rogue Power User building business-critical solutions without a note of documentation. Each user is a silo and when that silo leaves the business, that knowledge is lost. When a group of power users work together to learn the platform and document the journey, the team learns and leaves behind resources for further knowledge sharing. The fear should not be of more powerful tools like Designer, but of creating silos of knowledge that potentially deprive the business of crucial skill and understanding when those users depart.