SharePoint 2010 is not the Answer

The title of this post may be a bit surprising.  If you’re a regular reader, you know that Consejo firmly endorses SharePoint 2010 as an excellent platform upon which to build your intranet or extranet (internet sites are a different story).  However, we’ve worked with a few clients recently who seem very focused on the upgrade as a solution to their woes (mostly intranet woes).

Certainly, with every situation there’s always context.  I try not to preach to my clients (maybe a little) about why upgrading for its own sake is a bad idea.  Some may have very valid reasons for pursuing an upgrade.  Even when they don’t, many clients upgrade anyway.  However, to be clear, upgrading to the next version of anything is a bad idea if the only reason to upgrade isn’t directly attributable to platform capabilities.  SharePoint is no different.

Don’t get me wrong, SharePoint 2010 is a very robust product.  It has lots of advantages over 2007 and, if you’re a 2003 shop or an enterprise just getting started with SharePoint, I think you’ll be happy with 2010 (assuming the right implementation of course).  Further, 2010 is architecturally it is quite different from 2007 and far better at handling a more diverse set of infrastructure configurations.  It also has loads of goodies for the pedestrian user as well.  Be careful though: with all of this added capability and architectural robustness, there’s a price. 

In many ways, SharePoint 2010 is orders of magnitude more complicated to implement and not well suited for every environment (a 2007 failing as well).  There are new concepts like service applications, managed accounts, document labels, document IDs, content type hubs, external lists and a myriad of other very new and not so easily understood features.  Then there’s the idea that SharePoint can be all things to all people (e.g. a terrific web content management tool at the same time as it enables flawless document collaboration); it’s just not true.   SharePoint is good at a lot of things, but it’s not great or even capable at many more.

That said, clients, especially those in IT departments, seemed to be very taken with this new version.  Often they extol the virtues of managed metadata, better search, high count thresholds for document libraries, remote blob storage (eyes glaze on their business clients at this point) and better manageability (along with the other good stuff).  They heartedly recommend the upgrade to their business user clients and/or they simply say “if you don’t like your current intranet, blame SharePoint 2007; upgrading to 2010 will fix all of your problems and make you much happier.”  Inside of many clients, IT “owns” the intranet and issues an edict that they’re upgrading to 2010.  Worst yet, business users occasionally know that SharePoint powers their intranet and may have come to the potentially erroneous conclusion that SharePoint is the cause of their information management pain; this add further pressure to upgrade.

Honestly though, haven’t we all heard this before?  Wasn’t one of the arguments for SharePoint 2003 or 2007 that “the platform will fix all of your problems?”  Didn’t they (the ones pushing the upgrade) once tell you that SharePoint has loads of features you can use straight out of the box?  Even if part or all of the story was true, didn’t the move and/or upgrade cause you pain?  Don’t you and/or your colleagues, in some ways, have more complexity in your environment, more to manage and, potentially, more dissatisfaction with the intranet?  I suspect that at least some of you will answer “YES!!!” 

As yourself why.  Go ahead…. ask.

I suspect the answer is partially due to infatuation – SharePoint seemed (and seems) really fabulous (especially when that nice Technical Specialist from Microsoft showed you the Contoso Intranet or you attended an Strategy Briefing at a Microsoft Technology Center).  It’s also likely that you had a pretty broken intranet or a severe file-sharing problem.  Or could it have been that your organization had no previous mechanism for allowing various global business groups to share and collaboratively develop content together (save perhaps through very silly and uncontrolled file shares).  SharePoint seemed like it could work.  It seemed like “it” was simply the answer.

In practice, you now realize how much you didn’t know.  This is true for most things.  Martin White, of Intranet Focus, once quipped that “SharePoint demonstrated that most organizations didn’t know they had an information management problem because they never managed information before SharePoint.”  Once SharePoint was running, information management may have seemed even more out of control and users, in some ways, were even more dissatisfied.  This brings me back to my original point.  SharePoint 2010 is very likely not the answer to your intranet woes UNLESS you have very specific business requirements that can’t be immediately met with SharePoint 2007 (and potentially some combination of 3rd party tools); the new version is different, but it is still largely targeted at solving the same kinds of problems.

I’m not suggesting you shouldn’t upgrade.  In fact, if you can demonstrate that 2010 will actually solve your challenges in a way that 2007 and ISV products can’t, I would encourage you to upgrade.  We have a few clients that fall into this category and they’ve taken a very prescriptive approach to the effort.  Unfortunately, for most enterprises, this isn’t the case.

Here a few unjustified reasons I’ve heard for the upgrade and how I would (and have) respond:

• SharePoint 2010 has a better search engine and our search stinks
  I hear this a lot.  This is also the same argument, phrased differently, where search is generally the solution to findability.  Search is not the exclusive solution to findability and upgrading to 2010 (or, even better, 2010 and FAST) won’t help.    In many cases, organizations haven’t done the bare minimum to fix search with the tool they have.  This would include adding metadata (as basic as descriptive titles), creating a proper taxonomy, removed erroneous results from the index, created scopes, leverage pre-canned searches, gotten rid of outdated/irrelevant content or even provided search education to their end users (yes you need a little guidance to use search properly just like any tool).  Improve search first, upgrade later.
