Background

I mentioned in my last post entitled “Document Migration in SharePoint – Your options”, that there are basically 4 main options available to you when deciding whether to migrate content from your file shares and other repositories. To summarise:

• Migrate completely into SharePoint
• *Partial migration of a subset of the content into SharePoint
• **Leave where it is and continue to maintain both repositories independently
• ***Leave where it is and continue to maintain both repositories, but use SharePoint to index your old content, hence providing capability to search it.

One or more of these options may be the route you end up choosing depending on your needs and requirements.

*The older content may well be archived or just deleted.

**Consider the expense and risk here maintaining ageing equipment

***This has limited options, investigate thoroughly and test in particular the search results, hence use with caution.

Next steps and considerations

To help you through this decision process to determine which route is best for your circumstances, I have below written a few pointers for you to consider and debate within your core project team and stakeholders alike. These comments are based on several years of managing a variety of SharePoint projects, so hopefully you will avoid some of the painful lessons learnt that we and our clients went through! It’s probably not everything you need to think of, but a good start with a few thoughts to help you along your way.

“Migration can be expensive especially when you consider the volume of information you are intending to migrate, the true cost of the business and technical resources (internal and external) you intend to schedule in to help with the migration effort”

Question your stakeholders & senior users as to whether or not they really do need to move across all those documents and intranet pages, images, video, etc. Based to some degree on anecdotal and empirical, my experience shows time and time again, 80-90% of content is seldom if at all accessed beyond 12-18 months after it was created. So you could be creating a mountain of work, for very little return in value.

I therefore recommend trying to find supporting evidence to confirm it is (or isn’t) accessed frequently or other statements supporting or otherwise the migration requirement. Find out why it actually ‘needs to be migrated’, almost like putting together a mini business case decision process. Often business units will just say it is, to avoid doing the work of investigation or migration in the first place because they have other (naturally so) priorities. The reality is a good old clear out is often a welcome and good opportunity to freshen the content up, archive older elements of content not longer required.

I also strongly recommend you carry out a review of the content that has been amassed over the years. You may be surprised to find out how much of it really is no longer needed, relevant or appropriate and or actually identify content that needs to be refreshed anyway.

Remember also there is a subtle, but important difference between it being ‘available’ to the business and it being migrated and available in SharePoint. For example, you may keep it away from SharePoint in less available, but still accessible offline media or other perhaps cheaper forms of storage.

If you do determine that you will have a large amount of content to migrate, really do put in place a ‘blueprint’ for the migration team(s) you mobilise, make sure everyone is aware of their roles, their tasks and when they are supposed to be doing them and why. They in short need to be fully on board with what is being done.

You also need to ‘prove the process works in advance of proving the throughput’ for your migration teams. This goes for the manual, automated or mixture of both approaches. Be generous in your estimates for migration based on the results of your findings. This will give your stakeholders confidence in your project teams ability to meet the migration deadlines.

“Impact on overall SharePoint architecture needs to be planned into the overall design”

Hopefully you will have covered some or most of this in your original SharePoint architecture planning…Think about the increase in load on your physical server environment, capacity planning issues, impact on search results, overall navigation and usefulness of your content, to name but a few areas that need thought and evaluation when considering migrating existing content into SharePoint.

For example, if you’re going to move and or index any of the externally stored content into your SharePoint environment, consider the implication for the increase in storage you are about to place on your environment. Not least because the increase in size isn’t just for the raw data storage of content being added in your SQL databases, but also the new storage required to handle the increased index file sizes.

Then consider the additional load you have just placed on your backup & restore processes! You might bring potential pressure on your ability to meet your SLAs for service availability in case of downtime. For example can you still restore your newly increased content databases in the time allowed within the SLAs?

“Evaluate 3rd party tools to help you with the volume of data”

Many 3rd party products do a great job in helping you bulk migrate/upload content into your SharePoint environment. However, many will not meet your requirements fully, so review them carefully and plan their performance (or lack of) with migration and costs into your plans and budgets. It’s important to know their limitations as well as their strengths. You may find they migrate many, but not all of your document types. Also, quite often you will lose some important document properties or other meta data associated with the document or pages you are trying to migrate.

In addition you may lose data integrity for example the timestamp information. This is typically something that may be important from a records management perspective, as it may not be carried across to the new environment.

“Ensure you get the business to take the lead in migration”

By all means provide the blueprint (approach), tools and methods in which ensure content can be migrated. Ultimately however the business users should ‘own’ the actual migration and be fully involved in this part of the project from the beginning. They are best placed to know what content is or isn’t required, how it should look, be accessed, etc. It also happens to be one of the best methods to educate your end users in the use of SharePoint capabilities you are providing to them overall.

