Disclaimer: SharePoint Deployment Disaster posts is to apply learning from various client deployment scenarios. No SharePoint Farms were harmed in the process of doing these SharePoint deployments. Any similarity with your SharePoint farm is purely coincidental.
IMHO, working with SharePoint isn’t less than poetry. SharePoint let you work on Next Important Productivity Idea instantly and convey a meaning to your idea in much expansive way; pretty much the way I look at the poetry.
SharePoint helps you align many of your critical business processes easily. I have seen Clients getting Super Excited while showcasing them SharePoint prowess and possibilities. As pre-sales consultant, that’s part of my Job Description to influence purchase decision, but as someone responsible for establishing the right ROI for clients’ expenditure – I have also been part of “Too costly confusing licenses” ranting towards the end of projects.
You could leverage SharePoint in many possible business scenarios – from content management needs to creating an intelligent social enterprise. SharePoint can be customized to any degree and any extent. But, this flexibility has relative merits. SharePoint let you get overwhelmed by the possibilities it could create. With every new project deployment, there’s always a SharePoint lesson that you get – irrespective of your flying-experience with SharePoint.
As a SharePoint services provider we all do our share of mistakes and then we learn from them; at least that’s what we claim in our PowerPoint to prospective Services Clients. Yes, Best Practices too are overrated. There’s no 1, SharePoint Way for successful deployments and I had some close calls where SharePoint could have been a “The Road Not Taken” for clients. Thanks to the Force of brilliant and talented teams, SharePoint was conquerable.
Scenario -1: New SharePoint Deployment for an Intranet. Intranet was built using an open source platform. End users weren’t very pleased with the feature-set of their Intranet. The users wanted to get out of wrath of privileged IT department to be able to upload documents, share documents and take backups in addition to many wish lists.
We pitched SharePoint based solution and helped client team envision “How” new intranet could create value. We did a very basic and dirty Proof-of-Concept to help decision makers look at the technology. This also helped in setting expectations with new upcoming intranet.
We helped client team with Purchase decision and facilitate communications with Microsoft but we assumed that IT department will able to drive *user adoption* as they were pretty conversant and technically enabled.
We missed the element of adoption planning and that gave us some real challenging time towards the project end as there were mismatch expectations everywhere. As service provider we were immersed into SharePoint world and failed to apply basic common sense of hand-holding client with this change. It was one BIG change for client. We should have had a parallel ongoing consulting project along with the deployment. This could have helped us in delivering and communicating value simplistically.
During project post-mortem; we realized value of SharePoint Deployment Planning Services (SDPS). Most of our clients were large Enterprise with coupons which could be utilized as SDPS. As service provider, it gave us a comfort factor to meet a part of opportunity costs and do a deep dive assessment and deployment planning right at the start. SDPS sessions are very well organized. It helped us to meet many secondary stakeholders and identify power users and early adopters from the Enterprise User Crowd.
Scenario-2: Migration from Lotus Notes to SharePoint. Client team saw value in Microsoft Enterprise Agreement and it was an easy ride for them to establish an ROI on new technology stack. Our services were required to do the migration from Lotus Notes to SharePoint.
Migration is always tricky and when it involves the promises of improved experience to user – you are in line of receiving many unseen fiery emails and a part of famous corporate game – “Game of Blames”. Given our experiences, we were risks aware and we did what we called an Audit of Content. Existing taxonomy and information architecture was documented and we created a customized roadmap for migration of enterprise contents, business processes, knowledge repository and many other critical elements of Lotus Notes based system.
Given SharePoint’s limitations of out-of-box migration – we were exposed to two huge risks:
- Data Integrity, permissions on files, existing links and references were many – What-if we fail the test of Consistency of data and loose out to complaining users and critics of “New Tech doing more bad than good”, and
- The moment of truth – Switching from Old to New Platform maintaining business continuity.
Firstly, Our approach missed the fact that Content Re-organization will be a continuous process in the new platform. We stick to the One-Shot Strategy to reduce the impact of migration on the content. In short, we were looking at the end user delight and minimize complaints of “Content not found or organized”.
Secondly, SharePoint migration is trickiest of all SharePoint based deployment. Migration is function of both time and effort. As a services company, you are always expected to do an upfront assessment of effort and time. What you can always best have at the start is an approximation. Our Content Audit report had a list of Assumptions and we kept on validating them throughout the project reviews. Clarity on assumptions brought more communication with client team and also helps establish the end-result expectations. But, for us to make Profits on services engagement which involves migration – it’s best to have a Migration partner with you.
Yes, Each partner product has their merits. Our assessment of the situation and deep-dived knowledge of Partner tool helped us turn around the migration work within the time frame and expected effort. Always have an expert either as a part of your team or as a partner – to deliver on values which SharePoint as a platform is actually procured to do.
Thirdly, SharePoint could provide business a strategic advantage. For Delivering SharePoint success, you need to know the Challenges which you are trying to eliminate from Enterprise. At the same time you need to know SharePoint in-and-out to connect to the right approach and solution.
Like any other packaged software platform, SharePoint too has its limitations. It’s important that you understand clients’ Purchase Decision and invest some quality time doing Planning Deployment.
With SharePoint, never assume that Adoption happens. Adoption should be one another important focus while doing the deployment planning. In isolation neither deployment nor adoption will give you a healthy SharePoint farm.
When you were doing SharePoint deployment, did you end up quite where you thought you would end up?