• SharePoint’s interface is hard to use; SharePoint 2010’s is better
  It’s true that Microsoft has radically changed the user experience for SharePoint 2010.  My colleague, Tony Byrne at Real Story Group, though questions whether the changes in SharePoint’s interfaces are really all for the better.  Even veteran users of SharePoint find the new ribbon challenging, much like the ribbon in Office.  Further, AJAX has made some interface more modern (and somewhat more reactive), much of what makes SharePoint, well SharePoint, is still very apparent.  You’ll also notice that there are still some exclusively IE features (though more compatible with Firefox and Safari), there are loads of forms for uploading things, the interface is still decidedly “SharePointy” and while you can create a theme in PowerPoint 2010, I’m not sure I would.  Good interface design should be handled by a professional designer and a good developer.  Also, end users are still going to need training (still).  You could/can create compelling interfaces in SharePoint 2007 and the approach isn’t much different in 2010.
• We don’t want to be too far behind Microsoft’s development cycle
  I get it.  You don’t want to be stuck on the equivalent of Windows XP ten years after it first shipped.  This is a valid concern.  However, SharePoint 2010 shipped less than a year ago.  Lots of organizations are still successfully using Office 2003 or 2007, as well as Windows XP.  To be fair, it’s far more difficult to upgrade 10,000 client workstations than a few servers and I don’t think there are very many people outside of Redmond that would defend Windows Vista.  However, the “old technology” argument only gets you so far.  SharePoint 2007 is very much still technologically current relative to Office deployments (though perhaps not too “Web 2.0”).  It fully supports the more recent versions of .NET and you can absolutely find vendors who support the platform with add-on products.  If this were February or August 2012, the argument works far better.  I’d also like to bring up my previous point about search.  Like search, few organizations really spent time or money on customized user experiences for their intranet or fully developed a true application on SharePoint.  They expected business users to simply use what Microsoft provided (more of the “build it and they will come” mentality).  In some cases this worked.  Mostly, collaborative sites experienced uncontrolled growth (causing much of the information management pain) and the larger intranet application languished unloved and underutilized.  This argument is a fallacy from the beginning and shouldn’t be considered a truly valid reason, unless perhaps you’re using IBM Displaywrite 4 (you could probably benefit from the upgrade to WordPerfect 5.1).
• We’ve already paid for the upgrade through our Enterprise Agreement with Microsoft
  This too sounds pretty reasonable on the face of it.  Your EA provides you with the ability to upgrade to the latest version of any included product; why not upgrade?  The reality is that unless you’re not going to renew your agreement during the next cycle, you’ll continue to pay regardless of what version you’re using.    It’s not going to cost you any more or less to stay put on SharePoint 2007 for a while longer (especially if you need to “fix” some of the more serious problems with your intranet).  In the end this argument is just a red herring to distract from the core issue at hand: your intranet doesn’t work for your employees.
• We have too many 3rd party tools for our SharePoint 2007 implementation; SharePoint 2010 provides [insert vendor here]’s functionality out of the box
  Really? I’d double check.  What appears, in some cases, like Microsoft may have covered a previously missing feature, they may not have completely covered it.  For example, metadata.  Microsoft implemented a new managed metadata service that goes a long way to helping enterprises implement a proper metadata scheme within their intranet.  The existence of the service would seem to eliminate the need for tools from companies like SchemaLogic, Smartlogic and more utility-like components from firms like Bamboo Solutions and Layer2.  However, these and other vendors not only appear to have a solid business for SharePoint 2010, they’ve found new opportunities.  If anything, the explosion in add-on products compatible with SharePoint 2010 would anecdotally suggest that SharePoint 2010 continues to have functional gaps.  In truth, there’s probably a better story for ISVs, not because SharePoint has gotten worse, but the platform improvements give these ISVs a far better foundation for valuable add-ons.  Do your homework and don’t get sucked in by good marketing.

Look, I’m on your side.  I love new stuff – especially that new DVD/download smell.  However, distracting everyone from the real problems plaguing your intranet by upgrading to SharePoint 2010 isn’t going to be productive.  An upgrade will likely not fix the real concerns people have about your intranet, nor will the upgrade process be satisfying.  In fact, upgrades usually tend to be migrations; painful, painful migrations.  You aren’t just replacing binaries on the existing servers and manipulating the content database schema.  “Upgrade” usually involves building brand new servers, buying more storage (get it while the gettin’s good), installing a net-new SharePoint farm, licensing brand new add-ons (yes there are still plenty of “opportunities”), licensing/using a migration tool (please don’t try it manually) to move content to the new farm and sending the IT team to training on the new stuff (developers as well as administrators).   Again, when all is said and done, core problems are probably still not addressed, nor have users significantly altered the behavior that lead to this “bad” place; there was simply too much to do getting the “upgrade” done.

