But the reality is that the SharePoint technology represents only 25% of your project. The implementation of a SharePoint solution consists of the following:

1. SharePoint software; 15%

2. Information architecture; 25%

3. Solution architecture; 25%

4. Infrastructure hardware; 5%

5. Training; 5%

6. Change management and communications strategy. 25%

Point 6 is the one most often neglected. We forget too often that a SharePoint implementation is the introduction of new working way that impact directly your users.

Imagine if I knocked on your door at home, and tell you how you should organize your garage based on my methodology?

You did organize your garage your way for twenty (20) years and I would be surprised that you would agree to change it quickly, even if you think I’m right.

The success of your implementation is intimately connected to the adherence of your user to embrace the usage of your application. Over 30% of your efforts should be devoted to develop a strategy for managing change within your organization. Here are some recommendations that are simple application, but effective:

1. Target your internal customers: Make sure you involve your users early in the needs analysis and seek for cohesion.

2. Communication Plan: A communication plan allowing all impacted users by the implementation will help them to take a step by step approach to accept changes. Users will have the opportunity to share ideas in the cafeteria, coffee break and their respective office allowing them to give feedback to the implementation team. Make sure you have a place to allow feedback from users: Ideas of the week! Proposed improvements! Etc …

3. Training: Training will be an opportunity for interaction between users and potentially bring or suggest improvements to the application. The training team must be intimately related to the implementation team of the application in order to influence the improvements suggested by users.

This is not an exhaustive list, but I wanted to make you aware that the change management when you implement a SharePoint solution is the cornerstone of your success.

The idea of this article came to me with the advent of SharePoint Foundation and SharePoint 2010 which will have a far greater impact on your users compare to SharePoint 2007. The new interface of SharePoint 2010 worried many SharePoint experts, since it requires greater adaptation, especially if you still on Office 2003.

Good day in-a-box, and hope to see you at SharePoint Summit 2010 in Montreal

Our first implementation of this functionality was bundled in a product called Sopra and was aimed towards CRM. The product was basically a few webparts, a relationship API and some backend lists to keep the relationship information. With this approach we were able to add our relationship webpart to the editForm.aspx pages of lists and configure it to be able to add items / documents in relationship with the current item.

This approach however came with huge drawbacks for both our development team and the clients. So we decided to review our implementation and came up with the next generation of relationship management – xRM – Anything Relationship Management. Some of you might have heard that buzz word before and that’s because it’s from Microsoft (http://www.xrm.com/).

The basic idea is to not be limited in the relationships we can setup in your business. The relationship management module of our new Alexya™ platform for SharePoint leverages the concept of anything relationship management, but inside SharePoint. Think about it, in SharePoint you can create much more than items and documents in lists. You can create wikis, blogs, documents, lists of data, lists of images, lists of contacts, team sites etc… Why would you limit the relationships to only 1 or 2 of those?

Our new generation xRM is so tightly integrated into SharePoint that the implementation is literally a zero footprint integration. No more webparts to manage and absolutely no loss of out of the box functionalities in the relationship views; now, you actually get added functionalities like the checkbox. The xRM module relationship area is 100% Ajax and all the work you do while using it will never trigger a page refresh, this is a major enhancement for users. Also, the original list forms are preserved and never changed.

The way relationships are created between objects in SharePoint is now centralized in a Silverlight administration interface completely integrated into SharePoint, no external database, no separate server.

If you wish to see it in action you can go on YouTube watch one of our videos: http://www.alcero.com/sharepoint/alexya/demos.htm

We have build our Extranet with various Alexya’s module to support our business needs: Case Management, Customer Support and Extranet collaboration.

Enjoy the video!

As a SharePoint product developer, this is a major problem since we have, to date, 11 products that sit on top of SharePoint some of which use this contextual menu in order to display available features to the end-user.

Let’s  take as an example render-It, a document transformation product that allows documents like doc or docx documents to be transformed in another format like pdf, html etc… Everyone will agree that this “rendering” menu item should not be displayed unless the current document meets the requirements for the transformation.  Some people on the web have taken an approach where they modify or override the core.js functions and add their own logic. This was not an option for us since we wanted a “non-intrusive” way of adding our logic to existing functions.

So instead, we used the reflective nature of the JavaScript language to “hook” up to existing core.js functions and modify their parameters in order to add our own menus at run time by making some ajax calls. This preserves the original core.js functions and prevents bugs due to possible upgrades or changes Microsoft might implement in the core.js.

This nifty little trick allows us to make an Ajax call to the server at run-time in order to validate if a specific menu item should be displayed for this specific item in this specific context. It makes the end-user experience much more enjoyable by not having 5-6 menu items that will give you an handled error message after you click on it like ‘this action is not valid for this item”  which is very unpleasant.

The result is a much more intuitive editcontrolblock menu with menu items available only when specific feature requirements are met by the current item, security, type, metadata etc….