My team just completed a large MOSS project and I thought now would be a great time to reflect back on the SharePoint implementation -- not to be confused with MOSS MVP John Holliday's SharePoint Reflections (of which I'm a big fan). 

The first big issue that we ran into is what I refer to as the Great MOSS Paradox.  This is the idea that Microsoft markets SharePoint 2007 to businesses as an easy to use product with a laundry list of easy to implement features.  On the surface, yes this is 100% true but it comes with a very big disclaimer.  Depending on how you use the product (Collaboration vs Publishing) different functionality is available.  The best example I can think of is blogs.  Yes, MOSS supports blogging functionality.  But if you create a new Site based on the Publishing Portal you no longer have the ability to select the blog template.  During the implementation of our project I was asked on numerous occasions "where did XYZ functionality go?"  The truth is there's a big difference between out of the box and a customized site.  For the uninitiated, it is a very tricky subject.  It is difficult for management to sell MOSS to clients and it is often difficult for the clients.  Which brings me to my next point....

Setting expectations.  We found that because of the information being communicated about MOSS that setting and managing expections was critical.  It is very easy to get wrapped up in complicated functionality that is very difficult to implement.  The learning curve with MOSS is steep and often doing the most simple tasks can take a long time.  Early on in our project we engaged MOSS MVP Andrew Connell to give us a two day primer on all things SharePoint.  One of the most valuable things we did was to design a proof of concept.  It helped us to understand all of the concepts we needed to master and along the way we learned where the biggest pain points would be.  Ultimately, we still found new pain points but it went a long way to helping us.  It helped to arm the team with the knowledge about how to estimate and gave us a punchlist of everything that needed to be completed. 

On a related note, the proof of concept also helped to reign in our expectations of what was technically feasible to be completed in the time frame we had available.  Which in turn allowed us to go back to the client and work with them to manage their expectations.  The "under promise over deliver" mantra can be a challenge -- but not impossible if you work to...

Keeping as much as you can "Out of the box."  Vincent Rothwell aka The Kid recently had a great post on this topic.  I won't rehash the post, but the main point is worth repeating: SharePoint offers a ton of functionality OOTB, but your time and effort curve increases dramatically the farther away from OOTB.  You can do a lot with a custom site definition, custom master pages, and smart use of the out of the box web parts.  Just remember that the typical development cycle for MOSS also includes Feature and Solution development so often OOTB functionality still requires some level of effort.

These three points really go hand in hand.  Gaining an understanding of the product is important so that expectations can be set properly and realistic estimates can be made.  I really enjoy working with MOSS, but it is important for everyone involved in the process to understand that although MOSS is .NET -- the development process is unique. 

In future posts on the Lessons learned from the real world I plan to discuss the technical gotchas we ran into as well as the challenge of getting more than a hundred non-technical content authors trained and entering content. 

Feel free to check out the site I've been referring to throughout my post:

Orange County Public Schools - http://www.ocps.net