When Best Practices Aren’t Best Practices

I have a satisfactory tap into the SharePoint community, and something that I see on practically a daily occurrence is taking actions labeled as best practices without understanding the underlying issue and potential consequences of implementation. This seems extraordinarily ubiquitous in SharePoint, way more so than other facets. I believe that a lot of best practices are taken as holy doctrine because it helps abstracts a lot of understanding conventionally required to implement those actions. For some rationale, the resulting approach is taken as divine creed.

Before you read on any further, let me state up front that I am not saying implementing given best practices for SharePoint is bad, I am going to merely state some things that are concerning regarding how they are involved and used.

I think there are three important points that have to be taken into consideration when deliberating, exploring, and implementing best practices for SharePoint. The first is regarding industry verticals, the second company culture, and third about conception.

More Often Than Not a Best Practice Will Not Account For Industry Verticals

Best practices are commonly constructed as boilerplate templates that can be stamped out at an arbitrary organization and similar results expected. Its implementation should result in a more efficient approach to get the best results from a particular task. However, blindly implementing a best practice without considering the industry vertical is one of the largest, and most frequent, mistakes I see. Completely understanding a particular vertical can take years, a vast majority of large enterprises are dynamic, living entities subject to changes, adaptation, and evolution. A person developing and promoting a best practice is analogous to the industry, whereas industry sensitive collaboration deployments require an operational SharePoint practice to respond to industry and industry-bound user’s expectations. The primary obstacle is the tendency to view best practice tackled issues from a holistic perspective. However, for industry compensation it is better to instead package vertical specifics within cottage industries, since they will essentially function independently and uniquely. The current SharePoint best-practices perspective requires an organizational focus taking into account variability at levels fundamentally nonexistent.

More Often Than Not a Best Practice Will Not Account For Company Culture

Introduction of collaboration software, and the resulting enforcement of its use generally results in fear that the exercise will result in criticism and loss of business for someone. One of the largest friction points cultivates when a SharePoint architect implements an information taxonomy adhering to a best practice which presupposes generalization to all organizations. Such a best practice will not adhere to organizational carve-outs which would instead actively implement procedures delineating company cultural sensitive best practices for information architecture implementation. This results in SharePoint not being a competitive piece of software within an organization, since it becomes difficult to demonstrate pragmatic effectiveness.

More Often Than Not a Best Practice Will Not Teach You the Underlying Process

Best practices normally demonstrate a procedure that results in a more efficient approach to get the best results. As a result there is often very little attention that is paid to the underlying considerations that are below the surface. This results in a considerable maintenance obstacle since an organization might not then have the expertise to measure and interpret variability within a SharePoint implementation. As a result, it is common that data collection for maintenance of best practices comes for immediate sources, such as encounter reports and built-in measures. When the underlying issues of the best practice is understood however it is easier to generate meaningful information that allow SharePoint administrators to improve indicators and overall maintenance.

I am not alluding to an argument that I think best practices are bad, I think they are good! I am simply trying to demonstrate a frequent trend I have been noticing that is disturbing, and I think needs to be rectified with accommodations for when the best practice is implemented in an organization.