“Consider regulatory obligations to retain data”

Several business sectors in particular the government/public sector, finance, health and charities have particular regulatory rules they have to follow for data retention, availability and access (data protection issues as a whole). These will need to be factored into your plans.

“Disinvest and or reuse your old hardware”

The migration from old intranets, file shares or other applications potentially allows you to disinvest your hardware (or at least some of it).Plan for this effort, even if it just find out how are you are going to recycle the kit or have it removed from the server rooms. Do consider charitable organisations or schools that might benefit from the old equipment rather than dumping it in landfill.

“Remember, not all data should or can be stored in SharePoint”

It is true SharePoint can index a variety of content sources. But the painful reality is this rarely achieves the results originally desired, due in part not because of product failures per se, but because the general maintenance of SharePoint based searches take a lot of ongoing effort that is often forgotten or omitted in the design or on-going maintenance.

Quite often it’s the easy route to index your ageing and bulging file shares, but would you really want your search results to contain information from sources that is so old and out of date? Without the careful design at the beginning, fine tuning and regular maintenance required often you end up with a poor experience from a user perspective.

So by all means consider indexing your sources, but really do understand the implications from a design, planning and ongoing maintenance perspective not least the users experience with the search results pages. On the latter note, consider all of the out of the box options that you have with search and also introducing filtering for your search results content (custom or 3rd party route).

“Consider leaving the content where it is”

Try to understand both the tangible and intangible benefits of leaving the content in situ, and perhaps making the content ‘read only’ for a period of time whilst you consider your options and or carry out your migration, so as to not allow the increase, or changing of content stored in this area.

Conclusion

There are lots of things to consider as part of your discussions for deciding the approach to migration and the above are just some of the topics you may have to consider.

It’s often politically the ‘path of least resistance’ to just migrate all content, irrespective of the technical and sometimes the financial rational for doing something different. If you haven’t already, consider introducing archiving, quota and retention policies to manage the no doubt increasing volume of data in your environments.

Do engage with your stakeholders and get their buy-in to owning the migration piece. Often a strategy of making sure the business carries out this migration will make them think differently when it is their resources that are taken off their normal roles to do it.

Finally, in my experience migrating and refreshing a small subset of the original content into SharePoint, plus archiving the rest is the appropriate approach for most circumstances. Turning on SharePoint indexing capabilities for your file shares, but only in small and measured circumstances is also something you should consider.

Regards,

Andrew Walmsley

Director, WorkShares

Background

We were experiencing some issues with our hosted email provider through 2008 and were looking to move away from them at some point this year.

Together with our own business strategy of providing hosted solutions we were keen to continue ‘consuming our own food’ so to speak. Hence we were on the look out for a smaller number of service providers for our core service of email, conferencing, collaboration and instant messenger/presence.

Having signed up as a partner of Microsoft Online late last year, we also felt we needed to experience first hand what some of our future clients would go through and decided to move to Microsoft Online service when it became more widely available.

Microsoft Online – http://www.microsoft.com/online/solutions

We moved our organisations email services to the recently launched Online Services offering. There are several services available including:

• Dynamics CRM – Customer relationship management

• Office Live Meeting –Conferencing/live online meetings

• Exchange Hosted Services – Virus software protection, encryption and filtering for Exchange

• Exchange Online – Exchange email, calendars and contacts

• SharePoint Online – SharePoint (Windows SharePoint Services v3)

• IM & Presence – Office communication for instant messaging and presence

• Business Productivity Online Standard Suite (BPOS) – encompasses Exchange Online, SharePoint Online, IM & Presence and Office Live Meeting services ‘all in one’ package.

All of the above have been available predominantly in the US during last year and are now in UK and other parts of the world. There are also dedicated offerings for the larger customers available whom wish to move perhaps their ‘on premise’ solutions into the cloud.

We opted for the “Business Productivity Online Standard Suite” over a month ago now and though we didn’t replace all our services in one go, it nevertheless provided us with a useful insight into the challenges presented to businesses when moving from either ‘on premise’ or existing hosted service.

At this stage we have only moved our email and live meeting services over – though arguably our most critical application and service, (email) we felt comfortable with doing so based upon research with other beta users, demo’s I had seen plus existing experience in general with hosted exchange providers.

In addition to email and live meeting we were was also provided with these additional services as part of the package.

• Exchange Storage of 100gb (for all mailboxes)

• SharePoint – 5GB of Windows SharePoint Services

