SharePoint Customers Playing ‘Match Game’ with Providers

Say the word “SharePoint” in IT circles these days and you’ll be met with free-association responses that are as contradictory as they are predictable:

Easy to use … difficult to manage … pretty solid … hard to understand … the latest Microsoft plot to take over the world

Ask, however, about the purposes to which SharePoint is to be put and a much clearer picture emerges:

Content management … collaboration … portals … business forms … search

We know this because we’ve spent the past several weeks asking these questions, formally and informally, and then diving deeply into the world of SharePoint partners to see how their statements of value match up against the responses we received. The result? A typical misalignment of marketing message and market need. Here’s what we found:

Among the Partners

• An awful lot of SharePoint partners – say, a third of them – seem hard-pressed to use the word “SharePoint” properly in a sentence. They’ve done a fair-to-middling job of repurposing Microsoft’s official verbiage, and that’s about it. Consequently, nothing stands out about what differentiates them from the 999 other firms they nominally compete with, nor what need SharePoint may have been designed to fill.
   
• Another 20% or so appear to have focused on one or two of SharePoint’s numerous capabilities, and have done so to decent effect. Most of these highlight content management, collaboration, and, to a lesser degree, process improvement as core strengths, a proper and solid mix for most customer organizations.
   
• The remainder come across as the consultants most of them are, talking about their stellar ability to listen to their customers and develop solutions that are optimized for each situation. Not that there’s anything wrong with that (see Seinfeld, Jerry), but it can leave the reader wanting, and it certainly does presuppose the customer already knows what he or she wants.
  
  And therein lies the rub.

Among the Customers

• If the participants in a recent AIIM webinar are any guide, nearly a quarter of organizations either are still learning about SharePoint or are considering whether to deploy it. These people are hungry for as much fluff-free information as they can get, not only about the product but about how to think about what they most need. They likely know SharePoint can do a lot of things, but they may not know which of those functions will do them the most immediate good. Offers of meaningful help thus are gratefully accepted.
  
   
• Those that do have an idea – between half and two-thirds of our Webinar participants – say they’re looking to SharePoint primarily to handle content management and collaboration, followed by portals, search, and business forms in relatively equal measure. That content management scored so high may not be a surprise given that the question was asked of an AIIM-centered audience. However, business forms’ strong showing is interesting because they tend to be represent the great stealth need: never appearing in an inquiry or specification but needing to be dealt with right away because they’re central to most business processes.
  
  
  
  Sadly, very few SharePoint partners mention forms at all, even though the capability is baked-in via InfoPath.

• Besides being great for jump-starting workflows, electronic forms also work wonders for organizations seeking to reduce paper. However, it turns out that relatively few of the organizations we polled are thinking that way. Only one-third reported having a paper-reduction program in place, and 14% said they are too overwhelmed by the possibility to even think about it. So SharePoint partners leading with the environmental savings associated with moving from hard copy to soft might want to reconsider – not because the logic is wrong, but because people have other priorities right now.
  
  
  

Conclusion

At the end of the day, our foray into the market tells us that SharePoint partners overall can do a better job of matching their value propositions to the needs of their intended customers, and bringing out areas of associated value along the way. This issue isn’t endemic to SharePoint, of course. But it is worth bringing up because of the messaging onslaught we’re about to experience with the release of SharePoint 2010, which will only pile questions about the differences between the 2010 and 2007 editions on top of the questions so many organizations already have.

If only Gene Rayburn were available to moderate …

InfoPath: Where e-forms meet Sharepoint (comin’ thru the rye)

As much as recent perambulations around the edges of the forms arena have confirmed that so much hasn’t changed about organizations’ appreciation for and use of electronic forms (see post of February 9), so they also have opened the gates between what once was an administrative backwater and the more mainstream world of IT. This isn’t to say that today’s forms administrator is tomorrow’s CIO – far from it! – but for those who are so attuned, the separation between the roles is beginning to narrow.

For example, not too long ago, I asked in several places (including the AIIM and Xplor groups on LinkedIn) where forms become something more in the scheme of content collection/presentation (like, say, personalized brochures/enrollment kits), and the answers were varied and interesting.

Today, I’m moving in a different direction to gauge how e-forms are being leveraged in the Sharepoint world. Specifically, I’m keen to learn how best to move forms into InfoPath, and I’d like to pose the couple of quick questions below about your experiences so I can compile an insider’s lay of the land. Even some short, quick bullets would be really helpful, so please comment and/or email me at sweissman@hollygroup.com. Thank you!

- Are you starting from scratch in InfoPath, or are you converting from paper or a different e-format? (Jetform, PDF, etc.)

- Are you trying to re-create the layout of a specific paper form, or is a regular online form OK? (trying to learn what the latest thinking is about this)

- Do you need only simple fill and submit capabilities, or do you need programming for calculations, validation, database lookup/entry/reporting, etc. as well? (don’t know how much harder it is to do all this vs. not)

- How long does each form take to finish? (I know it depends, but is there a rough guideline for planning purposes?)

- Who’s doing the actual work? (by title or function)

- What is especially straightforward or challenging about moving to InfoPath forms? (forewarned is forearmed!)

Stay tuned for more. Thanks!