Five steps to more successful SharePoint solutions

Some points about how to succeed in SharePoint projects. Nothing special but my little experiences.

  • Create a prototype. It is always good idea to go step by step through analysis document and think how to solve different problems and how to build up the solution. If there is something you are not sure about – try to solve the problem. It is cheap thing to do when you have no deadlines, it is highly risky and maybe very expensive thing to do when you have deadlines. If you have prototype it is easier for you to detect the parts of solution where workarounds are needed or where additional decisions from customer are needed. 
  • Don’t go too far. Use as much that SharePoint has to offer as possible. When customers needs something special then think how to solve the problem using SharePoint features. Don’t start thinking how to hack and code. There are many ways how to solve different problems on SharePoint. You can also suggest your customers to do things a little bit differently – as long as customer doesn’t have to go too far from his or her logic of solution.
  • Don’t hack if there are better ways. It is always easy to make fast modifications through SharePoint Designer without analyzing if this modification is just exceptional case or is it better to develop some new field type or feature or workflow that you can use also in other parts of current solution (or in any other solution).
  • Keep your code close to SharePoint. It is not hard to write code that does exactly what customer needed. It is a little bit harder to write the same code in SharePoint way using SharePoint classes. If you add new functionality by extending existing SharePoint classes then your code stays safely close to SharePoint and you don’t have to struggle through creating functionalities that SharePoint already offers.
  • Test your code under different accounts. In your own development machine you are usually administrator and you have access to all features that SharePoint provides. If your code has to run also for users with another permissions then always test your code also under the other user accounts. This way you can discover all permissions related problems early and you have time enough to change your code or update administrators guide so they know what permissions one or another user group needs.

That’s all for now. Of course, it is possible to write a long list of best practices but I consider these ones as basic ones that must be followed in every project your are participating.

If you think I am missing something then please feel free to add your ideas to comments block of this blog entry. 🙂

See also

Leave a Reply

Your email address will not be published. Required fields are marked *