• Live Meeting Office Communications. 

Migration and Setup

So far so good. As you can see from the screenshots below, once you have the service up and running, the administration console is a clean intuitive interface with various options presented in tab like format.

The migrating and setup of the Outlook 2007 client was fairly straight forward, though migration from hosted email provider isn’t particularly well catered for in terms of migration tools. This is to be expected I guess as there are so many configuration options here and many would need the server level access, ISP’s wouldn’t be willing to provide.

Not the same however for your ‘on premise’ based solutions it has to be noted, as Microsoft has provided several options in this arena for you to consider as part of your migration planning. As you can see from the image below, we have several options to consider and plan for.

Once you’re email has been migrated you have access to your email either from your Outlook 2007 client. In addition you can access to your mail via the web browser in ‘Outlook Web Access’ shown below, which is great way to access your emails on customer or client sites.

Single Sign On

The Single Sign On application provided is a neat piece of software and very easy to use giving the user a single console like interface in which to launch their applications.

User Portal

The single sign on application will take you to your personal user portal. You get a number of different screens within your administration center, but the user portal is specifically personalised for your users and importantly has a lot of help already built into the site.

Live Meeting

We have not done much here other than to see ‘it just works’ and provides usual features to allow for live meeting to take place.

Office Communicator

Not something we have played around with much either, but again it just seems to work as expected. We’ve only just loaded this up, but will consider migrating to it once things have bedded down a bit. It’s basically an instant messaging application which will evolve into a ‘unified comms’ platform by 2010 supposedly.

SharePoint Online Features Table

Here is a table with the features provided by the SharePoint Online service, which is part of the BPOS offering. Again, we haven’t done much in this arena as we have other providers for this at the moment, but it pretty much does what you would expect. Note: It’s based on Windows SharePoint Services not MOSS for those interested.

Support during migration

Responses in general to queries being raised were provided to us in a timely manner, either by way of updates to the support area and or by way of telephone during office hours.

Our planning was thorough having gained experience in upgrades/migrations of Microsoft products with our day jobs, but we still came up with a few issues/challenges around email.

We particularly like the online support area, which is much improved from our old provider and keeps you easily up to date as to progress with your support requests.

Conclusion

The Good

• Setup was ok as we mentioned, though not really for the ‘none techie’ or individual whom isn’t used to migration issues with Microsoft based technology. You do need to plan your migration carefully as there are many permutations to consider, especially for your ‘on premise’ existing email providers and or SharePoint content migrations – more on this for a later post.

• SharePoint Online support changes made by SharePoint Designer and forms introduced by Infopath

• Mobile access to email via Windows Mobile devices is simple to setup

• Fantastic value for money with email, SharePoint, live meeting and instant messenger applications all neatly tied into one cloud based platform

• Highly resilient platform 99.9% plus secure https (only) traffic for all users

• Support via email and telephone was excellent.

Not so good

• It’s basically Windows SharePoint Services functionality, not MOSS

• Migration tools from hosted Exchange providers are none existent. Which we guess is ok, as you have the option to migrate/import your old PST files – but you do need to plan in time for this. For large scale migrations, you need time to do this and plan in appropriate with the user as they may well be without their mail during this time. Though with the migration tools available, you won’t lose any email

• Unfriendly URLs with all services – Apparently plans to improve on this area, but expect very long URLs and no way to change them

• Doesn’t support bespoke code within SharePoint Online (that requires server side additions or changes) but will allow SharePoint Designer based changes

• Arguably the lack of ability to support custom modifications is a ‘Bad’ but feel we have a good compromise here. Besides which, the dedicated offering from Microsoft will allow this. This position will probably changed for the better with SharePoint 2010….

Bad, needs improving

It’s early days yet, and perhaps we will post back after a month or so of using it in anger! Otherwise, it just works from our experience to date.

Regards,

Andrew Walmsley

WorkShares Team.

When looking to design, build and introduce any SharePoint based environment into your business, like any web based development that is accessed via a variety of internet browsers, you need to consider (amongst a whole host of other things!) the page weight of your users home page. Be that the main intranet home page, internet facing, team or mysite page – which ever you have set to be the users main browser home page.

This is often forgotten in an age when rightly so, broadband is getting more prevalent and cheaper.

Nevertheless, organisations still have bandwidth demanding applications and is even more critical for enterprise size customers or when your users are dispersed geographically and accessing SharePoint over small network bandwidths, over remote connections and or when your existing network utilisation on these links is high.

