Customized My Sites Exposed

We recently undertook a project to develop a global intranet for a relatively large organization.  As part of the requirements of that implementation, the client wanted to create a highly customized My Site experience.  As anyone who has delved deep into My Site customization knows, it's not straightforward, easy and may create maintenance issues long term. 

Ultimately, after working through the challenges with the client, we collectively agreed to back off the more grandiose My Site customization plans in lieu of a more simple approach.  The reasons for this change centered around the following:

• Each My Site is a site collection and dealing with several thousand My Sites when need to change elements of the implementation was not something the client wanted to deal with long term
• The original plan the client had for the My Site, while useful, ultimately removed a good deal of useful functionality provided by Microsoft
• There was some concern about "upgradeablility"

So while the we didn't create the highly customized My Site, we still implemented some limited customization that delivered a custom theme, master page and some unique navigation (to tie in the rest of the portal).  We used a technique called "feature stapling" to make that happen and ensure "compatibility" with what Microsoft would like to see in SharePoint implementations.

If you're interested in a really good set of explanations of both the My Site architecture, see a blog entry from Mark Arend.  If you are looking for the best practice approach to modifying the My Sites, see the SharePoint Product Team's blog entry.

Portals: Build it and they may come, but they won't know what to do when they arrive...

Many of our customers ask how they can spur adoption of new portal technology.  In cases where the IT department is leading the charge, we see a lot of "build it and they will come" approaches.  In much the same way Kevin Costner's character in Field of Dreams built a baseball field on his farm to encourage ghosts of baseball players to visit and play the game, IT groups hope that by simply exposing portal functionality to their end users, those same users will figure out what to do with it.  The trouble is that most employees are too caught up in their daily tasks to focus on the use of yet another tool, let alone see the opportunities for making their lives easier.

Portals technologies and other "productivity" tools come and go.  There have been lots of them over the years.  The prime example would be word processing software.  Does anyone remember the resistance to computer-based word processing over a typewriter?  Does anyone remember the fights that erupted in the executive offices when word processing centers (that existed in many large companies) were replaced by a far fewer number of individual secretaries armed with tools like the DOS-based Displaywrite word processor (an IBM created word processing packages from the early to mid-80's), WordPerfect or any of the other word processing packages of that era?  Or how about when the concept of an executive doing their own typing was introduced!  <GASP!>

The difference between a word processor and a portal is the number of functions.  More than likely, anyone familiar with a typewriter can guess how a word processing package functions.  And, with minimal fiddling, could probably figure out how to type out and print a document. 

By contrast, portal technologies encompass a number of functions -- some of them not so obvious.  The fact is and remains that IT or any organization pushing the adoption of a portal product, must help their user community.  This help comes in many forms, but here are some best practices for not only helping introduce the portal, but driving usage:

1. Pick a few Functions that have broad appeal
   Find those one, two or three functions that virtually everyone in the organization needs or wants.  The old term for this is the "killer app."  Effectively it's any feature of the portal that employees will immediately see value in using and something that you can make instantly accessible.  For example. surfacing a phone directory or portions of frequently used applications -- like electronic pay stubs.  The function needs to be something that users "need" to use as opposed to something that they could use (given the imagination to integrate it into their work).  One customer we recently spoke with implemented an employee lookup feature for a single department and it's now the most utilized feature -- by everyone from the mailroom to accounting to the receptionist.   As a result, this one feature is driving usage of the more traditional functions within their portal.
   
2. Train, Train and Train -- but do it quickly
   Most organizations miss this basic concept.  They also tend to focus on "all day" or other time consuming "big bang" sessions.  Remember that the portal is supposed to improve productivity, not create a huge hole in productivity.  By taking valuable resources away from their jobs for a day or more to try and consume loads of information, you not only create a down day, but the trainees will inevitably forget everything but the phone directory by the time they leave the session.  Instead deliver training in very small information blocks that take an hour or less.  Again, if we assume that the portal starts with a few key functions, developing training for these functions to fit within an hour or less session is not all that challenging.  If the functions are too complicated to show folks how to use them in that time, rethink the function.  Further, don't stop there.  Embed ongoing "training" into the portal, such that users can get to 30 second to 1 minute "mini-training" sessions on contextual content.  For example, if your portal has the ability to manage documents, embed links to help material literally next to buttons or links for that document management function.  A firm called Portalogiks has a product called "Virtual Training Academy" that contains 60 "modules" that fit this very description.  Their flash/shockwave-based materials are 30 seconds to 4 minute videos that present focused content around one specific function of SharePoint (e.g. how to upload a document).
   
3. Communicate Frequently
   One key to adoption is frequent and useful communication with the user base.  Users tend to forget or simply don't know that the portal may house useful functions  or, in the case of SharePoint, new approaches to accomplish the same task (see our blog entry on using SharePoint Search within Office's Research function).  Again, keep the communications focused around one topic that can easily be consumed in short order by your user community.
   
