I've been reading the musings of a very insightful chap at Cleverworkarounds.com.  Very, very impressive indeed.  Paul Culmsee does an amazing job of covering the IT decision makers and a few good bones to chew on for the IT implementers.  From ROI, Planning, Branding, Compliance, and content as deep as Disk I/O he speaks from his gut and gives it to you like he sees it.

I'm not going to tell you he's wrong on right, since I'm not going to take them point by point, but I am impressed by the insights and wanted to tack on some of my own musings on the topic of failed SharePoint projects.  Love some of the images, and I got permission to use them.  I also recommend you do take the time to read through the 5 post series he's put together on this topic.  Why?  Cause I want to make sure you don't fall into chaos, anarchy, or any "SharePoint gone Wild" scenario.  We all want successful SharePoint deployments... well accept SharePoint Hellboy (the Satan of the SharePoint world), someone I met once through blog comments.  He wants there to be lots of failed deployments.  So if you want Hellboy to win, then don't read this...

Let me put these to you in what I'd consider top reasons.  First I'd recommend you look at my 10 Steps to Success Governance Deck, since I'm going to consider that supplemental material.  I hope to publish that in a TechNet article or something in the near future.

Thinking that your Developers are Your Administrators or visa versa as a Great Way to save money (Think Again!)

This should have a few other titles and let me give them to you.  You employ Jack, yep the Jack of all trades.  He dabbles in development and wants to fulfill you dream of seeing all the documents in a single web part on the home page, so he's done it.  3 reasons that's bad.  One he didn't read the article or MSDN that explains the critical importance of disposing of objects, cause he hasn't had time to follow real SharePoint development.  (By the way, it's as important as adding sufficient RAM.) Two he didn't get a chance to test out his tree control and dynamic navigation in a test environment, but it worked on his desktop, so it has to be good, and he's also given great aggressive dates, so it wasn't outsourced since it was soooo easy to build and could be deployed so quickly.  Now you're wondering why you're having perf issues, your environment keeps crashing, and you don't know what is custom and what isn't.  You had to fire Jack, or he left 'cause he became a SharePoint rockstar because "No One" knows SharePoint Development and Administration... (except Jack).  Even if someone did know both, you wouldn't want to give them access to the development environment and production, cause it would break your processes around change management.

You bought SharePoint 'Cause it does everything

(Cleverworkarounds.com - Thanks Paul)

Those that buy SharePoint for BI, Collab, DM, RM, Portal, blogs, wikis, and on and on, and try to do all that with a single deployment, let alone a single server, and tried to scrap existing projects across the enterprise are now looking at this single web application and saying what did we do?  All those promises and I've got 80% of what I need.  Uh Oh.  What a platform right?  Well, if you're ok with the 80% then you're golden.  If you're looking for 105% you're going to be doing custom development till the cows come home, and they don't want to come.  It's the folks that glob onto records management and think that SharePoint comes fully featured and will solve all their digital asset management needs right out of the box that worry me.  I love SharePoint.  I think it's an awesome platform, and an awesome application.  My biggest worry is the person who ripped out Cognos and plugs in Excel services and wonders where the Nth feature is.  It's an easy to use, it is BI for the masses, but it takes discipline.

Unfortunately NO document management system can be thrown in and have people just use it and require no process, planning, or framework.  If you don't care how loose your document management is then you'll be pleased, but you'll end up with collaboration or a delegated form of document management and hopefully some other PM will pick up the pieces and run with it.

The built it and they will come form of document management is rough, but as a service it can be facilitated under the right circumstances.  If anyone can have a site, how are they attracted to your site and your rigid Document Management processes?

I tell customers that if they want to best take advantage of SharePoint they need to understand it's history and where it came from a little bit.  They don't need to know the features intimately, but to understand WSS 2.0 and SPS 2003 high level, they can understand where collaboration and document libraries were and where they are.  Microsoft does a decent job, maybe the best (I think so) at integrating with Office and that's where most companies come from.  Starting from the user, Microsoft's SharePoint offering is the easiest to use to upload a document, download a document, do check in/check out, add some required meta data.  That alone is huge and powerful.  Add on basic wikis and basic blogging capabilities and you've got quite the product... keep going and add rich search capabilities, KPIs, tasks lists, workflows, and on and on, and you have quite the rich feature set that will stack up well against anything.

Providing so much in one box is actually the challenge for your deployment project.  If you expect to do something with everything, and integrate it individually with each team and group and your project will be endless and doomed.  Especially if you go to each group for requirements across all those capabilities.  The two week deployment that turns into two years can result from trying to do the right thing for every team with every buzzword in the product in a large company.

You have to focus on what your business needs are generally and start with the groups that have the need that justified the purchase, then track the ROI and have those metrics before you release it.  Also because of all of these capabilities all in one box, maybe you have very specific scenarios and services you plan for hosting SharePoint inside your company.

Unforunately I can't be at every deployment and there aren't enough MVPs on the planet to be at every large deployment or customer need around the globe.  So use caution.  I've given some recommendation around choosing partners and determining what is somewhat safe custom code.  Remember if you take some, be sure it's a solution and make sure you know how to remove it especially if there's a component that is on the page (like a web part).  Those are some of the hardest to remove in a clean way.

KISS... Keep it simple stupid.  That's what I have to tell people so they don't start with the complex.  You can turn a simple SharePoint deployment into a very complex system very very quickly. (Just create some custom site and list definitions or download them from somewhere like maybe some of those custom app templates.  Just be careful if you do.  Problem is, you don't know how to be careful that early in the game.

Reliability is King... So why Destroy your reliability before you start?

I get most frustrated and saddened by green field (new) deployments that...

1. Don't allocate enough hardware (for high availability given the requirement, have no dev, test, or place to test service packs, even)

2. Don't allocate dedicated SharePoint resources (An Exchange or AD Admin as your SharePoint Admin is just a bad idea (no offense Exchange guys)) See the first issue for more explanation.

3. You have to change everything including the site settings UI before you release the product to your users.  Custom UI especially navigation has got to be the #1 reason for crazy performance issues.  It's also the #1 reason people say the product doesn't scale.  Sure they later like to point at list scalability, but lists are just not well understood.  Poor lists :(  People complain about list scalability without understanding that they can scale, you just have to know what you're doing.

4. Every desktop a developer...  Everyone having SharePoint Designer and Administrator rights is a bad combination.

5. Assemblies required?  Why? Ask yourself 3 times and then go ask a few others if you think you need assemblies before you've deployed for the very first time.  I'm telling you and retelling you the more OOB the more stable your environment will be.  Custom code introduces change and moving parts.  The more inexperienced the developer, the more moving parts and likelihood of reliability and performance issues.

Often SharePoint Projects are doomed from the start because there is no budget

When SharePoint is sold as the cheapest, easiest option and all the budget is spent on hardware, or not even that, they went with the desktop or old server in the rack, it's doomed from the start.  SharePoint requires SQL, SQL requires RAM/CPU, SharePoint requires RAM/CPU and whatever other resources it can get.  Resources are very important.  These days it is not unusual to hear about Web Front Ends with 16 or 32 GB of RAM.  Not unusual to hear of people are spending as much on RAM as they are on the quad proc quad core servers they bought.  Sad but true.  The bang for the buck in these systems is in the cores and in the RAM.  I'm a fan of blades.

What happens when you run out of money?  A neglected SharePoint environment is amazingly resilient until it 1) runs out of physical resources including disk 2) passwords reset due to policies 3) some bottleneck including Disk I/O, RAM, (CPU not so much)