I held discussions with a well known high street bank not so long ago about introducing SharePoint into its branch network, essentially to roll out a company wide intranet and in short, it was put on hold due to in part very small bandwidth links to its core branch network – circa less than 256k. Utilisation on these links was also quite high – 40-75% each day. And whilst a large LAN/WAN upgrade project was being considered, it was decided nonetheless to put the intranet project on hold until this was completed so as to not jeopardise the impact and hence adoption of the new intranet. It’s a decision I thoroughly endorsed.

During this period of evaluation we got to understand what SharePoint downloads all be it once during most users browser sessions. In short, there are about 300-400 kilobytes worth of javascript, other controls and files on a standard, out of the box SharePoint home page. This is before you add in any additional branding, custom web parts, content, etc. Hence you could very quickly come to a page which weighs in at 750k to over 1mb! It’s worth noting this is only for the first time and is cached for subsequent sessions (unless of course the cache is cleared frequently,i.e. when the PC is powered off or browser closed). Multiply this by 1000’s of users all logging on in the morning, you could well hit some thresholds on your bandwidth.

There are of course different types of optimisation you can do, like server side compression, but this requires considerable additional effort and change, if not planned for from the outset. But is nonetheless an area worth exploring if time and budgets permit.

More often than not its more or a local bandwidth issue nearest to the client, rather than the server side. Another consideration should be the timelines in which users will be logging on, i.e. when will performance ‘peek’. Of course, if your business is ‘bandwidth rich’, then it may not be a problem at all, but in my experience it’s always worth looking into it.

It’s recommended to thoroughly investigate this area prior to launch or when thinking of introducing other bandwidth demanding application via your SharePoint environment such as video streaming.

Regards,

Andrew Walmsley

Director

www.workshares.co.uk

Technorati Tags: moss, wss, sharepoint

Growth in third party tools

I have worked with SharePoint as a framework since its first full scale release in 2001. Since then I have witnessed the steady growth in third party tools to provide either enhancements to weaker functionality provided ‘out of the box’ (OOTB) by SharePoint, or new features to complement existing core functionality.

Most third party utilities or web parts started to come out with the previous release of SharePoint (SharePoint 2003 & WSS V2). But with the release of Microsoft Office SharePoint Server (MOSS) 2007 (and WSS V3), there has been an exponential growth in a whole variety of end user or administrative focused tools.

Entire businesses have in fact emerged over the last few years with their sole business model aimed at meeting the clear demand for list aggregators, backup & migration utilities or reporting enhancements, to name but a few. Not forgetting the MVPs, Open Source efforts over at Codeplex and the work by specific individuals, often referred to in posts and blogs within the SharePoint community.

Growing pains

The growth in third party tools and expanding SharePoint community, whom also provide a vast array of often ‘free’ downloadable utilities, means businesses deploying SharePoint have never been better served and can arguably gain even more out of their investment in by using the latest Microsoft SharePoint technology.

However, my experience over the last few years with third party utilities, in particular with the very nature of new and often immature utilities and add-ons, has led me to believe that these tools can be fraught with issues for the unwary.

Issues encountered include:

• Code developed and tested in a MOSS environment, not specifically WSS (but released for both types of platform anyway, causing key functions purported to be available, that fail to work as they are not supported or available in WSS)

• Tools and utilities often unsupported and provided for download on an ‘as is’ basis

• Poor documentation to allow for effective and safe configuration and setup

• Little or no testing prior to release, hence tools are ‘buggy’ and unstable

• Unproven usability and functionality across load balanced environments

• Poor or non-existent end user support.

Even some of the better known third party tools on the market have, in my experience, been quite poorly developed, therefore the development companies are unable to respond to even basic support related queries or product bugs. The tools and utilities often have been clearly developed on and for MOSS environments, but advertised for WSS as well, with the originating developers knowing very well there will be problems with its lesser feature set. I suspect these are just growing pains of small businesses and hopefully their development processes and support services will improve over time.

Is your selected third party product really the right choice?

It is clear many of the tools available are extremely useful, otherwise they wouldn’t have been created to fill a gap in the first place, or sold so well. I do think however that businesses, or rather inexperienced individuals, often forget (or just don’t know) to consider fully the issues involved in deploying 3rd party products that have been developed outside of certified Microsoft and other core platform environments.

What was once your relatively clean, core and stable environment has now been ‘dirtied’ by dlls’, web .config changes and registry settings. This provides you with the risk of a potential level of instability that is unacceptable, resulting in endless hours trying to troubleshoot and resolve issues that could have been avoided in the first place. Hence embark on deploying such tools without the proper due diligence at your peril!

Questions regarding third party tools I would suggest you consider are as follows:

• Supportability – Does the organisation provide timely updates and bug fixes to the components? Will it be supported in 64 bit platform? Does it need to and actually work across different browsers? What do others say about the product in the community? Who will pay for supporting it internally? What if the person whom installed it leaves?

Ultimately then, organisations can and do gain a tremendous amount of value for money from their investments as long as they invest wisely. However, I think a sizeable amount of businesses will have had numerous issues to do with performance, functionality, reliability or stability when using third party tools.

Due diligence

To reduce your exposure to such issues when purchasing third party SharePoint tools and utilities, you should carry out an appropriate review and justification process with these products.

I recommend the following as a guide:

• Understand in detail what it will take to provide an evaluation & test of the third party tool(s) assuming you will set up an separate environment to do it

• Document a list of business and or technical requirements you need to fulfil, matched by a list of product features stated. Compare & evaluate

• Review if possible on ‘pre-production’ evaluation environments in as close to a ‘like for like’ scenario as you can afford (UAT preferred)

• Read the specialist SharePoint forums and appropriate feedback from others who have used a particular product before deploying and essentially gauge a view on others experience of using the product

• Ensure you have a backup/restore approach that works (and has actually been tested), if you need to rollback following a tool/product deployment due to issues or other constraints

• Ensure you have considered your pre-production and disaster recovery environments in your planning, testing and budgets

• Consider documentation needed to not only install, but to provide support to your helpdesk team responsible for support and overall governance

• Before you embark on the process of introducing 3rd party tools really do look at the feature set provided out of the box and understand if minor changes to existing requirements can be made to avoid introducing such products or bespoke changes

• Where a third party tool is to be made available to end users, ensure the appropriate business testing and training is planned and made available in advance of any trial or pilot deployment.

Conclusion

The simple reason for this post is to make you aware of the dangers of introducing third party tools into your SharePoint environments and to recommend a series of steps to take to help you understand and decide if a third party tool is right for you. Third party tools can and do add real value, but be sure that these tools do not interrupt your core SharePoint environment.

In summary, you must ensure that you have some factual assurances that deploying any third party component is truly going to save you money or provide some other worthy and tangible benefit.

Measures must also be taken by you to ensure that uncertified tools are not going to damage your existing core SharePoint environment and that they are manageable and acceptable costs in terms of support longer term.

Finally, as I posted in the SharePoint Magazine recently, you potentially ‘pay’ for your bespoke changes and arguably 3rd party tools, to some degree, several times over. Consequently, do your homework before you download that evaluation web part and press setup.exe!

Regards,

Andrew

WorkShares Team

Note:

Arno Nel who runs the SharePoint Magazine, published this article on his excellent online magazine about ‘Using third party tools in SharePoint’.

Happy reading and hope you find it useful.

Introduction

How you measure the success of any SharePoint project is open to much debate. The typical metrics of ‘Time, Money and Quality’ are still the main areas most organisations focus on. However, often the true ‘measures of success’ from a SharePoint deployment aren’t actually felt by the business until long after the project team has been moved on to other things.

But with the introduction and importantly adoption of SharePoint into many organisations growing exponentially following the release of MOSS 2007 last year, it brings with it a number of challenges. The delivery of Microsoft’s premier collaborative platform will put one or more of these metrics under pressure during the project life cycle. As any novice or experienced SharePoint, traditional infrastructure or software project manager whom take on the management and delivery of these projects will tell you.

Having spent the last 7 or so years leading successful bid teams to win and then go on to manage the deployment of SharePoint into medium and large businesses, spread across several industry sectors, (and in some cases to help organisations ‘recover’ failed projects), this article looks at the reasons why SharePoint projects can and do go awry.

And in an effort to educate readers through the sharing of knowledge and experience here in this article, it will highlight some areas for you to be aware of and plan for accordingly, so that you can increase your chances of a successful SharePoint project.

Why are SharePoint projects difficult to deliver?

There are many reasons why SharePoint related projects run into difficulty and like any other IT project they fall under the following headlines, well documented by others:

• Poor scope definition
• No inherent project culture within the business
• Poor stakeholder management
• Poor project governance
• Poor project management skills
• Weak planning (for the project and beyond once it has been deployed)
• Lack of proper change and risk identification and management.

However, there are other reasons organisations need to be aware of.

Reasons Specific to SharePoint Projects

In my opinion, here are some of the main additional reasons why SharePoint projects fail to live up to expectations and in particular areas your organisation need to consider and plan for accordingly to increase the likelihood of success of your SharePoint deployments:

Underestimating the scope of the project deliverables