4. Flagrantly Encourage Participation
   One of my former managers, Sue Hanley, used to promote the idea of "bribery" for portal users.  Effectively, the portal won't survive without an active content contributor community and a broad consumer base.  Since the challenge is really a "chicken or the egg" problem, you should consider developing programs that encourage both the consumer and contributor communities.  In spirit of bribery, creating contests with prizes or a simple "gold" star program will help motivate both groups.  What works for your organization will probably be different from other firms, so do a little research and experimentation to figure what sells -- we've seen everything from lunch in the executive dining room to additional vacation days to iPod/Zune giveaways.
   
5. Make Incremental Improvements
   For a whole host of reasons, the big bang (rolling out all features at one time) approach simply doesn't work.  By contrast, introducing a new portal with a small set of core, broadly used functions tends to get the ball rolling.  However, without continued improvement, usage will fall quickly (or simply stagnate).  Instead, ensure that the portal continues to expand and grow.  This means not only in terms of functionality, but also approach.  There's a really good chance you won't get it right first time around.  Make sure that you become comfortable with changing how and what you're doing within the portal to keep up with feedback you're getting from your user community.  We typically recommend to clients that they make changes at least once a quarter, but no more than once a month.  This keeps any improvement scoped for a successful rollout and at a comfortable "consumption" interval, such that your users are not overwhelmed by changes.
   
6. Measure and Measure Again
   Don't guess at the portal's success, make sure you establish success criteria and gather both quantitative and qualitative data.  Use this data to continually evaluate if you're hitting your goals.  As the portal matures these measures will change, but do not become complacent.

While this list contains just six best practices, they are probably the most frequently ignored.  And, obviously, these best practices represent only a segment of what you should be doing  overall.  However, from what we've observed, just doing these six things well will vastly improve your overall success.

SharePoint Conference 2008

I just finished my time at the 2008 SharePoint conference in Seattle (admittedly a little early).  By all accounts, this conference was well attended with over 3800 participants.  Keynotes at the conference were given by Bill Gates, Kurt DelBene and three-time Tour de France winner (and first non-European winner) Greg LeMond.  In addition there were a whole slew of sessions on everything from Search Server 2008, Branding SharePoint and Microsoft's latest technology acquisition search vendor Fast.

Most significantly, Microsoft made a few announcements/general statements -- some surprising and some expected:

