The focus of this posting (and more to follow), is on the questions that were asked during the webinar that went unanswered due to time.  As previously stated, there were over 100 questions asked.  I have removed those that were answered during the webinar and have in some cases merged similar and related questions together and eliminated redundant questions.  In this post I address the first 11 questions, in no particular order. So here goes:

Q:   Integrating SharePoint with ECM for archiving and/or other ECM capabilities… how many are doing this, why, what ECM capabilities are they using, and what are the technical, business, political issues that customers face in doing this?

A:  WOW, this is a loaded question – perhaps a good place to start.  The survey did not provide direct answers to each of these questions.  Based on the survey responses, however, it is fair to say that the great majority are integrating SharePoint with other systems for complementary ECM functionality. This statement is based on the fact that aside from file sharing and portal platform, respondents indicated that other SharePoint-native ECM functionality is only somewhat used or not used at all (exact percentages will be available in the report.)  Additionally, most respondents indicated that integration was a major hurdle to deployment which suggests that most SharePoint implementations involve integration – likely to some degree for complementary ECM functionality.  Based on survey ranking of SharePoint functionality (level of quality) and anecdotal evidence from speaking with users, it is safe to think that archival and records management are primary examples of the type of functionality that is integrated into SharePoint, versus the native SharePoint functionality.  As for the technical, business and political issues customers face in doing this.  Clearly those will run the gambit.  The survey did not address this matter, but in my working with various organizations I can tell you that there is no trend, other than typically one or more of these issues will be encountered.  The technical issues are many – too many to get into here.  Just recall that users pointed to integration and customization as the number one most underestimated cost and reason for project delays.  In many cases it behooves an organization that wishes to augment or complement SharePoint to seek out products that can demonstrate preexisting integration.  Business and political battles can be quasi-technical.  I have witnessed more than one company in which business desires to go “outside” SharePoint face strong opposition form IT that has declared “SharePoint or nothing” as their strategy.  There is also the possibility of having to defend why certain functions are even necessary.  Oh yes, there was one other facet to this question:  “Why do organizations undertake integrating ECM systems with SharePoint?”.  As you can imagine based on my commentary so far – not for the fun of it.  Seriously – there are usually two reasons why. 1.  because there is significant ECM legacy and there is therefore a desire to integrate it into the SharePoint emerging applications so as to avoid silos. and/or 2. While there is a desire/decision to go forward with SharePoint, certain business needs (e.g. records control) dictate that a higher level of functionality is required than that provided innately in SharePoint.

Q:  How important is it to conduct an Information Architecture design phase of Sharepoint implementation for document management and how do you know if you got it right?

A:  What I like about this question is that to a certain degree it highlights the level of naivite that exists regarding not only SharePoint but ECM in general.  SharePoint is not a panacea.  It does not provide any turnkey solutions that address all of your organizations ECM needs out of the box. So, in my opinion, it is very important to develop a strategy for its application, which should include the development of an enterprise Information Architecture.  This is true of ANY ECM system.  An Information Architecture should,as a best practice, be used as a foundation to any ECM  system, especially one that is leveraged across multiple business applications, users and repositories.  To this end SharePoint does not offer anything that any other ECM does not.  The Information Architecture is required to ensure a centralized and rationalized approach to capturing, tagging and storing content to facilitate access and findability, and in the best case drive desired end results through the aces to content.

SharePoint does not circumvent that issue with one important exception.  In some cases the introduction of an ECM system may be used as a way  to help drive user interest and generate input into a strategic deployment.  This is often the case with SharePoint because it is simple to deploy at a elementary level. (In fact the proliferation of un-managed siloed SharePoint environments is a common problem in some organizations.) in such cases it would not be critical to precede the release of these early ECM/SharePoint applications with an Information Architecture. It needs to be appreciated however, that when and if a decision is made to move forward in a more formalized and managed ECM capacity, that then the effort should be preceded by the development of an Information Architecture, for all the reasons cited above.

Q: Are you seeing a large amount of Notes to MOSS migrations?