In particular for the medium to large organisations they often fail to plan and budget properly for the enormity of the project deliverables within a typical SharePoint deployment. These are often in areas such as:

• Strategic and operational impact on business practices
• SharePoint governance
• Project team resources and skills
• Planning and design (in particular around those that demand re-branding of SharePoint interface)
• Infrastructure to support both internal and collaborative working externally
• Infrastructure to support appropriate DR, back up & restore capability
• Application delivery, build and test (In particular for deployment with bespoke elements)
• Migration of content or documents from file shares, existing intranet(s) and other line of business applications, (databases, etc)
• Release & change management
• Launch activity and user adoption going forward
• IT helpdesk and user support following ‘go-live’.

Business ‘quick wins’ to demonstrate value

More often than not SharePoint is introduced as a replacement Intranet. Fine, it will do that very well. But businesses forgot to include in their planning enhancements to the intranet features that could give it the ‘wow’ factor when  the users first start to use it.

Such ‘quick wins’ can be relatively minor in effort, but tremendously valuable when trying to gain momentum and secure support from the wider business with its adoption.

Additional ‘quick wins’ should be identified earlier on and planned into a release program following the launch of the initial project to ensure the deployment of SharePoint is a success not just at the beginning, but continues to be so as it is further utilised and deployed within the business.

Short term planning, long term pain

Forget to include long term planning and management of your SharePoint project at your peril!

Businesses often forget to include the long term planning within the initial phase at the beginning, especially around the underlying architecture to support changes in the future. Thus potentially needing to re-invest in significant infrastructure and licensing costs later on when for example you wish to introduce an extranet facility or include another business units content following a business buyout.

It is critical you consider those changes planned for the future now within the SharePoint underlying architecture & infrastructure. This will I guarantee save you money and pain later on!

Lack of SharePoint experience in your project team

Do you use a one of your team members who has never worked with SharePoint before? Or hire a SharePoint developer or SharePoint consultant on your project team, or perhaps both? What about a SharePoint architect, business analyst, web designer or even an experienced SharePoint project manager?

For many larger projects all of these resources are needed and getting this wrong in terms of the mix of roles and experience of resources is one of the major reasons why projects will fail, as project planning and resourcing is badly managed and underestimated by the team at the beginning.

The product feature set is vast and all too often teams are poorly equipped in terms of the relevant team members experience of the product’s core features. It is critical you understand the challenges here and ensure you get the right resources on board. Consider carefully a growing trend with organisations trying to use a a single developer/consultant resource hoping they will cover it all. The chances are they won’t, will struggle to meet deadlines, cause project overruns and in the end it will cost you a lot more to make it right or worse you abandon a sound valuable strategic platform because of a poor initial experiences.

Lack of SharePoint Project Management delivery experience

Often overlooked, but good solid project management experience of SharePoint related projects is worth its wait in gold. Often, IT departments and outside consultancy’s will assume its like every other Microsoft infrastructure related project, which it is not! Neither is it like any other traditional software related project. It is more like something in between, which is why it proves challenging for IT management and existing project managers in either camp to get their heads around the issues and challenges. This is both at the beginning in terms of planning, in the middle in terms of day to day management and towards the end when you are ready to go live and you find yourself having underestimated all the activities that need to happen to make it visible and importantly adopted by your users both from launch day.

Wrong infrastructure and poor architecture

A little forethought here can save you a lot of money & effort. As the SharePoint product spans across intranet, extranets and now public facing web sites, the right infrastructure to support your deployment is crucial for successful delivery and operation.

The end to end design of a SharePoint technical architecture will often need to touch on other technologies such as networks, firewalls, proxy servers, anti-virus and database clustering to name but a few. In addition, capacity planning for your hardware is also important as potentially you will need to  plan for each 1MB of user storage over 3MB (Yes 3MB!) of storage space for your whole environment!

Together with a relatively complicated and pricey licensing model from Microsoft, do your homework and seek advice from a licensing partner on this area before your commit your budgets and commence your project.

Customisation or Configuration?

I will describe ‘customisation’ is essentially an activity whereby a SharePoint developer deploys bespoke code within a SharePoint environment. Whereas ‘configuration’ is the manipulation of existing ‘out of the box – (OOB)’ features to meet your needs.

Many organisations will opt for the former as they don’t know the latter well enough and assume they have no choice.

SharePoint in all its forms is a very pervasive technology and being able to support the environments both from launch to decommissioning/migration is key. The feature set is huge, hence understanding what you can do out of the box with the product is difficult, if not impossible for one individual resource to know. But that doesn’t mean you should turn to custom development, moreover you need seek further input and if need be bring in the right skills and experience of those that do understand how to get the most out of the platforms’ array of features, before you commit to development resourcing on the project.