In the end: fix what you have.  Get it right now, before you upgrade.  Prove it with real measures of success, then upgrade.  You’ll be happier.

Nielsen/Norman Group’s 10 Best Intranets of 2010

Welcome to 2010!  I hope you had a fantastic new year! 

To start this year on a high note, I wanted to highlight Nielsen/Norman Group’s yearly 10 Best Intranets.   The 2010 edition, like past reports, provides insights into some of the best intranets across organizations of various sizes, shapes and industries.  What I like best about the report (as well as report’s like Jane McConnell’s Global Intranet Trends Report) is the chance to see how different organizations take on the challenge of improving employee productivity through content technologies.

Here are the some of the highlights I discovered:

• Intranets are getting a higher priority in the enterprise
  Better technology is enabling organization’s to produce better intranets.  NNG also notes the average increase in the size on intranet teams, giving enterprises more resources to produce and maintain these applications; in fact, the average team increased 27% to 14 people from 2009.  In Consejo’s own work, we have seen an increased focus on intranets across all of our clients; this is especially true of organization’s leveraging SharePoint, as much of those implementations involve internally facing applications.
  
• Mobile continues to garner attention
  It’s far from a widely adopted feature, but mobile access is becoming increasingly important.  Of the surveyed companies, 30% had special mobile features.  NNG made a specific point about creating unique mobile experiences instead of merely trying to adapt an existing intranet design to a mobile device.  For example, one of our clients built a specific Windows Mobile application to download list items from SharePoint.  NNG cites another client that built an iPhone app for their intranet.
  
• Social features gain real traction
  NNG called it the “year of social networking.”  Previously, NNG cautioned organizations about using the word “social” and many of our own clients refuse even use the word; one client prefers to use words like “collaborative” or “interactive” in lieu of social to avoid executive confusion with sites like Facebook.   However, as NNG points out, this trend is reversing and social media (as well as features) is gaining credibility.  For more insight into this area, take a look at the CMS Watch report on Enterprise Collaboration and Community Software.
  
• CEO Blogs
  NNG highlights that the typical “boss blog” is getting a bit of a “face lift.”  Instead of the monolithic and “talk at you” approach of historical executive blogs, more organizations are, in NNG’s words, “show[ing] executives with a ‘human face’ and [helping to] make them more approachable.”    Toby Ward at Prescient Digital wrote a terrific blog article on the “8 ingredients of a great  executive blog, ” which summarizes some of the same themes NNG found in their research, specifically the inclusion of social media and audience engagement (like comments).
  
• Focus on usability and improving features
  This point is a bit of an interpretation on my part, but NNG cites changes in the ways that organizations are encouraging use.  There’s less of the “built it and they will come” approach and more explicit, upfront research on usability and needs.  At Consejo, we typically encourage our clients to conduct surveys and in-person interviews to ensure the newly designed  intranet creates and improves productivity, as well as reducing the frustration that often accompanies change.  We also use that data to evaluate overall success of the intranet post launch, in addition to conducting post-launch surveys.
  
• Continue quality improvement
  A trend that should simply be “par for the course,” NNG cites efforts that many enterprises are taking to improve the quality of their intranets.  Interestingly (at least for a consulting firm that focuses on SharePoint) is that “frequent use of SharePoint” was the first bullet under this heading.  NNG does note that “many other technology platforms were common as well [and that] no one solution guarantees a great intranet,” but I thought it was an interesting point (especially since half of the “winning” intranets in 2009 ran on SharePoint).  As the SharePoint Report 2009 from CMS Watch points out and what we’ve learned through our SharePoint Fast Track offering, collaborative applications like Intranets are definitely a strength of SharePoint; NNG continues to reinforce this idea through their research.  Beyond SharePoint, NNG points out that search continues to be a problem (though improving), editorial workflow is more extensively used to ensure content quality, more organizations are using role-based personalization (as well as personal customization), companies are waking up to the idea that you need to measure success (Trend Micro saved $1.6 MM) and more intranets are creating consistent presentation through the use of page templates (something WCM and portal tools have long included).  All of these trends add up to a vastly different intranet and improved experience.

As 2010 offers fresh opportunities for enterprises to further improve their intranets, it will be interesting to see how the old trends continue and what new trends emerge.  And, while we have seen both successful and unsuccessful intranets in many different kinds of organizations, it’s gratifying to see the progress being made.

We wish all of our clients and potential clients a prosperous new year!  May your intranets bloom!

Finally! Intranet Success Measures Everyone can Understand

Many of our clients truly want their intranet to be successful.  However, when we bring up the topic of how they measure success, they often respond that metrics are too hard to capture or that they really don’t understand what success means.  In his latest blog entry, intranet guru Toby Ward discusses the top 5 key performance indicators (KPIs) for company intranets.  Toby cites specific examples and references you can use when creating your success criteria.

I would highly recommend checking out this blog entry and creating your own metrics.

Make SharePoint Governance Plain and Simple

