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:
- Very few users can access it
- Those users that can, aren’t able to find information or use it very well
- 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
- 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
Tags:
LinkedIn,
MOSS,
SharePoint,
SharePoint Architecture,
SharePoint Project Management,
WSS MOSS,
Miscellaneous,
SharePoint,
SharePoint Governance,
SharePoint Resourcing,
WSS,
WorkShares
by Andrew Walmsley |
2 Comments
Are the executive, steering group or IT dept. who signed off on the project happy with the financial cost savings or delivery in general? I suspect quite a few responses would be not so positive, decisive or along the lines of ‘could have gone better’.
…