Having the experience to know when to use custom development is important because remember you pay for your custom changes several times and not just the few days of developer time for a minor enhancement that doesn’t seem to be there out of the box. Namely you pay for the following:

1. Initial bespoke code

2. Testing when service packs or ‘hot fixes’ come along that may break your bespoke code (could be several times in the life of the platform)

3. Finally, when you migrate to the next version of SharePoint or new product and the migration tools don’t like your bespoke work as its not supported.

Custom development definitely has its place however, but do not underestimate the effort it takes for even your best developers to come up to speed with the inner workings of SharePoint. Key areas for your developer training budget are that of branding, workflows, forms, BDC and solution deployment, as these are the main areas which crop up as being the more challenging than you perhaps expected or planned for.

So, do you really customise SharePoint or configure? Will the customisation you are about to embark upon really be worth it? Really think this through before you open up your SharePoint environment with Visual Studio or SharePoint Designer. Quite often its easier and hence cheaper to modify the business process or to leave out the functionality entirely. On this point I have witnessed all too often a bespoke function not available out of the box, then be custom built at great expense, only for it to be rarely if at all used by the end user!

Poor planning for user adoption

There is little point in designing and deploying the best, most detailed SharePoint solution if from launch date the following happens:

1. Very few users can access it
2. Those users that can, aren’t able to find information or use it very well
3. Those users that can’t access it that eventually do, don’t go on to then use it nor reap the benefits of collaborative working
4. Your training plan and users awareness is poorly delivered.

Planning for ‘launch and user adoption’ and the results of this are key to the perceived success of the project, more so than just the usual time, quality and money metrics. This revolves around planning, stakeholder management and user awareness, be that in form of training or briefing to them of the new ways in which to enhance and improve how they work and make their jobs easier.

Businesses should provide a long term engagement plan of objectives highlighting key deliverables, potential budgets and key milestones for enhancements to the proposed solution, following the initial launch.

Conclusion

This article has highlighted issues organisations already deploying SharePoint will have come across and indeed these existing and new SharePoint deployments will face difficulties in some or all of the above, as a consequence of lack of experience, poor decision making or expectation management with the business sponsors.

So what do organisations do to avoid many of the issues raised in this article. Quite simply, if you can start small do so (don’t run before you can walk so to speak) and get to know the vast array of features and functions available out of the box with the platform. Do not let loose your developers on a project until you have fully explored the rich feature set provided out of the box and established that the end result is really worth it to the business, when all costs (short and long term) associated with custom development are weighed up.

If you’re planning a large deployment then plan, plan and plan some more. Review your approach carefully and seek the knowledge and wisdom of others whom have done it before whom know the pitfalls and have learnt the lessons before you commit your resources.

Finally, it’s worth considering getting specialist advice from the outset from those who have been there before and can help your organisation through this period of change. Hopefully these small pieces of advice will help you ensure your project are successful, allow your users to reap the full benefits of SharePoint and enable your business to get on with doing what you do best.

If you do go external for such resources then ensure appropriate levels of knowledge transfer take place to your staff during ALL phases of the project and not just at the handover!

Andrew Walmsley

Director – WorkShares Limited © 2008

I like Adam Bruenz post here which is entitled ’When-Best-Practices-Aren’t-Best-Practices’, which provides a interesting and thought provoking view, and is a topic that is increasingly prevalent on many blogs in the SharePoint community – SharePoint Best Practices.

In short, you should not implement ‘Best Practice’ methods even if they have the mighty Microsoft name to them, until you have weighed up the pro’s and con’s of it.

Just because so called leading bloggers say you should do it a certain way means you have to, you don’t. But you should understand why they say they are the best way to do a certain task or take a particular approach.

Remember, they may not have worked in your industry or you may not have the same level of resource or skills levels needed to support such approaches or importantly they might not have experienced your type of organisational ‘cultural challenges’ when defining the best practices.

In SharePoint world, its rarely as straight forward as it seems. So do your homework first!

Regards,

Andrew Walmsley

Practice Manager/Director

WorkShares.

Introduction

Winning and delivering a successful SharePoint project is something that takes time to master, but even then will present experienced SharePoint Project Managers(PMs) with a few surprises along the way. As discussed in the previous article, delivering successful projects can and will be challenging.

This article continues on this theme, but looks not at the challenges PMs face, but presents a view on the background your PMs will need  to help ensure SharePoint projects are successful in the future. This is particularly key for system integrators but also your medium to large business that have these skills in house.

