I got 3 words for you ...
Plan
Plan
then Plan some more ...
Ok .. so this isn't specific for SharePoint, all Software development projects are reliant on planning for successful execution (how can you know if you have delivered, if you don't know exactly what you are supposed to be delivering?) but SharePoint has this point in spades.
The first reason is Scaleability. SharePoint scales extremely well (up to 40TB in Lab Conditions according to the Microsoft SharePoint Team Blog). In fact there is an excellent Whitepaper recently available on this topic: SharePoint Server 2007 Scalability and Performance whitepaper.
However ... this level of Scaleability can only come if it has been planned for. You cannot simply install SharePoint "OotB" (Out of the Box) and expect it all to work.
The main effort required in the Scaleability process is the idea of "Site Collections", each of which is reported to scale easily up to about 50GB (although the labs mentioned above had >100GB Site Collections). Either way, if you are looking at an enterprise level implementation you are probably going to run out of space at some point and that will cause problems.
So .. you need to factor in Site Collections to your infrastructure. I won't spend ages talking about them, but there is a great article by Hiran Salvi on Sites vs Site Collections that is a must read on the topic.
The other main factor is Content & Metadata Maintenance (also sometimes referred to as "Metadata Governance"). If you have been working with SharePoint for a while then you are bound to come across a client who asks the following:
"Can I add a column to all of my Document Libraries?"
Now ... if you haven't planned for Content Types then this could be a really big headache! Content Types are effectively the schemas that define all of your SharePoint storage. Each time you create a Document Library it is using the OotB "Document" Content Type. Now .. you could go and just modify the Library itself, but then you are effectively breaking your Content Type structure and that is bad mojo! (what happens when you want to modify said column after you've added it to 50 libraries?? you'll need more than one cup of coffee for that job!). The main problem is that you cannot modify the "Document" content type either! (well .. you could ... but you will probably break something doing it!). The reason is that a lot of other places in SharePoint also use that Content Type (such as "Master Page Gallery" and "Page Libraries" to name but a few!). A second major problem is that you cannot easily modify all of the Document Libraries either! (I mean .. thats what Content Types are for .. right?)
The recommended practice is to create a custom Content Type for all of the user-created Document Libraries. If the client wants to add a column .. no problem, you just add the column to the new "custom" content type, and Robert's your father's brother!
Of course .. if you didn't plan for that in the beginning ... well .. you'll be in for some pain! You either have to pay a temp to sit on your server for days on end re-allocating all of the Content Types system wide, and then you still haven't solved the problem of new lists and libraries that keep getting created! Or you have to get a developer to spend some very expensive days writing code to go around and do it all automatically!
.. either way .. best to be avoided and will be far cheaper in the long run if you plan for it!
The final point on planning (and by no means the final word on the topic, just the final point in my ramblings) is the following:
Who is going to use the system? And how will they use it?
Far too many people assume that SharePoint, being a Microsoft product .. hmph .. will just work out of the box and will solve all their problems (including World Peace). The truth is .. SharePoint is an advanced and very very complex web development platform.
Yes, it provides a whole raft of management, maintenance and administration functions and offer variability and flexibility like few other web based systems before it! But it requires time, a LOT of thought and plenty of expertise to deploy correctly.
The most important part of this is the users. What business requirement is being satisfied? What is the reason for using SharePoint (or any web based system?), what are the problems and how has this implementation been designed to solve those problems?
Last but not least .. never never never neglect the end users, especially the Content Managers. I have seen 2 things commonly happen which cause projects to fail:
1) "We'll just give them all Team Sites"...
This is a classic. You create 500 Team Sites ... one for each department / user group / business stream / office / project.
There is one major problem. they are ALL EMPTY!
99% of users will load up their nice bright shiny portal ... and look at these nice big expensive blank pages. Then log off and probably never return.
If you don't give them content and relevant design then you won't get any buy in!
2) "We'll let the Site Owners do what they want ..."
This is probably worse that point (1). At least there you can rebuild and you don't have to worry about the current system (because it's pretty much empty .. right?).
Now don't get me wrong ... this technically CAN work .. but you need Effective Training to make sure that your Site Owners understand the followig ideas:
* How to manage content
* How to create a hierarchical structure that works
* How to manage security permissions
* What is vision for the system as a whole?
* What do we want people to use the system for?
Without a unified vision for the system you end up with an implementation that is haphazardly put together, where each site has it's own layout, classifications and web parts. Trying to central manage a system like that will be a nightmare .. for both the project leaders and the systems administrators!
Well .. thats my ramblings for now, hope some of these nuggets have sunk in.
As always ... comments welcome!
- Martin Hatch