![MCj04412850000[1]](/Lists/Posts/Attachments/80/MCj044128500001_thumb_0C3B4D66.png "MCj04412850000[1]")
The Answer may be SharePoint, but Don't Forget the Questions!
One of the biggest reasons some SharePoint deployments fail is because they are "SharePoint Deployments".
People hear the buzz, and want to jump on the SharePoint bandwagon. They buy servers, attend training, install the software. Big bux are spent customizing and branding a SharePoint home page. Maybe there's a big roll-out promotion. Everybody says "Look! We've rolled out SharePoint!". And then...
Crickets.
All Dressed Up, and Nowhere to Go
But, you ask, what about all of those stories you hear about "uncontrolled growth"? People clamoring to get their own SharePoint sites? That's all true as well, but you need to consider why that is happening. In those cases, the people have a goal, and find that SharePoint is a great tool for making that goal a reality. The goal isn't to have a SharePoint site, per se. Rather the goal might be "easier document and calendar sharing", and SharePoint is used to attain it.
Simple Pleasures
Often those implementing SharePoint forget the KISS principle (Keep it Super Simple). SharePoint has a lot of great features and functions right out of the box. It is very tempting to try implementing all of them at once on the same site, sometimes even the same page. It is almost like when "desktop publishing" was made possible by Postscript laser printers. People discovered how easy it was to have a dozen fonts on a single page, and so that's what they did.
Similarly, in the early days of the web, as new features were added to web browsers, they started showing up everywhere on sites. (Does anyone remember the <Blink> tag?) And don't even get me stated on some of the early Flash-based sites. It got to the point where IBM was even poking fun at the designs in their commercials. "It's a Flaming Logo!" Why? Because we can!
The fact is, like the flaming logo, the fanciest features SharePoint has are worthless unless they are used in the service of some actual user need. For example: Assuming it is reasonably well implemented and up to date, the most used feature on any intranet is almost guaranteed to be the company phonebook or employee directory. Probably by an order of magnitude above any other function. It isn't fancy, but it is something people actually need on a regular basis.
As it turns out, SharePoint, with its personal profiles and My Sites, makes a great employee directory. :)
Form Follows Function
Of course, if all you needed was an employee directory, SharePoint would be overkill in the extreme. But put that directory in the context of a company intranet, with news and knowledge bases, collaboration and search. And here's a radical idea - Ask your users what they need first, and implement that! Maybe throw in a few things that are just for fun, like classified ads, or pictures from the company picnic. Suddenly you have a "destination" that will draw in your users and enhance the sense of community in your organization.
These are all things that could be (and often have been) done individually without SharePoint. But SharePoint gives you the tools you need to build and maintain these "applications" easily, quickly, and consistently - usually without custom code.
Now you can add your branding, and promote "Our-Net 2.0". Sure, it is a site based on SharePoint, but now you have put the horse before the cart, and given your users the tools they really need. It doesn't matter to them what the name of the technology behind the scenes is. All they care about is that you have created something that can help them do their jobs better.
Let SharePoint play Clark Kent, so you can look like the super hero.