Much has been written on the topic of SharePoint governance (and just to satisfy the Bing lovers: SharePoint governance).  Microsoft even has a Governance Resource Center for SharePoint on their TechNet site.  While most of the content I’ve found is quite good, though a bit fragmented, I still felt like there was something missing.

In fact, all of the discussions around governance got me thinking about the idea that you should be able to create a model where governance just “happened.”  Before you go away thinking that I’ve spent a bit too much time inhaling paint fumes, hear me out:  is it possible  to create a self sustaining “culture” of governance where participants reinforce content and technology best practices because “that’s the way we do business?”  I think the answer is: YES.

Recently, I’ve had the opportunity to work with a number of older companies – companies for whom computing technology is relatively new compared with their years in business.  Many of these older companies, especially those with a strong founder affinity, have a deeply engrained company culture.  This culture is so pervasive that it permeates virtually everything they do without being overbearing.  

I’m not speaking of the largely manufactured “culture” we saw sprout during the dot com days; that’s the kind of culture that never leaves any lasting impression beyond a few hollow words by an executive.  I’m speaking of , the real ingrained and consuming kind of culture.    Examples can be found in companies like GE, Caterpillar, Kiewit and the “old” IBM (somewhat paradoxically specifically because they’re a technology company).  These companies have a “way of doing business” and new employees quickly learn this “way” by having it reinforced by the processes and people around them.

Another such culturally rich company is PCL Constructors Inc.  They’re based in Edmonton, Alberta, Canada.  PCL’s founder, Ernest Poole, created a memo that’s now called “Pooles Rules.”  At the time of its creation, it created the basis for a company culture, PCL’s business practices and values.  Even today, the words of Mr. Poole are displayed throughout their headquarters and guide the companies business practices. 

What struck me about the rules was the plain and simple language used to describe “how to do business.”  These rules can be applied to a broad set of circumstances, even ones that couldn’t have been anticipated by Poole himself.  Today, while the language may seem “old,” the concepts and guidelines haven’t gone out of style and PCLers still largely operate using the insight that Mr. Poole jotted down on a single piece of company letterhead nearly 70 years ago.

To demonstrate just how applicable the rules are, I’ve created a derivative work that could be used as a basis for a SharePoint governance “culture.”  I’ve replaced certain words in Poole’s Rules with more SharePoint or portal-relevant terms (if necessary). 

• Employ highest grade employees obtainable
  SharePoint is a unique product with it’s own complexities and nuances.  I’ve seen some companies try to “fit” employees into a SharePoint administration role or use less-experienced resources to create solutions.  Just as Mr. Poole suggests using the highest grade employees to build a building, you should strongly consider the same approach for your SharePoint environment.   Frankly this rule is just good business and common sense.
• Encourage integrity, loyalty and efficiencies
  Create an environment where your content consumers and contributors see the SharePoint solution as central to their work.  This means avoid “snazzy” features for their own sake and instead focus on real time-saving or productivity-improving functions.  These functions don’t have to be complicated and can be simply a good employee directory or the place to find the right template for proposals.  By considering the time your users will invest in learning the new SharePoint solution and leveraging any given function, you’ll avoid overloading them with frivolous content or features – this builds loyalty, trust and a sense that the SharePoint application is meant to improve efficiency, not make it harder to get work done.  Further, employees won’t try to use “rogue” applications to get their work done, since you’ve demonstrated real value.
• Avoid side lines
  Don’t try to make your SharePoint environment be all things to all people.  As I’ve mentioned in the past, SharePoint has strengths and weaknesses.  Make sure you know what they are and avoid trying to make SharePoint do something it wasn’t meant to handle.  It’s better to do a few thing well than create a broad, mediocre application.
• Do not permit side lines by employees [or SharePoint environments]
  Don’t allow rogue SharePoint implementations in your environment; more than one organization I’ve worked with suffers this problem.  Multiple, unmanaged SharePoint environments cause lots of pain in the organization and confuse the general employee population.  I would highly recommend working to create a tightly controlled, singular (or set of SharePoint) environment(s) that can be relied on, supported and recovered (in the of a disaster).  The idea is not to create a uber-SharePoint group, but rather apply real discipline to the management of the environment, even if more than one group physically operates an environment.
• Be fair in all dealings with owners [content contributors and consumers], architects [SharePoint managers], engineers [internal SharePoint developers] and sub-contractors [consultants]
  The critical bit of  the initial deployment as well as long term application management is to understand there are lots of individuals, groups and interests involved.  You will do well to develop very clear goals for your environment, a plan to achieve the goals and metrics to measure success.  In addition, communicate constantly with everyone involved.  How does this equate to fairness?  In the end, no one group can bear the brunt of the development or maintenance.  Your contributors can’t be expected to create content over night, managers can be expected to solve “world hunger,” it should be understood that it will take more than 24 hours to design/develop/test/deploy a SharePoint solution and any consultants you hire don’t know your business as well as you do.  In addition, you need to make the environment accessible and easy to use for your content consumers.  Try to minimize overburdening one group or another when developing and maintaining your solution.