18 thoughts on “When Best Practices Aren’t Best Practices”

  1. Bravo to you for saying this! I totally agree. I’ve seen too many people working with the product for six months or so — standing up a few sites — and publishing some “best practices” something or other. Maybe it’s right… but how can ANYONE arrive at the total global best practice of ANYTHING in such short amounts of time using a product? In my opinion, it’s totally diluted the term of “best practice” and makes me stop and ponder every time I hear it now.

  2. Adam, great post and something I have come across all too often in the last 12 months or so, again by those whom have only been around the product for the last 12-18 months and haven’t really seen the after effects of a deployment, which arguably don’t take shape until longer after the project team has moved on.

    I think as 2007 has gathered significant momentum and publicity that all manner of individuals are trying to get on board, but bringing with them a lack of discipline in their approach, perhaps not needed in their previous roles or just never considered in the first place.

    Like Scott says, I also hear ‘we have to use best practice approach’ all too often by so called ‘architects or ‘experienced’ SharePoint consultants and when I ask why not this way or how will IT Support manage that or are you sure the business will work that way with that constraint, their typical response usually ends up quoting some well known internet celebrity blogger from the SharePoint community! No names mentioned!

    Like any approach, method or ‘best practice’ it has to be reviewed, understood and discussed/agreed with others.

    At the very least it should be with your peers, possibly the Programme Board of your project and or other main sponsors or those whom may be impacted in your approach if it changes the way a business or culture operates.

    Like you say, best practices in themselves are not bad, but you can implement a ‘best practice’ that wasn’t created with your culture, business or requirements in mind. Hence you may choose to implement a ‘lesser best practice’ approach, because it simply works better for you.

  3. Agreed Andrew.

    It has become a major pain point in my life as a consultant, since I consistently have to argue that flexibility is paramount to making a best practice work. However some when delivered come off so rigid that it is the exact opposite, people try to tailor business to platform, not platform to business.

    I see a lot of failures for that exact reason, round peg / square hole metaphor in action!

  4. Adam, firstly, I agree broadly with your post, “Best Practice” sadly lacks an objective measure!

    One mans best practice, is another mans worst design!

    But, it occurred to me that there was something behind your post! Would been keen to understand some of the specific examples you encountered….

    Round Peg/Square hole is a good one, I have used “When you are a hammer, everything looks like a nail” a few times…

  5. The term “Best Practice” can be quite misleading; in fact, I believe it is the overuse of the term that leads to the kind of issues Adam describes in this post. There are, however, some specific areas in which Best Practices are just that – the best way, based on experience, to implement a given solution.

    For example, I speak often about building high-performance applications in SharePoint. There are a number of hard-and-fast rules to this – correct object disposal, iterative list item manipulation, query methodology, cache management – that combine to make a best practice that can be followed in (nearly) every situation to produce reliable results. I have also seen Adam present evidence regarding application security within top-secret environments that lends itself to the same type of reproduceability – do x and you will get y in almost every instance.

    Areas that do not lend themselves to such definable parameters, such as information architecture, taxonomy, and topology, are those in which best practices are situational but not subjective; that is, there may be certain methods or processes which produce optimal results for a particular set of circumstances but these may not have the same results under a differing set of parameters. We must be very careful when prescribing best practices in these scenarios and make sure our audience understands the context in which the advice is given.

  6. It is inevitable with a platform as complex as SharePoint that people will fall into this trap. In many cases, there is little rhyme or reason why one practice would be “the right one”. The differences between the options is usually subtle, with tradeoffs that are hard to observe or measure.

    So people turn to the experts in the community rather than trying to unravel the complexity on their own. You can’t blame them for focusing on their own core business rather than the technology. And you can’t tell them not to blindly implement best practices and expext them to change their ways. The best we can do is try to find abstractions that work, and simplify this complex platform.

  7. Adam, when people use the term best practice, to me is used for marketing purposes. And also customers or clients need to hear that term when they are going to hire a consultant. To me I try to use the term proven practice, I think is more accurate and realistic, because shows the real experience I have been collecting over the years. This best practices issue is not just for SharePoint projects are also for .NET and others.
    All the best.

  8. Micheal:

    I can agree that it is more important to focus on the business end, however I don’t agree that you can’t pay attention to the technology being implemented at a company as a result of that focus. I believe this is an important part about any IT strategy, otherwise the business “blinders” might shelter important concepts and issues.


    I suppose I *sort of* understand that it may be a marketing term, but in that case it is also a dangerous one. I agree proven practice makes a lot more sense, it solely demonstrates that it is the approach that has worked. However, best practice already seems ingrained so must be compensated for.

  9. If every best practice was applicable verbatium quo, we’d be doing better things. So I totally agree with your post, but there is still value in learning best practices.

    So, when are you fixing the dark blue links on the dark gray background?

  10. Adam, I totally agree with you. Not all solutions need the degree of complexity that some “Best Practices” dictate. Its like the other SharePoint word pushed around “Governance”. This is partly due to the community chanting it and also Microsoft themselves.
    “Standards” is another word bleated around too. From my point of view there are some things that you should ALWAYS do such as disposing of objects (all what Eric Shupps mentioned basically).
    I tend to use these words, as others have mentioned above, to push more time to “do things properly” rather than throw things together which SharePoint does so well, but in the long run trips you up and doesn’t just graze your knee but breaks your leg!
    I recently came across one where I originally pushed SharePoint Solution Packages, but in house they only had XHTML skills. So we had to move to a Web UI/SharePoint Designer implementation for support and maintenance reasons. We did however point out the limitations of this approach and the risks they face later on in “hacking” SharePoint with this approach.
    The reason I started SharePointDevWiki.com was to try and put all the possible approaches in one place with guidance on which one is appropriate for various scenarios…not to just push one as the ultimate approach.

  11. Jeremy:

    Excellent point! Governance is definitely another buzzword that I think has little, however some, pragmatic backing. Sometimes when it is discussed I question whether it is mostly an esoteric concept, although cultivating an important idea that should be backed into the products. IMHO, governance can ONLY be solved with creative tooling that enforces tailored governance initiatives. Policies help, but rules are meant to be broken! I sense another post coming :)

    God, the project you reference sounds just plain awful BTW. I might have thrown sand in their eyes and fled on foot once they said that.

    I haven’t checked out sharepointdevwiki.com but I will this evening. Sounds awesome!

Leave a Reply

Your email address will not be published. Required fields are marked *