Much has been written on the topic of SharePoint governance (and just to satisfy the Bing lovers: SharePoint governance). Microsoft even has a Governance Resource Center for SharePoint on their TechNet site. While most of the content I’ve found is quite good, though a bit fragmented, I still felt like there was something missing.
In fact, all of the discussions around governance got me thinking about the idea that you should be able to create a model where governance just “happened.” Before you go away thinking that I’ve spent a bit too much time inhaling paint fumes, hear me out: is it possible to create a self sustaining “culture” of governance where participants reinforce content and technology best practices because “that’s the way we do business?” I think the answer is: YES.
Recently, I’ve had the opportunity to work with a number of older companies – companies for whom computing technology is relatively new compared with their years in business. Many of these older companies, especially those with a strong founder affinity, have a deeply engrained company culture. This culture is so pervasive that it permeates virtually everything they do without being overbearing.
I’m not speaking of the largely manufactured “culture” we saw sprout during the dot com days; that’s the kind of culture that never leaves any lasting impression beyond a few hollow words by an executive. I’m speaking of , the real ingrained and consuming kind of culture. Examples can be found in companies like GE, Caterpillar, Kiewit and the “old” IBM (somewhat paradoxically specifically because they’re a technology company). These companies have a “way of doing business” and new employees quickly learn this “way” by having it reinforced by the processes and people around them.
Another such culturally rich company is PCL Constructors Inc. They’re based in Edmonton, Alberta, Canada. PCL’s founder, Ernest Poole, created a memo that’s now called “Pooles Rules.” At the time of its creation, it created the basis for a company culture, PCL’s business practices and values. Even today, the words of Mr. Poole are displayed throughout their headquarters and guide the companies business practices.
What struck me about the rules was the plain and simple language used to describe “how to do business.” These rules can be applied to a broad set of circumstances, even ones that couldn’t have been anticipated by Poole himself. Today, while the language may seem “old,” the concepts and guidelines haven’t gone out of style and PCLers still largely operate using the insight that Mr. Poole jotted down on a single piece of company letterhead nearly 70 years ago.
To demonstrate just how applicable the rules are, I’ve created a derivative work that could be used as a basis for a SharePoint governance “culture.” I’ve replaced certain words in Poole’s Rules with more SharePoint or portal-relevant terms (if necessary).
- Employ highest grade employees obtainable
SharePoint is a unique product with it’s own complexities and nuances. I’ve seen some companies try to “fit” employees into a SharePoint administration role or use less-experienced resources to create solutions. Just as Mr. Poole suggests using the highest grade employees to build a building, you should strongly consider the same approach for your SharePoint environment. Frankly this rule is just good business and common sense. - Encourage integrity, loyalty and efficiencies
Create an environment where your content consumers and contributors see the SharePoint solution as central to their work. This means avoid “snazzy” features for their own sake and instead focus on real time-saving or productivity-improving functions. These functions don’t have to be complicated and can be simply a good employee directory or the place to find the right template for proposals. By considering the time your users will invest in learning the new SharePoint solution and leveraging any given function, you’ll avoid overloading them with frivolous content or features – this builds loyalty, trust and a sense that the SharePoint application is meant to improve efficiency, not make it harder to get work done. Further, employees won’t try to use “rogue” applications to get their work done, since you’ve demonstrated real value. - Avoid side lines
Don’t try to make your SharePoint environment be all things to all people. As I’ve mentioned in the past, SharePoint has strengths and weaknesses. Make sure you know what they are and avoid trying to make SharePoint do something it wasn’t meant to handle. It’s better to do a few thing well than create a broad, mediocre application. - Do not permit side lines by employees [or SharePoint environments]
Don’t allow rogue SharePoint implementations in your environment; more than one organization I’ve worked with suffers this problem. Multiple, unmanaged SharePoint environments cause lots of pain in the organization and confuse the general employee population. I would highly recommend working to create a tightly controlled, singular (or set of SharePoint) environment(s) that can be relied on, supported and recovered (in the of a disaster). The idea is not to create a uber-SharePoint group, but rather apply real discipline to the management of the environment, even if more than one group physically operates an environment. - Be fair in all dealings with owners [content contributors and consumers], architects [SharePoint managers], engineers [internal SharePoint developers] and sub-contractors [consultants]
The critical bit of the initial deployment as well as long term application management is to understand there are lots of individuals, groups and interests involved. You will do well to develop very clear goals for your environment, a plan to achieve the goals and metrics to measure success. In addition, communicate constantly with everyone involved. How does this equate to fairness? In the end, no one group can bear the brunt of the development or maintenance. Your contributors can’t be expected to create content over night, managers can be expected to solve “world hunger,” it should be understood that it will take more than 24 hours to design/develop/test/deploy a SharePoint solution and any consultants you hire don’t know your business as well as you do. In addition, you need to make the environment accessible and easy to use for your content consumers. Try to minimize overburdening one group or another when developing and maintaining your solution. - Keep your word as good as your bond
This is about credibility. If you (as the “owner” of the Intranet) want to encourage use, make sure you deliver what you promise and what is useful. This means not only delivering the obvious – SharePoint functions and the environment – but also the ongoing content contribution, continuous improvements and overall management. Living web applications – whether their internally or externally facing -- need to be cared for and “fed” to survive. Once you’ve built your solution, you or another group must be responsible for keeping your implied promise that the solution won’t be abandoned. - Give encouragement and show appreciation
I had the good fortune of working for knowledge management guru Susan Hanley while at Dell. She was famous for saying that organizations should use techniques like “bribery” to create a vibrant community of content consumers and contributors to build up an intranet. In fact, as she often pointed out, without both communities, a intranet will wither and die away. Providing encouragement and showing appreciation is especially important for fledgling SharePoint environments; participation and adoption are paramount to success. It’s also critical for ongoing success; consider your own population and develop a program that continuously provides encouragement and support to all communities involved. - Be firm, fair and friendly
Think outside the box, encourage suggestions and get folks involved. Improvements or changes can come from all levels in the organization. Treat all who participate as if they can constructively contribute to the environment. However, it’s also equally important to set firm ground rules for that participation and refuse some requests if they’re either unreasonable or don’t fit the “model” you and your team have developed for the application. See the “avoid sidelines” rule. - Avoid jobs where design is not good or financing doubtful
If you don’t have the funding, time, human resources or the budget to effectively create, deploy and maintain a SharePoint solution, don’t start one. I have seen numerous companies attempt to develop a solution with insufficient resources, thinking “it’s just a simple intranet” or “SharePoint does that out of the box.” There is nothing simple about an intranet and while SharePoint does provide a lot of out of the box functionality, more enterprises must buy add-ons, build customizations and deal with challenges that are often underappreciated. - Good accounting and cash keeping are essential [Develop good metrics for success]
- Do not let finishing up of jobs or collecting payments lag
These last two bullets are close enough to lump them together. In construction, like developing a SharePoint solution, demonstrating success is critical. How do you demonstrate success? You have objective measure to compare against. Whether this means that the new application supports a certain number of users, that it helps to reduce the time it takes to accomplish a task or eliminates work altogether, you have to be able to measure it. Many organizations say that it’s impossible to measure productivity improvements or more “soft” metrics. I would agree that it’s very difficult in many cases to determine whether process improvements have saved time, for example; often you don’t have a baseline to compare against or it’s difficult to gather ongoing data. However, even anecdotes can serve as a metric (e.g. here’s an example of how I save time generating a proposal using the new intranet). Further, stay on top of these measures of success both throughout the initial deployment and the applications lifecycle. It’s the only real way of figuring out whether all the time, money and effort paid off.
Keep in mind that I’m not necessarily endorsing this specific approach for everyone. However, I think it’s an interesting model to explore when developing a governance program for a SharePoint environment. Obviously, a good governance has to include more than just a few rules. That said, writing this blog entry, for me, has only reinforced that there is an argument for creating a relatively broad set of guidelines that can apply across numerous circumstances. Many companies fail to realize this and end up creating an inaccessible, overly complex governance policy. In the end, their policy fails because no one understands it or it is too hard to follow.
Consider creating your own “Poole’s Rules” for your SharePoint environment. I suspect you’ll not only gain new insight on a practical governance strategy, but also end up creating something that outlives SharePoint.
