Tag Archive | "Project Management"

Tags: , , ,

Increasing your chances for a successful SharePoint project

Posted on 24 March 2009 by Andreas Vamvatsikos

There are five rules of thumb that every SharePoint Project team must keep in mind in order to have a clear chance for success.

Plan big, start small
Microsoft Office SharePoint 2007 is a platform with a vast array of capabilities and features which is a good thing … until someone tries to use them all in an single project. So plan big since MOSS gives you the background to do so, but pick a couple of business focused quick wins for your first project. Don’t try to solve all of the client’s data, search, collaboration and process problems at once, the project will just never end. Get an ally within the client team, pin-point one or two problematic areas with their document or process handling and provide a solution just for that, either as a small start-up project or even as a pilot of a broader implementation.
This makes it much easier to keep the project on time and in budget but also to get the “buy in” from the end users that you will need later, when trying to deliver solutions to more complex problems.

Educate your developers
As I already noted MOSS is a platform. As such it has a wealth of Out Of the Box features that can be utilized in any solution. It has even more features that can be downloaded through Microsoft and the Codeplex Community in the form of application templates and web parts. You can even buy components from various vendors to facilitate a solution. All of the above components and features are extremely customizable according to your solution design and the user requirements.
This is something your development team HAS to understand and embrace. It is sometimes difficult to convince a developer with .Net mentality to try and find a way to implement things in the above described “SharePoint way”. If you find the team launching Visual Studio and going through the “Dim x as …” routine something is probably wrong.
With that said, there are actually some extreme cases where coding is indeed needed but they must be treated as exactly that, extremes.

Educate your users
Starting from pre-sales, users must have a clear view of how SharePoint will benefit themselves and the company, how it is going to take some effort and stress away from them, so that they are willing to go a little out of their way (and their established habits) to use it. They have to be educated to the whole metadata and search paradigm (don’t be shy to give the Google example even if they are an MS competitor) but at the same time assure them that they will still perform most of their tasks through their beloved MS Office.
After Roll-out do not try to train everyone in everything! Prefer role-based training according to how users are expected to utilize the SharePoint implementation. Finally be prepared to communicate the positives of the implementation and get ready for a storm of questions that must be answered. Unanswered questions tend to lead to a lot of user resistance to system adoption.

Plan for business not for IT
Since IT is usually vocal, you may end up designing a business system based only on IT input, which is exactly the opposite of what you should be doing (I should know, have been guilty of this a couple of times). SharePoint was designed with business data and processes in mind and is built in a way that some of the customization and the administration can be handled by business users.
So you must set up a group of key users in the requirements phase, that can close the gap between the business needs and IT, that can describe processes, define roles and responsibilities and bring some specific “company know-how” into the project, since every business is unique in its structure, function and needs. Document the processes, templates and metadata (avoiding IT complexity and terminology) and get a consensus before proceeding to implementation. Missing process steps or messed up templates and useless metadata will lead to an unusable system.

Design for user friendliness, be prepared for change
A user friendly implementation is key to success. Try to keep as much of the offered functionality as you can within MS Office, users love the impression that nothing really changed in the way they proceed with their everyday tasks. Site Structure and navigation must be simple and – got forbid- nice looking! Spice up sites and site collections with some images or charts, don’t just pile up lists. Even in lists provide intuitive views, don’t rely on users to create them. Set up a site for social interaction within the company to lure users in increasing adoption and acceptance.
However build all that with a well thought out structure of Content Types, Site Columns List templates and Web Parts at the site collection level. This way you are going to be ready to adapt quickly
to the unavoidable change that all businesses undergo sooner or later.

Lastly remember that even if MOSS is a platform offering solutions to many business problems it does not offer solutions to ALL the business problems!

Comments (0)