Where we have been & where we are now

Historically, Project Managers delivered traditional client/server infrastructure based solutions such as Exchange, Notes, Novell, Active Directory, or desktop migrations and required a somewhat different skill set to that of Software Development Project Managers, whom delivered bespoke ASP or .Net, Java applications and such like. There are others arguably to a lesser degree in terms of their roles and technical exposure, hence I would described PMs backgrounds of the past and to a large extent present, as having one of the following traits:

1. Infrastructure – Your typical Infrastructure PMs are likely to be former consultants whom have worked on such projects or have a track record in IT Support
2. Software Development – Your typical ‘Software Dev PMs’ are probably a former developer/analyst who have moved into this role and to some extent may still ‘cut the code’ as well
3. Existing Consultant or Developer – Those whom still provide core consultant or developer roles, but mix in some PM type skills
4. Business – Little or no technical ‘hands on’ skills, but may have manage several business driven projects within the business.

Where we will PMs need to be in the future?

It’s well documented by others and in summary here, that the SharePoint product features are vast and the skills needed by a team (yes, notice I didn’t mentioned an individual here!) to design, deploy and support a SharePoint environment (medium to large businesses) are significant and will not be held within one individual, (those whom purport to say they do should be escorted off the premises and are simply not credible!).

So its with this view in mind, that I think SharePoint Project Managers of the future will potentially need a blend of all the above traits mentioned, but realistically that person does not exist.

I think in future SharePoint PMs will need to have a background in BOTH 1 and 2 above. If they are from either one area, be prepared for some mistakes as they get to grips with the different challenges that they will not have experienced previously in their other roles. This will be in areas such as budgeting, large farm deployments, release management, migration, accessibility, web design, and deployment.

Those whom sit within 3 will I think continue to struggle (to the projects detriment) to handle such a multi-faceted role as the project scope and duration gets to big for them and will need to make a decision where their career/ambitions lie in terms of the role they wish to focus upon. The simple reason being is that SharePoint is too big now to keep up with in overall in detail, let alone what it will be like in the next release.

Those in area 4, well, it’s going to be a very very steep learning curve and an expensive one! Arguably businesses should not put important projects into the hands of such individuals and is asking for trouble. Though I hasten to add such resources are still valuable and can be used on SharePoint projects. Especially when you are defining your launch activities, user adoption and overall governance. Such experience, awareness and knowledge about key sponsors, cultural challenges and business processes is a critical element of your planning.

Regards,

Andrew Walmsley

Practice Manager/Director

WorkShares

www.workshares.co.uk

I wrote an article and published it over on the recently launched ‘SharePoint Magazine by Arno Nel.

With the growing interest in deploying SharePoint (MOSS and WSS) across all manor of businesses and organisations, the article looks at the general topic areas they should look into to avoid disappointment and ensure their investment reaps the expected rewards.

Drawing upon 7 or so years in winning and managing SharePoint projects into medium to large businesses, hopefully you will find it a useful ‘heads up’.

Regards,

Andrew Walmsley

Director

WorkShares

www.workshares.co.uk

In addition to this article I wrote recently, SharePoint Consultant/Developer Required….No!, I also responded to a posting on the ever popular LinkedIn site called ‘What skills are you looking for when hiring/recruiting a SharePoint Consultant?’.

Since receiving positive comments from others following this posting, it has be referred to in others work, including that of the white paper by Julie Pfahl, of Syntapa.

An interesting and although not exhaustive piece of research, nevertheless does highlight some important considerations businesses need to work through as part of their resource planning for a SharePoint based project.

Regards,

Andrew Walmsley

Director

WorkShares

If you use Microsoft’s SharePoint Services, you’ll be pleased to hear there are simple and affordable ways of taking your content offline, perhaps for your remote workers.

A much unheard of, but in my view powerful collaborative feature is that of Outlook 2007’s capability to  take anything in a SharePoint list or document library  (they are for all intents and purposes one in the same) offline and sync up upon your return to the office.

Simply pull the drop down ‘Actions’ option from the list or library concerned, select ‘Connect to Outlook’ and follow the instructions:

You will be asked basically to confirm your request:

And after syncing, your documents will be located inside Outlook for you to take away, update and or just read.

You do need to be using Windows SharePoint Services version 3.0 AND Outlook 2007 for this to work, but is I think I great partnership for people whom work away from the office a lot.

Other tools out there are available at different prices/functionality including Colligio’s ‘free’ reader only product – nice for just viewing content offline.