• Keep your word as good as your bond
  This is about credibility.  If you (as the “owner” of the Intranet) want to encourage use,  make sure you deliver what you promise and what is useful.  This means not only delivering the obvious – SharePoint functions and the environment – but also the ongoing content contribution, continuous improvements and overall management.  Living web applications – whether their internally or externally facing --  need to be cared for and “fed” to survive.  Once you’ve built your solution, you or another group must be responsible for keeping your implied promise that the solution won’t be abandoned.
• Give encouragement and show appreciation
  I had the good fortune of working for knowledge management guru Susan Hanley while at Dell.  She was famous for saying that organizations should use techniques like “bribery” to create a vibrant community of content consumers and contributors to build up an intranet.  In fact, as she often pointed out, without both communities, a intranet will wither and die away.  Providing encouragement and showing appreciation is especially important for fledgling SharePoint environments; participation and adoption are paramount to success.  It’s also critical for ongoing success; consider your own population and develop a program that continuously provides encouragement and support to all communities involved.
• Be firm, fair and friendly
  Think outside the box, encourage suggestions and get folks involved.   Improvements or changes can come from all levels in the organization.  Treat all who participate as if they can constructively contribute to the environment.  However, it’s also equally important to set firm ground rules for that participation and refuse some requests if they’re either unreasonable or don’t fit the “model” you and your team have developed for the application.  See the “avoid sidelines” rule.
• Avoid jobs where design is not good or financing doubtful
  If you don’t have the funding, time, human resources or the budget to effectively create, deploy and maintain a SharePoint solution, don’t start one.  I have seen numerous companies attempt to develop a solution with insufficient resources, thinking “it’s just a simple intranet” or “SharePoint does that out of the box.”  There is nothing simple about an intranet and while SharePoint does provide a lot of out of the box functionality, more enterprises must buy add-ons, build customizations and deal with challenges that are often underappreciated.
• Good accounting and cash keeping are essential [Develop good metrics for success]
• Do not let finishing up of jobs or collecting payments lag
  These last two bullets are close enough to lump them together.  In construction, like developing a SharePoint solution, demonstrating success is critical.  How do you demonstrate success?  You have objective measure to compare against.  Whether this means that the new application supports a certain number of users, that it helps to reduce the time it takes to accomplish a task or eliminates work altogether, you have to be able to measure it.  Many organizations say that it’s impossible to measure productivity improvements or more “soft” metrics. I would agree that it’s very difficult in many cases to determine whether process improvements have saved time, for example; often you don’t have a baseline to compare against or it’s difficult to gather ongoing data.  However, even anecdotes can serve as a metric (e.g. here’s an example of how I save time generating a proposal using the new intranet).  Further, stay on top of these measures of success both throughout the initial deployment and the applications lifecycle.  It’s the only real way of figuring out whether all the time, money and effort paid off.

Keep in mind that I’m not necessarily endorsing this specific approach for everyone.  However, I think it’s an interesting model to explore when developing a governance program for a SharePoint environment.  Obviously, a good governance has to include more than just a few rules.  That said, writing this blog entry, for me, has only reinforced that there is an argument for creating a relatively broad set of guidelines that can apply across numerous circumstances.  Many companies fail to realize this and end up creating an inaccessible, overly complex governance policy.  In the end, their policy fails because no one understands it or it is too hard to follow. 

Consider creating your own “Poole’s Rules” for your SharePoint environment.  I suspect you’ll not only gain new insight on a practical governance strategy, but also end up creating something that outlives SharePoint.

Create a Support Program for your SharePoint Environment

A recent article in CIO Magazine provided some great content around the true cost of SharePoint.  Social software and portals expert, Peter Sejersen from J Boye, has expanded that discussion when he added a quick case study of a DIY SharePoint implementation at the municipality of Aalborg in Denmark.  However, one dimension of SharePoint that has not received a lot of attention is support.

In virtually every engagement we have with clients, the cost of supporting SharePoint comes up.   Clients want to better understand what it takes to “care and feed” for an enterprise SharePoint environment.  If you’re struggling with this same challenge, I’ve included some of the various support dimensions touched lightly in the CIO article and that may help you create your support program:

• Monitoring
  Do you want to get the most value out of SharePoint?  Make sure you monitor the servers, the applications and ensure up-time.  During your implementation’s early stages, little attention will be paid if it’s unavailable.  Once the site has been around a while, you better ensure it’s running in top form.  Beyond that, you should really know if errors are being generated in the event logs, issues manifesting themselves in the SharePoint logs or if your content databases are getting to large.  This means that you must get serious about monitoring and look at more than just ping responses.  Microsoft has System Center Operations Manager, which provides a good tool for monitoring your environment.  You can also leverage a combination of event log monitors, perfmon or manual checks.  At Consejo, we developed a monitoring agent with Panopta and integrated it into our SharePoint Support offering.   Whatever approach you choose, make sure you have one.