A:  There were actually a few questions that allude to Lotus Notes.  One reason for this may be my mention of Notes twice in my presentation.  The first was early on when I stated that I had not seen such market excitement and confusion since  the advent of Lotus Notes.  The second was when I made a comment similar to: “some of the confusion stems from the fact that like Notes, back in the early 90s,  many today view SharePoint as a solution – when in reality it is a platform.  What can you do in Notes – what can you do in SharePoint/  Given enough time, budget and gumption – just about anything.” I reiterate this statement  because it relates to my answer to this question. No, I have not seen much migration of Notes applications to SharePoint.  I believe the main reason  for this is because the Notes applications that continue to exist in most organizations today are not remnants of simple file sharing applications.  They are more complex applications that have pushed the functionality of Notes using a fair degree of customization and integration to meet very specific business application needs.  Therefore migration away from them takes some serious planning. They will not likely simply port over to SharePoint. Where I do see organizations migrating from Notes, these applications are typically being migrated to high-end ECM systems.  In such cases, in evaluating SharePoint as a replacement many experience deja vu, i.e. a need to develop much functionality through extensive integration and customization, and as a result are reluctant to so so.

To a lesser degree, another reason Notes applications are not readily bieng migrated to SharePoint is that organizations that are still significantly using Notes are often IBM-centric shops, and therefore shy away form Microsoft-centric solutions.

Q:  How were survey respondents using SharePoint? In intranet deployments? Other things?

A:  This question is answered in detail in the report – so stay tuned.  Suffice to say for now that, the great majority of respondents indicated they were predominately using SharePoint as an internal portal (i.e. corporate intranet), supporting file sharing and collaboration.

Q:  Is there a reason why SharePoint is not used much for document management, BPM, Search and other Somewhat used and NOT used categories you have listed?

A:  The answer to this question lies, I believe in the relatively low grades that SharePoint functionality got concerning this type of functionality.  Aside from file sharing and internal portal development, most users of SharePoint functionality ranked the functionality performance between fair and good. In applications where such functionality is important, organizations apparently are choosing to use complementary sources.

Q: What is the difference between File Sharing and Collaboration?

A:  Technically this question is not SharePoint specific – but will get answered anyway.  File sharing is a subset or single approach to collaboration. File sharing is the ability to create a common library.  Collaboration, by definition goes beyond that to include the ability to engage in dialogue/debate, co-author content in a dynamic manner, create a social network, broadcast/communicate in real time, perform social tagging, among others.  While users point to file sharing as a strength of SharePoint, SharePoint does provide many of these other approaches to collaboration as well.

Q:  Would you define knowledge management and collaboration, as it relates to a SharePoint application?

A:  This question is similar to the one above – so is the answer. As file sharing is a subset of collaboration, collaboration is a subset of knowledge management. Knowledge management can have a technology component to it, but it is about much more than just technology.  Technology supports and facilitates a knowledge management practice. (I’ll keep this brief, as some know I can go on for pages on the tenets of knowledge management.)  Suffice to say that SharePoint is not a knowledge management system, but its functionality can be used to frame and support such a ecosystem. File sharing, collaboration, wikis, blogs, social networking and process automation are all feature of SharePomt that could be used to specifically support a knowledge management practice.

Q: Our large Government Department is using SP for Web Publishing (Internet / Intranet sites) Do you have any info (statistics) on SharePoint for Web Publishing?

A: Among survey respondents: 10% indicated that SharePoint was exclusively used in their organization for web publishing, 10% used it significantly in this capacity, 34% use it somewhat, and 47% do not use it at all for web publishing. Among the 20% that use it in this capacity, 19% ranked the functionality as very good or better, 44% ranked it has fair-poor, with the remaining 38% ranking the web publishing capabilities as good.

Q: Regarding limited use of SharePoint for external sites, was the main reason license costs? Or was it lack of existing SharePoint Internet sites to use as a best practice model?

A:  The main reason (53%) cited was security concerns.

Q:  We have heard that Sharepoint does not scale effectively for large volumes of documents. Did this also come up in the study results?

A:  Only 30% of those who responded to the survey reported having experience with scaling SharePoint. Of those, 23% reported success. The other 7% ran into problems that caused them to stop their scaling efforts. Among those that did encounter problems with scalability, the most-often cited causes were support for more complex content and greater volumes of content (59%), administration (59%) performance (47%) and supporting more complex applications (42%). (There is more detail on this in the report.

Q: Do you recommend using an archiving solution to archive SharePoint data?

A:  If archival is an important area of functionality for your organization, and the content created and or managed in SharePoint should be subjected to archival, then yes, I woud recommend integrating an archival tool to augment SharePoint.  Such functionality can be acquired in system that provide a wide array of functionality beyond archival (including products from Oracle, EMC, Autonomy,  and Opentext), or systems targeted specifically at archival (including DocAve, CommVault and Syntergy).

Please note that the products cited here are not endorsed or even recommended. They were just the first that came to mind.  Does anyone know of others – or want to share a positive or negative experience with such a product.  All comments and additions are welcomed.)

OK – enough for this post.  But stay tuned, there are many questions left that will be answered.