• "Cloud" Strategy
  Microsoft is making a commitment to introduce managed SharePoint and Exchange services to a broad range of organizations.  Up to now, only firms with 5000 or more seats could participate in their managed strategy (primarily because they were testing and hadn't worked out a multi-tenant approach).  During the conference Bill Gates and Kurt DelBene (Senior Vice President, Office Business Platform Group) announced that they are introducing multi-tenant (more than one client on a "box") managed services for both Exchange and SharePoint (in addition to rolling in LiveMeeting).  Both services will also enable single sign-on, so that historical issues with multiple authentication prompts should be a thing of the past, and a provisioning workflow for both sites and users.  Ultimately, the strategy seems to create an offering where clients can get an "enterprise" experience, where users can leverage a full compliment of traditionally on-premise applications -- like Exchange, SharePoint, Live Communications Server -- through the cloud.  Based on the demo they showed it looks promising.   You can read more here.
  
• SharePoint-like Lists in SQL
  One of the more surprising announcements by Bill Gates was a suggestion that the next version of SQL may contain a SharePoint list-like construct within a table.  Taking that a step further, it may also be possible to directly link a SharePoint list to a single table!  After speaking with some of the product team members, I think this announcement was a bit premature (they appeared to cringe when reminded of what Bill had said during his keynote), but I'll be interested to see how both SQL Server and SharePoint progress in the next release.
  
• Office Online
  While the executives stopped short of saying "we're going to give you Office over the web," they hinted we could be seeing versions of some of the Office suite products being offered over the web -- in thin-client form.  Never one to shy away from a good dig, Bill Gates took aim at Google's "consumer" centric approach, offering that they're (Google's) online productivity products aren't ready for the enterprise.
  
• Visual Studio 2008 compatible Extensions for SharePoint in June
  One source of frustration is the constant marketing of VS 2008 improvements over 2005, but a complete lack of support for SharePoint projects (with the exception of workflow).  Product team members were on hand to assure everyone that the extensions are coming, with cool enhancements over the current 1.1 release for 2005.  They estimate these extensions will be available by June of this year.
  
• Fast Search Integrated with SharePoint
  What was both disappointing and encouraging, Fast has folks onsite to discuss their work to integrate with SharePoint.  The downside was that it felt more like a marketing pitch than a "real" discussion regarding how they were going to enhance SharePoint.  That said, they did demonstrate some of the key advantages of their tool, in the SharePoint context.  In addition, they demonstrated some admittedly very slick Silverlight-enabled search result/interaction controls.  They also demonstrated a search-centric personalization approach with faceted navigation that was novel, even if it was not entirely new.
  
• Browser Compatibility and Accessibility 
  This is less of an announcement and more of what should be a red-faced admission that SharePoint isn't as cross-browser compatible as anyone would have hoped, nor as accessible.  While 2007 is vastly improved over 2003, there are still pretty significant issues on both front.  In both cases, the product team assured everyone that this was a priority for vNext (Office 14/2010ish).  As a short term fix, they're pointing people to Telerik for their "upgrades" to the rich text editor, blog editor and wiki editor.  For accessibility, there's  a "toolkit" (developed with HiSoftware), to help with the accessibility aspects.
  

Beyond the announcements, the conference was full of the usual information sessions.  Microsoft seemed to have a good mix of services partners, ISVs and  Microsoft employees (both Microsoft Consulting Services and product team folks).

I was able to attend a number of sessions, but was generally dismayed at the lack of real depth or new material.  As mentioned earlier, the Fast search sessions were only slightly better than marketing pitches for their software.  Sessions on best practices rehashed the same stuff that virtually anyone in this space would know and has already heard a dozen times. If you had attended the previous SharePoint conference, it seemed like many of those sessions were repeated at this event (more than a year later).  And, in what seemed like a bizarre event, other attendees reported that in one session, two speakers began to disagree with each other during their presentation and  the talk degraded into unintelligible babble.

There were a few bright spots however.  The sessions on the new Search Server 2008 struck a nice balance between technical detail and actual usage.  Customers like EasyJet and Chesapeake Energy did a good job of relating how their SharePoint implementations progressed and the value that they received (a similar presentation by Best Buy for Business was less interesting though).  Finally, the session on the latest version of the Community pack for Wikis was quite interesting, if only to demonstrate how SharePoint can be extended beyond it core competencies, as well as the community support behind the product.

In all, the conference wasn't a waste of time, but I would have preferred better material.  I would have liked to have seen deeper material around all of the topics (in fact for developers, the Office Developers Conference earlier this year in San Jose was the place to be).   Better titles for some session would have also helped -- a sessions titled "My Content is in SharePoint, now what" sounded like it would have been about adoption or user experience, but really ended up being about securing content.  A good topic, to be sure, but poorly "branded." Finally, the best practices session is something everyone wants (the room was packed), but they should have focused more on the specific challenges in running a SharePoint implementation like: provisioning (the explosion that can occur), the challenge around taxonomy development, when to create site definitions vs. site templates, how to train users, dealing with varying levels of Office and so on.

If you were at the conference, I'd love to hear your feedback.  Like it?  Thought it was a waste of time?  Were there particular sessions that piqued your interest?

Simple SharePoint Backup Routine

Like many of our clients, Consejo uses SharePoint to collaborate -- both with our clients and amongst our employees.  As a result, it has become a critical service to maintain -- thereby making it critical from a business continuity planning perspective as well. 

Recently a number of clients have all asked the same question:  how can we easily create backups of our SharePoint sites so that we can restore them in the event of a disaster?  While there are some good backup options built into SharePoint and some commercial vendors like AvePoint that provide backup and restore solutions, there are some relatively simply approaches that will provide baseline protection in the event of a disaster.

To begin, you should really read this post from Microsoft's SharePoint Developer Documentation Team blog on the various backup mechanisms and elements that need to be protected.  The blog entry does a great job of highlighting all of the moving parts, but doesn't provide a straightforward approach to getting the basics.  What we've tried to do, below, is provide you with an easy mechanism to automate and schedule backing up SharePoint site collections.  These backups can easily be restored in the event of a disaster.   To be clear, this approach is kind of the sledge hammer approach for site collections only and may not be right for the needs of individual sites.  However, this represents the very least you should have in place for your SharePoint environment.

NOTE:  The backup process described will backup only the site collections specified in the backup routine.  As the Microsoft article suggests, there are a lot of other parts to a SharePoint environment.   When designing your complete disaster recovery/business continuity plan, please ensure you have all of your bases covered.

Identifying the Site Collections

Depending on the type of SharePoint environment you have, your complete SharePoint environment will have one or more site collections.  When using the approach illustrated in this post, you must backup each site collection separately (or include them in a single job).  In any event, you should inventory the various site collections you want included in the backup routine.  If you're unsure what collections exist, you can look them up in the Central Administration tool by going to the Applications tab and clicking on the Site Collection List option under the SharePoint Site Management category (show in figure 1-1).

Figure 1-1 The site collection list for a given SharePoint application

If the site collections that appear aren't what you expect, make sure that you've selected the right web application, using the drop down list just above and to the right of the site collection list.

If you have found the right set of collections, take note of all the ones that are important to include in your backup routine.  You'll need the URLs to each of the collections.  Because you can have multiple collections off of the same web application, SharePoint may only show a relatively URLs; make sure that you know the full-qualified URL for this backup process.

Creating and Automating the Process

To create some basic automation and logging, we're going to create a CMD file that contains all of the commands necessary to use the STSADM command-line utility to backup one or more site collections and add some basic logging to a text file.

CMD code

The code in the CMD file should contain at least the following:

@echo off
echo --------------------------------------------------------------------- >> SharePoint_backup.log
echo SharePoint Backup Began >> SharePoint_backup.log
date /t  >> sharepoint_backup.log
time /t >> sharepoint_backup.log
"c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm" -o backup -url [URL TO YOUR SITE COLLECTION] -filename [PATH TO BACKUP FILE] -overwrite >> sharepoint_backup.log
if errorlevel 0 goto finish_backup
:error
echo An error has occured and the backup did not complete properly >> sharepoint_backup.log
goto end
:finish_backup
echo The backup completed successfully >> sharepoint_backup.log
:end
echo SharePoint Backup Finished >> sharepoint_backup.log
date /t >> sharepoint_backup.log
time /t >> sharepoint_backup.log

Keep in mind that the code contains bracketed text (like [URL]).  This bracket text should be replaced with settings specific to your environment, like the URL to your site collection or the path to your backup file.

Once you've made the modifications to your specific site, save the file to a directory on your SharePoint server; keep in mind that the log file will be written to the same directory and will collect entries over time.

Before proceeding, I would recommend testing your finalized CMD file to ensure it operates as you expect.  Once it does, proceed to the next step.

Scheduling the CMD File

There are a number of ways to schedule a process to run on a server, but Windows has a built-in scheduling system that you can use for this purpose.  The service is the Windows Scheduled Tasks.  A scheduled task can be created and run on a specific period and within the context of a given user.  To create the backup scheduled task, using the following instructions:

1. Open up the Windows Control Panel
2. Click on Scheduled Tasks
3. Click on Add New Task
4. The Scheduled Task Wizard appears
   
   
   
5. Click Next
   
   
   
6. Click on the browse button and locate the CMD file you created earlier
7. Now name the task and choose the schedule as shown below
   
   
   
   
8. Click Next
9. Enter the credentials for the user that the system will use to run the task.  In this example, we're using the Administrator account, but you should choose a user with the minimum privileges necessary to complete the backup.   Keep in mind that the user must have access to both the SharePoint site collections and the file system.
   
   
10. Once you click next, the final confirmation dialog will appear; simply click Finish to schedule the job.

To confirm that the job runs as expected, you can reopen the Scheduled Tasks option in the control panel and right click on the new job.  From the context menu, pick RUN.

After you have your job scheduled, your SharePoint site collection(s) will be backed up every time the job runs.  I would recommend at least once every 24 hours.

NOTES:

1. When I developed this routine, I made the assumption that you will get a full backup on the specified site collections every time the job runs.
   
2. The backup files are overwritten every time the job runs, so if you want historical backups, you'll need to develop some process for making a copy of the resulting backup file elsewhere.  Ideally, you could move the backup file to tape or another file system once the SharePoint backup is complete.
   
3. This backup process will backup all of the data and the security settings.  In the event of a disaster, the security context may not be the same when the site is restored.  For example, the domain used by SharePoint may change in the new environment.  As a result, you'll have to set the owner of the site through Central Administration to the new user ID who will control the site.  Then, you must grant the appropriate users in the new domain access to the SharePoint site collection.  This can get complicated if you use a lot of item or container-level security (e.g. sites within a collection or lists/libraries within a site don't use inherited permissions).
   
4. The text file that holds the log entries can fill up quickly over time.  Make sure someone is reviewing that file periodically to ensure it does get too big AND that the backups are completing successfully.

I'd love to hear your feedback on this approach and/or whether this was helpful to you. 

SharePoint 2007 Service Pack Update

Microsoft has finally released the new service pack for SharePoint 2007.  The individual downloads for WSS and MOSS can be found here:

• WSS v3.0:
  http://www.microsoft.com/downloads/details.aspx?FamilyId=4191A531-A2E9-45E4-B71E-5B0B17108BD2&displaylang=en
• MOSS 2007:
  http://www.microsoft.com/downloads/details.aspx?FamilyID=ad59175c-ad6a-4027-8c2f-db25322f791b&DisplayLang=en

We will be upgrading our own servers and will post our findings shortly.

SharePoint Service Pack (SP) 1

If you haven't seen it, Microsoft recently released some information on the upcoming service pack 1 for SharePoint (both WSS and MOSS).  This new service pack not only includes a number of hot fixes for both platforms, but introduces some new functionality.   In addition to Server 2008 support, Microsoft is now officially supporting AJAX-enabled web parts.  They've also included some new STSADM commands (and who doesn't like STSADM).

Unfortunately, Microsoft has only really stated that it will be released by 2008.  Recently, Arpan Shah posted in his blog that the service pack could be released "anytime between now and Q1 of 2008."  So, for those of you waiting for your issue to be corrected or some of the new features, you now have a potentially four month window to sit patiently...

IIR/SharedInsights Portals, Collaboration and Content Management Conference

[UPDATED: 25 November 2007 - Slight flow changes to the content]

I've just returned from the IIR/SharedInsights Portals, Collaboration and Content Management conference.  While I've been speaking at this conference for a few years, this year's conference was a bit unique.  Unlike past conferences, where the vast majority of the attendees were more business oriented and "non-denominational" when it came to technology, this year's attendees were more technical and were very interested in specific technologies -- a good many of them interested in SharePoint.  It seemed that many of the attendees were either starting to implement or had implemented "phase 1," a smaller percentage were making their final decisions around what portal platform they would implement in the coming months -- almost universally, SharePoint was in the product mix, if not the chosen portal platform (hence the interest).  However, there still seemed to be a lot of basic questions about how SharePoint would fit in the enterprise.  To that end, I wanted to recommend a book written by some former colleagues of mine.  It's called Essential SharePoint 2007. 

Amazon.com: Essential SharePoint 2007: Books: Scott Jamison,Mauro Cardarelli,Susan Hanley ISBN: 0321421744 ISBN-13: 9780321421746

What makes this book somewhat unique in the space (since there are absolutely tons of book on SharePoint 2007) is that it takes a less technological route.  The book focuses on business usage more than technological implementation.  I would recommend it as good starting point for anyone interested in SharePoint -- whether or not you're technically inclined.  In addition, CMSWatch also has a number of reports which compare SharePoint to other tools in the ECM/Portal space.  These reports would also be valuable for anyone considering SharePoint.

Now, even in the SharePoint 2003 days, there was great interest in SharePoint -- organization's interest in 2007 is not really unique.  In a good majority of the cases, the Windows SharePoint Services component was and is a very big leap in accessible (easily obtained and easy to install) collaborative technology, but it is also just darn easy to use for the vast majority of typical Office users.  Contributing to this ease of use is the fact that the technology is directly integrated with Office -- even people with older versions of Office can use it (you don't have to match SharePoint's version with your Office version).  However, the 2007 version (and WSS v3) seems to have created a great deal more buzz.

From what I heard from attendees, most organizations were hoping to leverage the portal capabilities found in MOSS.  There was a slightly smaller group interested in pure team collaboration management -- project teams need a place to deposit assets and work from one "song book."  Finally, there were those groups who felt that SharePoint was almost a "blight," but needed to figure out how to manage it (my guess is that these individuals got caught in the WSS explosion that occurs in many organizations). 

If I were to identify the biggest changes/advantages, it would be in two categories: 1) expanding content management capabilities and 2) improved extensibility.  On the content management side, web content management tops the list.  This feature allows you to manage traditional web sites using SharePoint.   In addition, Microsoft has added new forms of contribution with the addition of Wiki and Blog templates.    When you add these capabilities to the business intelligence and forms processing features, Microsoft has taken SharePoint native content management function to a whole new level.

