1,688 articles and 12,612 comments as of Tuesday, September 7th, 2010

Friday, July 24, 2009

SharePoint Best Practices: Back to Basics

Best Practices: Back to Basics

Author: Ben Curry, SharePoint MVP

I’ve received many emails from people wondering what I’ve been up to and where I’ve been. If you didn’t know, I run the Best Practices® conference company and consult with Summit 7 Systems. Both of these are in addition to teaching with Mindsharp. So, needless to say, I’ve been busy. 2009 has been an interesting year because I haven’t uncovered as many ‘best practices’ as I have ‘bad practices’.

I’ll be covering some of these bad practices in a series of blog posts over the next few weeks, but I want to focus this blog on the basic premise of Best Practices® and how the concept increases your odds for success. Essentially, I’d like to lead you back to the basics of doing things the right way.

Note: At the upcoming Best Practices® Conference in Washington D.C., I’ll be presenting the Top 10 Bad Practices and what you can do about it.

I’ve many customers that struggle with implementation and support of best practices because of organizational politics, budget constraints, and culture. While most of the SharePoint administrators and developers I work with want to implement best practices, they face impediments and many times just give up. When this happens, one of two outcomes is often the case:

  1. SharePoint doesn’t work like it should and the stakeholders basically come to the conclusion that ‘SharePoint doesn’t work for us’.
  2. The stakeholders believe ‘SharePoint is a bad piece of software’.

In either instance it’s difficult or impossible to then get a successful implementation. There will be too much negativity about the software, in general, and most likely another tool will replace SharePoint. BUT, will the next tool be any better? Probably not! Now, I’ve seen another tool work because a new project manager is assigned the task that has more political power, is a better architect, more completely understands the culture and change a new tool will bring, or all of the above. While that new PM might very well successfully implement a new tool, they would have gotten SharePoint to work as well! So, what can you do to ensure a successful implementation? Get Back to Basics!

What is Best Practices® all about?

Best Practices is about doing it the right way. Part of doing it the ‘right way’ means adapting to the surrounding environment of business, culture, politics, requirements, and security. One of the primary foci of Best Practices is to encourage professionals to think about the best method to accomplish a task, no matter how large or small. While Best Practices is mainly focused on large and complex environments, I honestly believe they are needed by everyone. This is where Best Practices may be very different between verticals depending on the technology, size, scope, culture, and complexity of the problem. Best Practices must be adaptable.

Best Practices should be intellectually simple. The practical application is usually not.

Let me give you a practical application of that. A very common bad practice I see is not using solutions for custom code and farm modifications. The best practice is to use solutions to package everything possible when customizing the server farm. If you’ve already deployed lots of custom code, then this could be quite a lot of work re-packaging your code in solutions. But, what if you had to rebuild the server farm over the weekend and the developers who wrote the code were out of pocket? I can tell you from personal experience that you’ll restore servers from tape to temporary hardware. You’ll then spend hours (maybe days!) finding all of the dependent artifacts (think – features, images, web.config, etc) one by one until you think everything is put back in place. Even then, you can almost be assured something got missed. A Web part, an IIS settings – something that you’ll get a call from the helpdesk on Monday.

I only put this example out there because it’s a real world bad practice due to budget constraints and prior poor system design. I do get it – it’s difficult to go back and re-tool your SharePoint implementation. But, it’s a lot like getting exercise "Short term gain, Long term pain" OR "Short term pain, Long term gain". We want the latter. It’s soooo very nice to rebuild a server farm when all of the custom development was packaged as solutions. I like to make an uber-solution that we can deploy after the configDB rebuild. More on this in another blog….back to basics today.

The point is best practices sound really simple and folks glaze over with boredom sometimes when we talk about them. But, the real challenge is digging into the best practice and finding the best way to implement. By the way, this is what the Best Practices® Conference is all about. We help you with the difficult practical application.
While it’s true SharePoint won’t create world peace, solve world hunger, or solve the budget deficit, it can increase the overall efficiency of your organization. As a general rule, when folks decide to implement SharePoint without outside help or training, it fails. At best, it becomes a glorified file share that has simply increased the cost of storage and operational support!

So, what can you do about it?

First, realize that SharePoint is a tool, and should be used to fix problems it was intended to do so. Second, don’t try to fit a square peg into a round hole. Things like CRM, accounting, portfolio management, and relational data management probably don’t belong in SharePoint. When you try to make SharePoint fit every IT need you have, it’s a sub-optimal experience for all.

Here are some Best Practices basics you should always have in any IT project:

  1. Get the stakeholders involved
  2. Gather requirements from the business people (the more interviews, the better)
  3. Create a project plan
  4. Get some training!
  5. Engage the services of an architect if you don’t have one on staff
  6. Create an IT Governance plan for the project
  7. Prototype solutions
  8. Create a Test and/or Development environment
  9. Execute a test plan
  10. Define Service Level Agreements

Guest Author: Benjamin Curry, SharePoint MVP

Ben Curry – (CISSP, MVP) – is a Microsoft MVP and a highly respected enterprise architect specializing in knowledge management and collaboration technologies. As a senior instructor for Mindsharp, Ben shares his knowledge in training courses that cover the next generation of Microsoft products. Ben is the author or co-author of three books for SharePoint products and technologies, including the newly-released Microsoft Office SharePoint Server 2007 Best Practices by Microsoft Press. Ben has over fifteen years of experience designing, managing, implementing and securing data center IT solutions.

Ben’s Blog

View all entries in this series: BenCurry - Best Practices»
 

Please Join the Discussion

One Response to “SharePoint Best Practices: Back to Basics”
  1. jdem says:

    Great, I’m really looking forward to this series of posts. I’m sure glad I don’t have any non-solutioned server modifications! (well, OK, maybe a couple…)


Notify me of comments to this article:


Speak and you will be heard.

We check comments hourly.
If you want a pic to show with your comment, go get a gravatar!