• Patch Management
  The SharePoint team releases patches with relative frequency.  They are sometimes in the form of a “hot fix” (an update the corrects a “small” feature or function within SharePoint), a roll-up (a collection of these hot fixes) or a service pack (the total collection of hot fixes plus updates not found in any hot fix).  Whatever the form, you need to have a program to apply them regularly, since you don’t necessarily want to update SharePoint the way you update the OS.  While you may have a program for applying fixes to your server and desktop OS, a lot of organizations fail to regularly implement SharePoint-specific fixes – some of which are required for working with certain OS and/or .NET framework patch levels.    The tricky bit about this element of  a support program is the number dependencies created by either custom or commercial add-ons; this means testing ahead of deployment.
• Reusable Components
  Companies like Telerik and Infragistics have made a good business out of creating new controls or components that fill in functional gaps between what Microsoft provides in the .NET framework and what you may have to create for your application.  In the same way, consider creating an organization specific set of controls, components or SharePoint add-ons that you can reuse across your SharePoint applications.   Examples of this might be a “print Wiki” function that can be used with any wiki in SharePoint or SharePoint site archive function that backs up a SharePoint site before deleting it from a Site Collection.    More granular examples may be components that make it easy for developers to connect to your specific SAP implementation.  While your needs may be different, creating a collection of reusable components will help improve development quality and speed within your organization.
• End-user Assistance/Help
  A lot of IT organizations tend to take the “build it and they will come” approach to SharePoint.  This approach suggests that IT organizations simply need to make a facility like SharePoint available; from there business users will “figure out” how to be more productive.  Unfortunately, most end users are unable to conceptualize how SharePoint can help them to be more productive as they tend to struggle with the basics like simply uploading documents or using search.  Instead, enterprises should create real training materials that translate SharePoint capabilities into tangible benefits in the context of the business.  This means demonstrating how users can be more productive in real situations using SharePoint to supplement or replace tools they already uses – like Word (just as an example).   When we deliver our Fast Track to SharePoint solution, we provide a license for the SoftwareFx Virtual Training Center for SharePoint (created by PortaLogiks) and embed them in the SharePoint application we create for our clients.   The materials give end users 30 second to 4 minute flash-based narrated videos on everything from uploading a document to a document library to customizing a page with SharePoint Designer.  Along with these materials, we typically recommend clients create application-specific help material that will further supplement the rather generic videos with specific information on their implementation.  In this way, business users don’t have to “imagine” how they can be more efficient -- they’re shown.   This will encourage use and help with adoption.
• Be Serious about Adoption
  Another frequent topic of conversation is end user adoption.  Adoption describes how you get your business users to utilize the new intranet, extranet or internet site you’ve built on SharePoint.   There are no easy answers to help to spur adoption; each organization will need to create a specific program to fit their end-user community.  However, success of your SharePoint implementation will depend entirely on end user adoption.   If you’re interested in learning more, check out a blog entry by Bianca Wong at Prescient Digital Media on change management strategies to support intranet adoption.

Admittedly, creating your own support program will be specific to your organization.   It also likely you’re doing some related activities already, so adding SharePoint-specific elements to those existing programs should not burdensome.  However, consider the alternative costs if you avoid creating a disaster recovery program or skimp on training your users.

SharePoint Summit 2009 Recap

I have just returned from a fantastic trip to Montreal for the SharePoint Summit, where I taught one tutorial on making SharePoint work in the Enterprise and one regular session on Web 2.0 and SharePoint.    The sessions were very well attended (partially to my surprise) and I really enjoyed seeing a different side to SharePoint implementations – in the U.S., Consejo tends to see more commercial organizations and, while there were definitely a number of folks from commerical organizations, I saw quite a few Canadian governmental agencies represented as well.

Overwhelmingly, the questions about SharePoint remain largely consistent with the U.S.

1. What does SharePoint do well and where does it falter? 
   The answer to this question really depends on your needs.  I saw quite a few organizations who needed records management, for example.  However, as readers of CMS Watch’s SharePoint Report 2009 know, SharePoint does not have any real depth in records management; if that’s what you need, you should probably look elsewhere or find an add-on to improve SharePoint’s RM capabilities.  Beyond that (and imagining), SharePoint is a pretty mediocre player.  However, Mike Fitzmaurice  from Nintex (and his Microsoft days), made an interesting point: SharePoint doesn’t have to be the best at any one thing as long as it’s pretty good at a lot of things; partners, organizations or even Microsoft can add point capabilities to supplement what SharePoint does natively and cover a good deal of what organizations need to accomplish.  Interestingly, Mike made his point with a little “presentation zen,” by showing images that represented examples of the “best” animals in specific categories (e.g. Cheetah’s are the fastest land animals, the Bull Elephant is the strongest , a specific species of Shark is the fastest sea creature) and then comparing those “best of breed” animals to a human with a tool.  Obviously an elephant could lift, literally, a ton.  However, a human with a crane can best the elephant.
   