For the developer types, 2007 represents a leap forward in extensibility, where almost everything inside of SharePoint is accessible through the object model.   For example, you can write your own authentication provider, to enable SharePoint to use something other than Active Directory to authenticate users (unheard of in SharePoint 2003).  It's also now possible to easily add new interface elements to native SharePoint administrative screens using the "features" capability.

For those of you who might be interested in some of the content at the conference, IIR has posted some podcasts on their web site.   More podcasts will be posted as time goes by (include my own).  If you're interested in attending the spring conference, you can find more details on the IIR web site (you may want to wait a few days before searching around, since the current conference is still running as of 8 November).

SharePoint 2003 SP 3 Released

A new service pack has been released for both SharePoint Portal and Windows SharePoint Services (2003/v2). The KB article on the update can be found here: http://support.microsoft.com/kb/923643.

Thank you to Ian Morrish at WSSDemo for posting a link to the KB article.

Is SharePoint the "Right" Solution - Part 2

In a previous post, I described a panel that I participated in where each of three consultants presented what they liked an didn't like about SharePoint. In that post, I gave you my "likes;" in this post, I'll continue the discussion with what I think are SharePoint's disadvantages or shortcomings. While the product is quite good, there are definitely areas where it could improve -- some of those areas have more to do with the way Microsoft markets the product than the product itself; none-the-less, they are disadvantages.



