Every day I speak with CIOs, and the feedback is always the same: “Carl, we have spent so much time and resources on SharePoint, and we still don’t have a product we can use.”
Here are: 7 Common SharePoint Roll-out Mistakes
Mistake # 1 Lack of Planning and Goals
You can’t build a bridge without a plan and goal in mind. The same is true for SharePoint. You can’t roll out SharePoint without first factoring pros and cons into your decision.
SharePoint requires an extensive amount of planning before, during and after its deployment. The first part of planning starts with understanding how SharePoint will be used and what problems it will solve in the short term and long term. For example: Human Resources is always looking for solutions to help them improve onboarding and offboarding.
If you’re not sure how you are going to use SharePoint, you will fail. Your goals should be small and easy to obtain in a short time. Too often, organizations have long multiple-year plans for SharePoint without proving its return of investment in the short term.
Mistake # 2 No Documented Governance
No one likes to spend hours on documentation no one will read, but the purpose of documenting your governance plan is to have something to fall back on as users start to use SharePoint. Governance will cover who had access to what, how your sites are played out and who is responsible for documents and content. Without a governance plan, your site will come out looking like the Wild Wild West.
Mistake # 3 You Didn’t Ask Your Users What They Want
Often only one or two people are pulling the strings with SharePoint, leaving the rest of the organization out of the decision-making process. This will ultimately have a bad impact on your rollout. Ask users what would help them be more productive. You will be amazed at the answers you would receive from them. You don’t have to promise them everything on their wish list, but they will appreciate you listening to their concerns.
Mistake # 4 No Internal Marketing and Insufficient Training
If you wait until the end of the rollout to inform and teach your users about SharePoint you have already failed. It’s best to send out weekly updates to department managers and have your SharePoint team create a duplicate SharePoint site ahead of the rollout so users can start training.
Mistake # 5 Lack of Leadership/Sponsorship
In order for you to have a successful SharePoint rollout, someone’s got to own up to it. Ideally, senior management should play a large role in pre-rollout meetings and its direction for the company. IT should not be the only one in charge of SharePoint’s direction for the company. One of the very first steps is to establish steering committees that will focus on SharePoint’s role and progress. The steering committee should meet regularly even after SharePoint has been rolled out.
Mistake # 6 Underestimating SharePoint’s Cost and Power
SharePoint is sometimes confused with its counterpart, Microsoft Office. So many times I hear, “Users don’t need directions because it’s just Microsoft Office. It’s easy.” SharePoint works extremely well with Microsoft Office, but it is not Microsoft Office. SharePoint should be treated for what it is: an ECM system. SharePoint is also like an octopus with many tentacles to your enterprise resources like Active Directory, Exchange, network drives and Domain Controllers. Care and planning should take place to ensure all of your resources work together smoothly.
If you have not budgeted to have at least one dedicated SharePoint (size of SharePoint team depends on size and scope of organization, goals, etc.) resource to manage your SharePoint farm, just forget it. Stop now. SharePoint requires a resource that is skilled in its administration, security and development. A big mistake organizations make is asking the Windows server administrator, who is already overtasked, to be their SharePoint resource too. If your organization is new to SharePoint, your first step should be to hire a SharePoint architect to lay the groundwork and provide the proper guidance.
Mistake # 7 Creating an Unrealistic Project Plan
A few years ago there were loads of SharePoint consulting firms pushing aggressive 60- or 90-day SharePoint rollouts. The only people that benefited from these rollouts were the consultants who sold unsuspecting organizations on thinking they would be able to rollout SharePoint in under 90 days (size of organization, goals and deployment schedule will be a large factor). Technically you can configure, setup and integrate SharePoint in 90 days, but that’s only 20% of what’s involved. A significant amount of time and resources should go into planning, topology and metadata mapping, training, auditing your current environment and working with departments to insure the organization’s needs are met. Depending on how fast your organization works, that process alone will take 60 days. When creating your SharePoint plan, layout dependencies, add buffers for meetings, quality assurance, configuration management and training.
Over the years, I have seen some pretty horrific enterprise projects, and they all had one common denominator.
I’m coming from Salesforce and SharePoint background, but the same problems exist in just about any case where an application has to be built based on requirements.
It’s the same scenario each and every time. Sales people work extremely hard to set meetings with senior management and the C-suite to better understand their technical needs and challenges.
After months of proposal preparation, slide decks, and meetings with senior management on both sides, a deal is now on the table, and the only part left is an approved statement of work (SOW). From the vendor’s prospective, this is great news and well deserved after all the hard work and time put into the opportunity. All the heavy lifting is done, and the vendor can go on to the next pursuit. From the client’s perspective, this opportunity will potentially solve a business need or problem, and this vendor is now considered their trusted advisor.
From the perspective of the architect, who was informed about the decision at the very end, it’s an uphill battle to understand what was said versus what is realistically possible while keeping both sides happy.
The architect’s responsibility is to put all the pieces together to come up with a solution that meets or exceeds the agreed-upon requirements. In most cases, this is quite a normal task, but in other cases, it is impossible. Here is why: the architect was not involved in the initial stages of the sale, and the vendor’s sales team oversold the software’s abilities to the client.
Some organizations have “technical” sales teams who are proficient in the art of sales and SPIN, but they lack the technical depth required to understand the client’s needs and meticulously map the need to the appropriate enterprise solution. The expectation is that everything will fall into place, and/or the architect will perform some magic to make it happen. Unfortunately this not how it works.
If the architect is included in the early stage of negotiations, he or she can advise the sales team on the risks associated with each approach. More importantly, the architect will advise if the opportunity is worth pursuing at all. Understandably, time is of the essence, and you don’t always have time to vet every opportunity, but even taking an architect with you to early-stage meetings will make a huge difference and save lots of backpedaling later. In CIO Straight Talk, Barry Libenson, CIO of Land O’ Lakes, puts it this way, “Anytime you have to go back to a contract [with a supplier] and start talking about terms and conditions that were negotiated a year ago, I mean, that’s a bad day.”
Another reason to involve an architect early into the project is that he or she can identify opportunities that may have been missed. An architect is always thinking about how everything will come together and asking questions (technical and/or functional) that help paint a picture of what the end solution will look like.
The excuse given by sales teams is “early sales meetings with the client are not technical and don’t go into the how.” All the same, the sooner you can have the “how” discussions, the better off you’ll be. Waiting until the very end, after the SOW/contract, is dangerous and only creates problems for the implementation team. By the time the SOW/contract is signed, the “how” and design should have been figured out.
In closing, before working on that enterprise application project that is going to revolutionize how the client does business today, think about the architect and implementation team that have to turn magic into reality.
Do you have a story about doomed enterprise project? Please share.
Over the years I’ve seen some pretty bad SharePoint implementations. Some was the fault of the consulting company, some was the fault of the organization. Each of the implementations had the following in common:
- Unrealistic Goals and Requirements (too much, too soon)
- Limited Budget
- Jack of All Trades , Master of None Consultants
- Lack of Corporate Involvement
- Lack of Corporate Communication and Adoption
- Undefined Governance Plan and Strategy
In “Implementing Compliance and Governance with SharePoint” I discuss how to take SharePoint serious as an organization and design a governance plan that is aligned with your corporate governance and compliance plan. Each chapter provides real world solutions on how to resolve SharePoint’s security and governance shortcomings. Implementing Compliance and Governance with SharePoint will be available for purchase and download in March 2015.
Table of Contents
- About the Author
- Chapter 1: Introduction
- Chapter 2: Aligning SharePoint with Organizational Goals and Requirements
- Chapter 3: How to Create a Successful Governance Board
- Chapter 4: Auditing your Current SharePoint Permissions
- Chapter 5: Understanding Document and Record Compliance
- Chapter 6: Aligning SharePoint with your Data Loss Prevention Program
- Chapter 7: Developing a Strategic Governance Project Plan
- Chapter 8: Building a Successful Training and Communication Program
- Chapter 9: How to Get a Grip on your SharePoint Environment
- Chapter 10: Building a SharePoint User Adoption Plan
- Chapter 11: Repair Damaged Credibility and User Moral
- Chapter 12: Understand SharePoint Search
- Chapter 13: Protecting Documents and Records with Rules and Permissions
- Chapter 14: Understanding Digital Signatures and Document Encryption
Set Expectations Early
To your users, SharePoint is this large system that can do many things for their department. You want to set the expectations early on what the organization will support and what the users will be able to do with SharePoint. If possible, involve your executive sponsor in meetings to highlight his or her support and the importance of SharePoint to your company.
Don’t Overwhelm the Users
SharePoint role outs are normally handled by IT and what is easy for an IT departments to understand may not be so easy for, say the Human Resources administrator to understand. Start with the basics and build from there.
If It’s Not in SharePoint OTB (out of the Box), We Don’t Need It Right Now
As mentioned in the previous point, start with the basics. Once users have utilized all the features of SharePoint OTB, only than is it a good time to think about customizations and 3rd Party tools.
Be Clear About How Users Are Measured
Make sure users understand they are responsible for SharePoint’s health. For example set deadlines on when documents and records should be uploaded and tagged in SharePoint.
Answer The “What’s in It for Me?” Question
Don’t just make demands—get people excited as well. The best way to do so is to show how SharePoint will make life easier—for example, with greater access to documents, easier to find using documents using search, and the ability to create Apps without waiting for IT.
Provide Hands-On Training With Real-Life Scenarios and Information
Don’t tell users to go to YouTube to find SharePoint tutorials. Instead create in-house SharePoint videos using real employees and real user cases. For example, HR could create a screencast called “How I use SharePoint for onboarding new employees”.
Create and Reinforce Processes
Treat SharePoint as an opportunity to roll out more effective processes that makes life easier for users. For example, because all document live inside of SharePoint it is now easier for documents to follow the corporate life cycle for proposals (draft to final).
Help Users Learn the Lingo
Create cheat sheets with SharePoint terminology, simple overviews of your processes, and step-by-step summaries of the most important features like tagging and content types. These job aids will serve as handy, easy-to-use references.
Motivate your users to dive right in with contests, incentives, and a little competition. For example, you could award a $200 prize to the first users to complete all the metadata tagging for the 100 documents that have been uploaded in the last week. You can also use a leader board in a SharePoint list to show how individual users compare in adoption to generate some healthy competition.
To get off to a good start, it’s important to clear up any assumptions and to find out what’s on your users’ minds. Remember users will be the ones spending up to 8 hours a day working in SharePoint. Their feedback is very important and should always be considered.
Provide Constant Follow-Up Training
Some people think you train users once and you’re done. But successful training isn’t a one-shot effort. Be sure to follow up after a few weeks because by then, your users will have a new set of questions. A great way to provide follow-up training is to recruit enthusiastic power user’s to follow up with their peers and use what they find out to create highly targeted lunch and learns for various user groups.