2. How do I control (govern) SharePoint in my environment? 
   This is something that I had the opportunity to give a keynote on during the conference.  I’ve also written a little about governance in the SharePoint Report 2009 and on SearchWinIt, in my article “Four steps to creating practical SharePoint governance standard.”  However, the short answer (if you don’t want to read the source material) is really about establishing “how” to use SharePoint within your organization.  Microsoft gave administrators some tools to limit growth or unused sites, but the tool won’t solve any real governance problems or create your policies.  Good governance has to be an explicit effort on your part.  You must actively engage in a process of policy creation and education to ensure your success.
   
3. Do I have to buy add-ons to SharePoint and/or why doesn’t Microsoft handle “this” out of the box?
   The answers to these questions are: “probably” and “by design.”  More often than not, organizations will have to buy/build/download add-on components to supplement SharePoint.  This isn’t necessarily a bad thing; Microsoft could not be expected to anticipate every need or “solve” any specific requirement in a way that all organizations may require.  In fact, as Mike pointed out, Microsoft explicitly excludes certain features and/or components by design.  Mike shared that even Microsoft does not have inifinite resoures and when deciding on what features end up in a version of the product and which don’t, the product team focuses on “platform functionality” over “improvements to the UI or scenario specific” features.  The expectation is that partners, consultants or customers will fill in the gaps.  This approach doesn’t work for every customer, so be clear about your own goals and how much you’re willing to accept with regard to “missing” functionality and/or capability.
   
4. What’s in the vNext of SharePoint?
   Only the Microsoft product team knows for sure.  However, what I did hear from people in the know is that Office 14 (the version number of the next release) will be largely evolutionary with some slightly cooler, but not revolutionary components.  The one caution I will provide is that point 3 (above) still holds true; don’t expect Microsoft to cover every base and you should still budget for consulting and add-on products in your implementation.

Beyond all of the points I’ve made here, SharePoint is one of the fastest growing portal products on the market.  There were over 300 attendees at the conference and, universally, everyone was legitimately interested in better understanding SharePoint – primarily because they had all committed to using the platform for some web-based application within the enterprise.  I’m excited to see what’s coming in the next release and encouraged by the excitement I saw at the summit. 

Customizing a SharePoint Site's Visual Design

One of the common questions we get from clients is "how do I apply a custom design to my SharePoint site?"  While SharePoint's interface is relatively clean, it has the ubiquitous "SharePoint Look."  Most clients want to make their sites match their brand, palette and navigational style.  However, it's not always easy to figure out the various elements that need to change.

To that end, here's a short list of options for changing SharePoint's look into something more complimentary to your brand:

1. Custom SharePoint Theme
   A Theme, in SharePoint terms, is like a fresh coat of paint over the existing SharePoint interface.  A Theme is driven exclusively by a series of CSS files located on the file system (in the "12 Hive").  The best custom themes simply override styles that can be found in the various CSS files that accompany the SharePoint software, like CORE.CSS.  The advantage to a custom Theme is that it takes very little to create some dramatically different interface styles; since so much of SharePoint's interface is CSS drive (to its credit), you can do quite a lot by simply changing the theme.  The easiest way to create your own theme is to copy an existing one (located in X:\program files\common files\microsoft shared\web server extensions\12\template\themes where X is your SharePoint installation drive).  Once you've copied the directory, renamed it, updated the included CSS and added your images, just modify the THEMES.INF to point to your new custom theme.  If you'd like detailed instructions, take a look at this MSDN article.
   
   
   Figure 1 - List of Themes included with SharePoint
   
2. Custom Master Page(s)
   In the .NET v2.0 timeframe, Microsoft introduced a concept called a "master page."  A Master Page, in SharePoint vernacular, represents all of the common elements of pages that share that Master Page.  Using an overloaded term, "template" might best describe at least part of the concept.  While Master Pages don't represent that entirety of the visual design, they establish the major elements and then determine where variable elements of a page can be placed.  By using "container objects," called placeholders (another overloaded term), Master Pages can establish the interface framework without interfering in a specific implementation.  Using various Master Pages with the same Page Layout (more on that shortly), you can produce vastly different looking sites.  In fact, SharePoint (MOSS) comes pre-loaded with several master page examples (mostly with names including "band" in them).   If you currently have a publishing enabled MOSS site (collaboration portal, News site or Publishing portal are the standard ones that enable this feature by default), you can change your master page in Site Settings.  There you'll have the option of choosing between various pre-installed Master Pages for both the Site Master Page and the System Master page.  In addition, you can create your own custom Master Page to introduce a radically different look.   If you are using WSS or don't have the publishing feature enabled, you can still use different Master Pages.  However, you'll either have to write a small utility to change the Master Page or you can download an open source extension to SharePoint from CodePlex to assist you in changing your master page (among other visual design elements).  Microsoft published a short article on customizing master pages on their MSDN site.  Remember though, you can have many Master Pages defined in your SharePoint site collection, but you can only use one Master Page per SharePoint site (unlike a traditional ASP.NET application).
   
   Figure 2 - Option in Site Settings for changing Master Page
   