SharePoint Disadvantages

• Accessible to a wide range of skill levels
  You'll notice that this particular bullet point is listed twice -- once on my "like" list and once here. The reason for it appearance here is simply this: SharePoint is almost too easy to setup, configure and use. Normally, this isn't a bad thing, but in SharePoint's case, it has led to trouble at many companies. At a recent SharedInsights conference, I had the opportunity to speak with a number of professionals who were interested in SharePoint. One of the attendees described a situation in his company where a non-technical, non-IT employee downloaded the SharePoint bits and spun up his own Windows SharePoint Services environment. The issue isn't so much about the actual instance of the WSS server as it is a matter of management; since this installation was done with out IT's knowledge, it's impossible to control and ensure operational integrity. Most of us, I'm sure, have either used a tool or created one that was widely distributed in the general population and provided great value, but did not come with the official support of a larger corporate group. These tools, if they're good, quickly become "mission critical," and a nightmare to support if something goes wrong. My own experience was with a really useful expense reporting system built in Access -- it was created in my division, but as folks from other groups saw it, they also wanted to use the same tool. In much the same way, SharePoint is like the expense reporting application -- pretty easy to use and distribute, but it can lead to headaches for groups responsible for keeping the technology lights-on as it were.
  


• Rigid architecture
  Microsoft has made great strides in providing a fairly flexible architecture that is both easy to use and able to be extended to fit individual organizational needs. Unfortunately, this flexibility isn't universal in the product. Very key areas of the tool are horrifically rigid. To make certain kinds of changes, you're required to modify, what is in effect, the based product interfaces (all of which could, as Microsoft constantly reminds us, be changed through a service release). The best example of this rigidity is the out-of-the-box interfaces for adding, editing and deleting list items. As you might already know, everything in SharePoint is a list. As such, these contributor interfaces are quite important to the product. Let's take an event list. Try scheduling an event for a time not on a 5 or 10 minute increment -- say 7:11 am/pm. Now, this may seem trivial, but I know of a baseball team that recently signed a deal with 7-11 convenience stores and now start their night games at 7:11 p.m. If that baseball team wanted to use a SharePoint event list to keep track of all of their games, they'd have to modify the out-of-the-box list item entry interface to insert additional values in the minute drop-down box or change the drop-down to a text box. Think this is an unrealistic example? Consejo just finished delivering an intranet solution, on SharePoint, for an MLB team (thankfully not the one in this example). Granted, if the solution were an Internet solution instead of an intranet solution, the team could have simply written a custom field control (great flexibility), but the out-of-the-box interfaces for these more internally facing solutions simply aren't as flexible... which brings me to my next point....
  