Oh yeah, did we forget to check the backups!!!  Is anyone doing any clean up?  How are we saving by not doing anything?  Ok, so maintenance is important.

SharePoint has a lot of new areas and still has some growing pains (Documentation and Customer Deployment Challenges and New Experiences)

So, despite the fact that we're on V3 and SharePoint is the hottest thing on the planet, we still don't know everything.  It's true we don't.  We also know it's huge, it's big, it's as complex as you make it.  It can touch everything in a datacenter and be the UI for everything as well.  These days everything from provisioning of accounts, to password resets, and managing your extranet to providing customer and sales opportunities, to providing financial forecasts.  I know I only missed a few other hundred or thousand things that it potentially could be doing for you.

This doesn't mean waiting, that's the worst thing you can do.  The best thing you can do is to get it in.  Get your IT managing it centrally, get them offering a service, get them working with your departments and start with the easy stuff.  I have the concept in my head around a real BPIO model.  A model for where a business is, and where SharePoint fits into that maturity.  If you're new to SharePoint my recommendation would be to start simple (master pages are ok), and attempt to use out of the box features before you change everything out from underneath IT.  First, this helps your IT group know what to expect OOB, and next it prepares them for what happens when things become moving parts.

When the assembly line first showed up and started making automation simple, the design wasn't to swap out the employees and make people do different parts of the job or to change the belts underneath.  It was about replaceable parts. 

You could have anything you wanted as long as it was a black Model T.  Later you could have other colors, but in the beginning it was simple, and focused.

Software quality was rated the most important service provided by IT.  If that's the case, then stabilization, change control, and learning how to support what you've got out of box before parts start changing.

Choose Your Own Adventure and Documentation

<Image removed temporarily>

(Used with Permission from CleverWorkArounds.com)

When you can do anything you want and no one can give you clear scenarios and usage examples and case studies.  (sure you can find case studies, but can you find the real use scenarios in there?  I don't think so.

The biggest challenge I've seen with TechNet documentation is the scenarios.  SharePoint is too big to be taken in one or three or five or even twenty five scenarios and be complete.  By taking a dozen or so, and trying to come up with core content we've ended up with a bit of choose your own adventure.  You run along jump down a rabbit hole and sometimes you end up coming out the other end, and other times it's a dead end.  How often do you land in the nest a trap or finding the rabbit?

I use to hold my finger in the book as I went down the choice, with browsers I open new tabs.  When I have twenty tabs, I find IE doesn't like me very much.  I usually try to stick with no more than about 10 tabs per browser and then add more browsers, but I do often get lost.  Where I end up starting back at the top or going to your favorite search engine and starting again.

So this challenge of putting together documentation based on choices is tough, but so is your own deployment.  You're going to find that your deployment is the same as many others, but also very unique the farther you go down the customization and choices rabbit hole.  What are we talking about now, Alice in Wonderland?  Then I must be the Cheshire Cat.  Smiling at your deployment and offering advice.  I'm not the Queen running around saying off with their heads... that's someone else, and if they are in your environment you're reading this here, maybe not first, but as a reminder of the reality that the Queen lives.