So, I’m now slowly working my way through this excellent reference Professional SharePoint 2010 Branding and User Interface Design. A few weeks ago, I decided it was time to teach myself how to apply a custom ‘brand’ or interface design to SharePoint 2010. I was enticed into this pursuit for a number of reasons, including:
Play to its strengths - My next tip for success with SharePoint is a deceptively simple one. While accepting that SharePoint has its weaknesses, success accrues from deliberately playing to the application’s many strengths. Well d’uh, I hear some of you say. Bear with me – my point is acceptable I think, because many deployments I’ve seen simply don’t do this. They do the obvious – for example, “we’ve installed Team Sites for collaboration” or “we’ve rolled out SharePoint for document management” – but usually they haven’t moved far beyond this and found ways to leverage the platform’s strengths to truly make SharePoint a great fit for their environment.
Having made the decision to deploy (or maybe upgrade) SharePoint, done your due diligence and planned your project (see post #1 in this series), the next thing you need to do is scope your deployment and determine the functionality for implementation carefully, deliberately and preferably explicitly. If the planning phase was effective this should be easy enough. You’ll know what you’re trying to achieve and why – I’ll assume you have clarified the vision or objectives – and project scope should come reasonably naturally out of that.
Post #1 in the inevitable numbered series…These will be just my opinions, of course but, for what it’s worth, they’re derived from years of observations on what’s worked and what hasn’t. My lessons learned – sometimes bitterly – have come from working on or leading several real world SharePoint deployments. And also living with the results; I have done my time in an operational role as a Portal Manager on a SharePoint platform.