• Really great at too little
  I've always heard that Microsoft identifies commodity features in a space and produces products that meet 80% of those needs. While I can't take credit for this position, nor do I think it's entirely accurate, I do see the wisdom in it. SharePoint, in particular, suffers from the Jack-of-all trades problem: it isn't really good at any one thing. It's document management features aren't as good as Documentum. It's web content management features aren't as good as Ektron (or even the product it replaced -- MCMS 2002). The wiki and blog templates that ship with the product are passable, but don't compare with SocialText for wikis or Community Server for blogs. It's collaboration features and integration with Office are admirable, but you can't take content offline easily (even though Groove can). All-in-all, it's good at a bunch of things, but not great at any. As a result, I constantly run into customer needs that can't be met as well as either the customer or I would like. The counterpoint to this complaint really comes down to the sheer combination of features in a single package: if you need a good all-around product that can handle many common information worker content management (broadly) needs, SharePoint is usually a good fit -- being good at a lot is SharePoint's strength.
  


• To many partner-based solutions
  Like the first bullet in this post, I've listed the broad partner community as both as asset and a liability for SharePoint. It is true that no one software company can realistically produce a perfect solution. However, I get concerned when a product has to consistently rely on a partner community to lend features or functions not found in the base package; this usually means that customers must a) spend additional dollars to get the solution they need and 2) deal with multiple parties to support their solution (finger pointing between Microsoft and their partners has been elevated to a sport). One could certainly argue that a broad partner community is an asset, since it does give customers additional flexibility in finding the right solution through the coupling of "best of breed" features. True... this is why I'm on the fence on this one. As it stands though, Microsoft seems to market SharePoint as it's content management platform (effectively the only content management platform for Microsoft). However, there is an absolute ton of bolt-on solutions for SharePoint. They run the gamut from scorecard solutions like Alegri CIO Scorecard to work management to point solutions like Automated Well Lifecycle Solution for the Oil and Gas Industry from geniant. In addition, Microsoft (to its credit) recently released a set of "application templates" for MOSS 2007 and WSS 3.0. Each of these templates support the management of information for a given "vertical," such as a help desk, a baseball team , projects and clinical trials (there are almost 40 templates available). The trouble is that these templates are generic; just like the templates shipped with the product. If you really want to address very specific needs you need to turn to a partner like CorasWorks or Quest Software (who recently acquired Workplace Architects) for both templates and new web parts that address customer needs specifically. Ultimately, you almost always have to implement a partner product, in concert with your SharePoint implementation, to get the solution that will meet your needs. The easiest example of situation is in the search space -- I almost always recommend Mondosoft's Ontolica suite to improve search functionality.
  
  
