I liked this post as its right on the topic area that I am particularly interested in.
User adoption as you say is particularly important and something as simple as organisational culture can completely derail a SharePoint project. When performing training this is quite evident. Sometimes the vision behind the portal reflects one person's ideals but the organisation is not ready to come with them.
Thanks PCulmsee. It's also worth bearing in mind that the 'cultural mix' of an organisation staff will have a bearing here on user adoption.
For example, traditionally public sector organisations will typically put more effort/budget into training. This is because the transition is often more 'challenging' as employees are often more resistant to change than say private sector businesses in my experience.
All the best, Andrew.
jthake
· 11 months ago
I liked your take on Project Management and include the comparison of customisation and development. Very topical at the moment with the points I raised in my most recent blog article. This is something that the community as a whole needs to define more clearly. Where the line is drawn and some scenarios to set both the end users expectations but also the SharePoint teams too. Where to draw the line between SharePoint Customisation and SharePoint Development It also aligns nicely with the other articles I've written on this web site about Leveraging the SharePoint Platform: Leveraging the SharePoint Platform. I agree completely that the SharePoint Platform is a large area and pretending you know all it's functionality is insanity! The most common one I see repeated everywhere is the Intranet Phone Book app rather than just using MOSS User Profiles and People Search!
walmslan
· 10 months ago
Thanks JThake for your feedback. I have found all to often the lines between customisation/configuration/development is blurred and this I think will continue as organisations begin to push the boundaries of how SharePoint can be leveraged to improve upon current inefficiencies, together with a general lack of good SharePoint resources out there at the moment.
sharepoint_consulting
· 10 months ago
Good post. Taking small steps is key to a successful SharePoint projects especially if this is something that the organization is starting out on. Other than that, SharePoint projects should be handled like any other technology project.
walmslan
· 10 months ago
Thanks sharepoint_consulting for your comments. Small steps are important, but many businesses don't necessarily have the patience to take this approach!
As for treating SharePoint like 'any other technology project', agreed but at a more granular level they do present different challenges to say a traditional IT development project or email migration project.
In my view they have similarities & approaches that need to be merged as SharePoint can and will cut across such traditional project delivery methods.
ccarter
· 10 months ago
Thank you for the article. I am assigned to manage a SharePoint Site Development project for a department within our company. The developers have some experience developing a SharePoint sites to date. Do you know of a source for a project plan template for site development. I've found some for Enterprise SharePoint implementation which is a little more than I need. Thanks.
walmslan
· 10 months ago
CCarter, they vary so differently depending on the needs of the project.
You don't say what type of SharePoint project (The 'sharepoint site development' name unfortunately means very little) it is in terms of scope, (Intrant, extranet or internet), which products you're using - WSS, MOSS, etc.
Hence difficult to respond with specifics as such. Based on what you have said however, use the enterprise one as a starter and strip out the irrelevant stuff that sounds completely out of scope for what you are doing - It's often easier to take out, than put back in so to speak.
Ensure there is a 'design stage/sign off' process, infrastructure ratification step, release cycle(s) planned in, launch/adoption activities.
Some basic PM stuff, make sure you have a scoping document (Project Initiation Document (PID) - this needs to be signed off/monitored regularly, Issues/Actions list reviewed weekly and actioned accordingly.
Finally review your team structure - suggest given your supposed lack of experience, avoid any branding changes, stick with features 'out of the box' for the first couple of phases, bring in bespoke stuff later once you have understood the wide features, constraints and therefore opportunities to add value later!
Hope that brain dump helps... Andy
Andy Dale
· 8 months ago
The important factor is to know why you want SharePoint in the beginning. It is a great tool but is not a fashion accessory. I would advise almost having a SharePoint Project Mission Statement that the Project Team can always refer to.
All Comments
User adoption as you say is particularly important and something as simple as organisational culture can completely derail a SharePoint project. When performing training this is quite evident. Sometimes the vision behind the portal reflects one person's ideals but the organisation is not ready to come with them.
http://www.cleverworkarounds.com/2008/11/17/roo...
http://www.cleverworkarounds.com/2008/11/17/roo...
For example, traditionally public sector organisations will typically put more effort/budget into training. This is because the transition is often more 'challenging' as employees are often more resistant to change than say private sector businesses in my experience.
All the best,
Andrew.
Where to draw the line between SharePoint Customisation and SharePoint Development
It also aligns nicely with the other articles I've written on this web site about Leveraging the SharePoint Platform:
Leveraging the SharePoint Platform. I agree completely that the SharePoint Platform is a large area and pretending you know all it's functionality is insanity! The most common one I see repeated everywhere is the Intranet Phone Book app rather than just using MOSS User Profiles and People Search!
As for treating SharePoint like 'any other technology project', agreed but at a more granular level they do present different challenges to say a traditional IT development project or email migration project.
In my view they have similarities & approaches that need to be merged as SharePoint can and will cut across such traditional project delivery methods.
You don't say what type of SharePoint project (The 'sharepoint site development' name unfortunately means very little) it is in terms of scope, (Intrant, extranet or internet), which products you're using - WSS, MOSS, etc.
Hence difficult to respond with specifics as such. Based on what you have said however, use the enterprise one as a starter and strip out the irrelevant stuff that sounds completely out of scope for what you are doing - It's often easier to take out, than put back in so to speak.
Ensure there is a 'design stage/sign off' process, infrastructure ratification step, release cycle(s) planned in, launch/adoption activities.
Some basic PM stuff, make sure you have a scoping document (Project Initiation Document (PID) - this needs to be signed off/monitored regularly, Issues/Actions list reviewed weekly and actioned accordingly.
Finally review your team structure - suggest given your supposed lack of experience, avoid any branding changes, stick with features 'out of the box' for the first couple of phases, bring in bespoke stuff later once you have understood the wide features, constraints and therefore opportunities to add value later!
Hope that brain dump helps...
Andy
Andy Dale
Senior SharePoint Consultant
Officetalk
Blog : http://aboutsharepoint.com