3. Creating Custom Page Layouts
   Page Layouts, like Master Pages, were released as a part of the .NET v2.0 framework.  They are used in conjunction with Master Pages to create the overall visual design of a SharePoint site.  Page Layouts define what content will be placed into placeholders defined by the Master Page.  SharePoint ships with a number of different layouts.  By default, selectable Page Layouts are only available when using a publishing enabled site; you can choose a specific Page Layout for other SharePoint-types.  However, if you are using a publishing-enabled site, you can further refine your SharePoint site's look by leveraging customized Page Layouts.  Just keep in mind that Master Pages and Page Layouts are pretty tied together; if you create a Page Layout that uses placeholders from a customized Master Page, that Page Layout may not be "compatible" with out-of-the-box layouts.  For more information on creating Page Layouts, see this MS Office article.

In many cases, organizations will need to leverage more than one of these techniques to create the look they desire.    The specific technique will largely depend on how different you want your SharePoint site to look.

Once you've completed your changes, the best way to "install" the new, customized look, is through a SharePoint Feature.  A feature can provision all of the files involved in the customizations and programmatically enable them on one or more sites within the site collection.  The advantage to this approach is that by activating or deactivating the feature, the customized look can be enabled or disabled without vastly affecting the function of the site; this approach is also the way Microsoft recommends making changes to your SharePoint site.

Now, if all of this is too much to take in, or if you just need some help, Consejo has recently created a new SharePoint Branding Fast Track offering.  This offering is meant to help organizations quickly develop a customized the look and feel for their SharePoint site.   In a short 11 business days, we create a semi-custom visual design for your site, leveraging our pre-build master pages, page layouts and themes.  For more information or to discuss your needs, contact our sales group.

Rookie mistakes to avoid during the SharePoint implementation process

Despite what may seem like a virtual explosion of SharePoint in the enterprise, it has been around since 2001. However, because of the various architectural changes in the recent version, SharePoint's popularity has taken off. The challenge now is to ensure that it is implemented properly in your environment.

Read the full article here...

SharePoint Report 2008 Released on CMS Watch

After months of work, the new SharePoint Report 2008 has been released.  I collaborated with  CMS Watch to develop a full 190 page research report that exposes what SharePoint does well, its limitations and what businesses of all sizes need to do to be successful when implementing the tool.

I encourage you to review the sample content and review the TOC.

If you have feedback on the report, I'd love to hear it. 

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.

Using SharePoint Search as a Research Content Source

Back in Office 2003, Microsoft introduced the concept of the "task pane."  The task pane was a panel that appeared on the right side of the Office interface (at least for the "first class" Office products).  The task pane represented a few different functions -- from showing the status of a document in SharePoint, to allowing you to manage permissions on a document.   Included with these functions was something called the "Research" task pane. 

The Research task pane allows you to search various information sources using basic keyword-type searches.  For example, if you highlight a word in a document and right click, you see a function called "Look Up."  When you select that option, the feature searches through the dictionary (for example) for the definition of the term you highlighted.  You can see this function in figure 1-1.

Figure 1-1 The context menu allows you to lookup a term in Office 2007

When you execute this function, the Research task pane dutifully appears on your right.  By default, the task pane appears to the right and displays the search result. In addition, it exposes a number of other sources that the search can be executed against (shown in figure 1-2).

Figure 1-2 The task pane and the content sources.

When I first saw this feature, I thought it was a way to extract additional dollars out of buyers of Office, since a good number of the research sources were premium sites that wouldn't allow you access to the content without a subscription.  However, I then noticed a link at the bottom of the task pane labeled "Research Options."  Clicking on this link allows you to control what sources are included in your task pane, as well as allowing you to add addition sources as shown in figure 1-3.

Figure 1-3 The Research Options dialog

As it turns out, it's easy to add your own sources, in addition to enabling ones already defined within Office.  In fact, one of the best sources of "research" is SharePoint.  SharePoint's own search web service is already setup to be included as a search source (MOSS, not WSS). 

To add your SharePoint site as a search source, follow the instructions below:

1. Click on Add Services button
2. Type in the URL of the SharePoint search service.  The default URL for the search web service is: http://[server_name]/_vti_bin/search.asmx.  Simply replace [server_name] with the host of your SharePoint site.
3. Click on OK and Office will validate the selection to determine whether there's a compatible search service.  
4. Once Office validates the search service, it will show you the name of the search service available to be included.  The service name will be the name of the primary MOSS site where search is hosted.
   
   
   
5. Simply click on Install and your MOSS search service will be added to your research source.

Once you've added your own internal search as a source, any lookup done within first class citizens of Office (Word, PowerPoint, Excel and Access), can use that source to look up terms and return search results, just as any other source.   When users click on a search result, Internet Explorer automatically opens, preserves the search results in pane on the left side of the interface and show the specific, chosen result in the main window (as shown in figure 1-4).  Now, all users have to do is navigate the various results until they find the one they feel meets their requirement.

Figure 1-4 Search results preserved in IE

This feature is particularly valuable for organizations that need to connect employees with content throughout the enterprise.  In addition, it adheres to a good rule of thumb about portals: don't make your employees leave the applications they're comfortable using -- surface the functionality in the applications where they do their work

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.