How you measure the success of any SharePoint project is open to much debate. Your typical tangible metrics around how a particular project has performed in terms of Time, Money and Quality, are still the main areas are what most organisations focus on upon to gauge their ultimate success. This is irrespective of whether or not the true ‘measures of success’’ from a SharePoint deployment aren’t actually felt by the business until longer 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 over since the release of MOSS 2007 last year, it brings with it a number of challenges to say the least. The delivery of Microsoft’s premier collaborative platform, SharePoint, will put under pressure one or more of these metrics during the project life cycle, as any novice or experienced SharePoint, traditional infrastructure or software project managers 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 deployments of SharePoint into large and small 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 increase your chances of a successful SharePoint project.
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:
However, there are other reasons that organisations need to be aware of.
Here are some of the main additional reasons why SharePoint projects fail to live up to expectations and in particular areas your organisation needs to be aware of 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 that feature in SharePoint deployments.
These are often in areas such as:
Business ‘Quick Wins’ to demonstrate value
More often than not, SharePoint is first introduced as a replacement Intranet. Fine, it will do that very well. But often businesses forgot to include in their planning, enhancements to the intranet that could give it the ‘wow’ factor when the business first starts to use it.
Such ‘Quick Wins’ can be relatively minor in effort, but tremendously valuable when try to gain momentum and secure support from the wider business that the adoption of SharePoint within the business is more than just an intranet replacement solution. They are more aligned to a different way of working for the business which should be one of the strategic objectives is much more than this and are key to business adoption.
Such ‘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 potential changes in the future. Thus potentially needing to re-invest in significant infrastructure 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 whom has never worked with SharePoint before? Or hire a SharePoint Developer or SharePoint Consultant on your project team, or perhaps both…?What about SharePoint Architect, Business Analysts, 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 around resourcing is badly managed and underestimated by the team at the beginning.
The product feature set is vast and all too often project teams are poorly equipped in terms of the relevant team members experience of the product core features, including the underlying infrastructure to support the larger implementations. It is critical you understand the challenges here and ensure you get the right resources on board and consider carefully whether or not to use 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 experience of managing 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! Nor is it like any other traditional software related project either.
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 have underestimated all the activities that need to happen to make it visible and importantly adopted by your users both from launch day and beyond.
Wrong Infrastructure and Poor Architecture
An area often overlooked, but be warned a little forethought here can save you a lot of money/effort. As the SharePoint product spans across both intranet, extranets and now public facing web sites, the right infrastructure supporting SharePoint users 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, ISA servers, anti-virus software and database clustering to name but a few. In addition, capacity planning for your hardware is also important as quite often you will need to potentially plan for every 1MB of user storage, over 3mb (yes 3!) of storage space for your whole environment!!
Together with a relatively complicated, and costly licensing model from Microsoft, do your homework 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 handwritten code within a SharePoint environment, whereas ‘configuration’ is the manipulation of existing “out of the box – (OOB)” features to meet your needs.
More often than not, many organisations will opt for the former as they don’t know the latter well enough and assume they have no choice, but this should be counselled against doing so without proper consideration of the impact and risks.
MOSS/WSS are very pervasive technologies and being able to support the environments both from launch to decommissioning/migration is key. The MOSS/WSS 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, more you need seek and if need be to 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.
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. Particular areas for your Training/R & D efforts are that of SharePoint branding, workflows and how you deploy your solutions, as the three main areas which crop up as being the more challenging than you perhaps expected or planned for.
Hence, having the experience to know when to use custom development is important because remember, you pay for your custom changes several times, 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:
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 next version of SharePoint or new product, and the migration tools don’t like your bespoke work as its not supported.
So, do you really customise SharePoint or configure…? Will the customisation you are about to embark upon be really worth it to your business needs? Really think this through before you open up your SharePoint deployment with Visual Studio or SharePoint Designer. Quite often its easier and hence cheaper to modify the business process or to leave out the functionality altogether. On this latter point I have witnessed all too often a bespoke ‘function’ not available out of the box, 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, very few users can access it, those that can can’t seem to find information or use it very well and those that can’t access it that eventually do, don’t go on to then use it and nor reap the benefits of collaborative working.
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/money metrics. It revolves around planning, stakeholder management and user awareness, be that in form of training or briefing them of the new ways in which to enhance and improve how they work and make their jobs easier.
Businesses should have a longer engagement plan of objectives, deliverables,budgets and milestones for enhancements to the solution following the initial launch. Such long term planning is often missed.
This article has highlighted many issues organisations deploying or are about to will come across and indeed, many organisations 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 simple, if you can start small (don’t run before you can walk so to speak) do so 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 however, plan, plan and plan some more, review your approach carefully and seek the knowledge and wisdom of others whom have done it before, 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 that have been there before and can help your organisation through this period of change and allow your users to reap the full benefits of using Microsoft’s SharePoint collaborative platform whilst allowing your 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
Andrew Walmsley is an established UK based SharePoint Project Manager with significant experience of winning new SharePoint business and has been involved in a lead capacity with in excess of 100 SharePoint projects over the last 8 or so years. Spread across public and private sector businesses, many project have gone on to be turned into case studies by Microsoft. My current role is that of Practice Manager at WorkShares, (www.workshares.co.uk), focusing on developing new business, pre-sales, scoping and time permitting, managing the delivery of SharePoint projects for our customers.
Contact the author | Other Posts by Andrew Walmsley (2) | Author's Website
Loading ...
