Leverage what you have, it really does work

Almost every day you'll find people complaining about SharePoint and how it doesn't do something exactly the way they want, or it's complicated to use, blah, blah, blah, blah, blah. This is pretty much true of any technology and yes, with enough time/money/resources anything is possible. Don't like what SharePoint does with Grouped Listings? You're welcome to write your own Web Part from scratch because you want the icon on the left instead of the right. Is it really worth it? I seriously doubt it.

SharePoint is a mish-mash of technologies and comes at a price of a pretty steep learning curve. A SharePoint guru needs to know all about the product in order to really know how they can exploit it. If you don't know all the features of a DataView Web Part (and there are many) then how can you dismiss it when you're looking for a solution? In addition to just knowing the product, you really need to know Windows infrastructure, Windows Server, IIS, Active Directory, DNS, SQL Server, and the list goes on. Now you don't need a deep understanding of all of these technologies but you certainly need some familiarity with most of them (and having a good breadth with 1 or 2 topics covered in depth is a good rounding of knowledge when it comes to SharePoint).

For example I was challenged with creating a news archive web part which allowed a user to browse all news items in the system, select a year, then filter by that year. All news items live as listings in SharePoint and you can just target the top level area to start getting listings for, recurse through them and put together your collection of information and present it. This is neither rocket nor science, at any level. However the implementation of the system was that they chose not to use the OOTB news areas, but rather created a custom area and all news items were entered manually (in a Document Library using the Web Part Page template) and listings were added manually (and then repeated on the Home Page to display the content again). This was all apparently done because someone didn't like the way news was entered and wanted more flexibility. True, you have a lot of options when you use a Web Part Page and a Content Editor Web Part, but is it really worth all that hassle? Using the built in news area and news feature of SharePoint Portal Server, it's a one step process. Click "Add News", enter your text (or link to an external news item) and save. The process the users go through now is about 10 steps involving a lot of duplication of information and manual editing of links (which can [will] lead to broken listings at some point).

Bottom line:

  • Learn the technology platform you're working with and what it has to offer. Assume it works as expected (after all, you paid for it and it should) but do small technology spikes if it's a feature you're unfamiliar with (for example if you've never done a CAML query in code before try it before you offer that as a solution to building a White Pages system).
  • Experiment yourself before you go into the meeting to discuss what the user needs so you know your boundaries
  • Only build what you need. It's great to provide a system that has all the bells and whistles, but you'll find yourself quickly creating work for youself and makes your solution more complex than it needs to be and features that the end-user, while they may appreciate it, not really use in the end.
  • Be the customer. If a solution smells complicated to you, walk through a scenario from their shoes and if you're frustrated doing it then they'll probably be too.
  • Clearly set expectations with your customer on what they're getting and provide options (options always come at a cost but generally there are many ways to present information with OOTB features in SharePoint)
  • Get buy in from as many levels as you need and flag things early and often if they look like an oddball solution to you (which in the long run will end up costing more when you keep revisiting it to fix things)
  • Don't paint yourself into a corner and deliver a "Quick Hit" if you know you're going to be going back and fixing/rewriting/changing it entirely. While we can't read the minds of end-users, we can (if we're good enough) anticipate their needs and have alternate plans to back out if things get too complicated.

2 Comments

  • I think its important to clearly establish that you are working with a product and that the product has strenght and weaknesses and also that sometimes the best way to use the product will not match with someones opinion on a particular thing.

    If the product does not do something in the assumed manner, the assumtion is wrong, not the product.





    I've seen an MCMS project hobbled by the fact that the UI for managing related content was determined from looking at annother cms system.





  • BRILLIANT!!!! Well Put!!

Comments have been disabled for this content.