• Inconsistent feature lifetime
  Anyone who has been working with SharePoint since the 2001 days, knows that various features have come, gone and come back again. Some examples of here today, gone tomorrow and back again are items like workflow (started in 2001, almost non-existent in 2003 and back with a vengeance in 2007), versioning (major and minor versions in 2001, only major versions in 2003 and major/minor versions reintroduced in 2007) and meta data enforcement (2001 would force meta data entry through all interfaces, 2003 only enforced meta data entry when using the web or Office interfaces, and 2007 re-introduced end-to-end meta data enforcement - albeit not as thoroughly as 2001 - controlling content meta data through workflow). As a result, customers who have implemented solutions across the three versions are whipsawed from one feature set to another -- loosing functionality and, in some cases, gaining it back again as they upgrade. Not only does this approach make it very difficult for IT to support the platform, but it creates training nightmares for end users. I can certainly sympathize with the product team at Microsoft -- it takes a great deal of effort to rebuild an entire product (as they did between 2001 and 2003) -- but you can't simply eliminate features that are useful to customers between versions; you must keep what you have and add on (unless there's a really good reason to phase out a feature).
  
  
• Microsoft’s "Go-To-Market" for Web Content Management
  Microsoft made the decision, with this version of SharePoint, to discontinue it's web content management server product, Content Management Server. In its place, it added features to SharePoint (specifically MOSS) to support web content management. Unfortunately, instead of mimicking the features provided by MCMS (or other dedicated WCM tools), they made the WCM features fit inside of what SharePoint natively understands: lists and libraries. While Microsoft can point to a number of public sites running on SharePoint, I just don't think SharePoint is the right tool for managing content in a public web site. Perhaps it's the weird URL patterns created by SharePoint (since web pages sit inside of a special document library -- a "pages" library -- every URL has "pages" in it) or changes they need to make to SharePoint to force WCM into the platform (see this blog post from Tyler Butler on the SharePoint team regarding anonymous access sites on SharePoint as an example) or the restrictions around how you can use master pages and/or themes in SharePoint (you can only have one master page per site for example) or simply the fact that navigation is really just enumerating every site in the site collection (using the site hierarchy to display the various navigation levels), the platform just doesn't really "fit" the WCM model almost every other vendor in this space uses. Being different isn't a bad thing if it works, but I don't think WCM in SharePoint works; it's close, but not totally there.

Ultimately, I must admit that I like SharePoint. I think it's a great product, despite what I perceive as its failings. The Office product team at Microsoft should be commended for producing a tool that is quite broadly useful. I would encourage anyone who hasn't used SharePoint to download the trial version of MOSS or simply install WSS on their Windows server. I think you'll be impressed with its ease of use and tight integration with Office; as a colleague of mine was famous for saying -- it just works. That said, you need to understand how you'll use the product and in what context; understanding both what SharePoint does well and what it doesn't will help you avoid a bad implementation that doesn't add value to anyone's work day.

Give me feedback. Tell me I'm wrong or simply give me more examples for either list. I would love to hear from you.