Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
What are the top 3 mistakes often made when managing SharePoint?
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
6 Answers
1. No clear business objectives, goals, or benefits being achieved as a result of using SharePoint.
If you can't easily prove (or clearly show) that SharePoint is providing business benefit it will not be possible to get the resources you need to manage and make SharePoint an effective technology investment. Additionally by having clear business objectives being achieved through SharePoint solutions it can help guide prioritization of SharePoint tasks, indicate how critical SharePoint is to the business (for planning IT support/infrastructure), and lead to strong adoption (since it's actually solving real problems).
This is actually extremely easy to do, but is the number one thing missing from most deployments that has the biggest impact on SharePoint's success and certainly directly impacts the management of the platform.
2. Assuming its simple or underestimating complexity.
It's one thing to not plan for enough resources due to lack of understanding the business impact and implications of introducing a new technology. It is another thing to read all of the guides, recommendations, and cautionary tales about SharePoint and still not associate key resources or have key planning in place. Here are a couple of the most common 'thoughts' I have seen which lead to trouble.
- "We don't need to plan or worry about things to that level yet, since the first iteration, release, or phase will be extremely simple. We are just going to roll out an Intranet and some team sites. We won't use the advanced features..."
- "First let's see how people use it by just releasing it, and then begin planning for Governance and steering it towards some business goals that bubble up."
- "We can install and implement it, and then just run a small pilot. There is no need to worry about all of those other factors yet because our initial group will be small and controlled."
A danger of the first quote is the assumption or underestimation that rolling out a new Intranet or Team Sites is a simple matter/project. These projects can be very complex and the scope is not nearly defined enough. The quoted individual should not feel comfortable without more planning and understanding.
A primary danger of the second quote is that it assumes users will know what SharePoint is, how to use it, and why they should use it. This is ineffective. The idea of soliciting, measuring, and validating feedback to guide future work is always a good one, but to rely on users to determine best uses for a technology is a bad practice.
The last quote is dangerous only if the pilot isn't well planned and tightly controlled. It's also important to note that many of the biggest benefits SharePoint provides are at an enterprise level in creating consistency, breaking down information silos, and connecting disparate groups. All of which is extremely weakened when piloted to a small portion of the enterprise.
3. Saying yes to everything.
This sounds simple and obvious, but it's worth noting as the third big mistake with managing SharePoint. The obvious truth here is that you just won't have the capacity to say yes to everything. What follows are three brief harder to understand 'truths':
- Sometimes you shouldn't say yes to using/leveraging SharePoint for a solution because it isn't always the right platform or technology.
- Sometimes the organization or business unit asking for a SharePoint solution isn't mature enough, or disciplined enough for that solution to be effective. It's extremely important to be practical minded when implementing SharePoint solutions.
- Hiring for SharePoint is extremely difficult in this marketplace. So if you assume you can say "yes, but we need to hire more people" that isn't always a practical answer. I suppose you could say "yes, but we need to find good consultants to augment our internal capacity" (it always makes me and our business happy), but this can also be impractical when you consider the consulting costs.
Hope this helps.
TOP 3 is a tricky one to boil down .. I would suggest these are a good start:
1) Not planning enough from day 1.
This is true I think for most SharePoint implementations I have seen over the years.
everything from adoption strategy, to governance plans, and even the "basics" like branding, information architecture and logical topology.
This can lead to all sorts of pain, especially in the capacity / scalability planning bit..
2) Managing expectations.
Probably the hardest nut to crack .. some people expect it write their documents and then read them back to you (and make the coffee at the same time).
Other people I've run into say "I don't like SharePoint" or "it's not very good" even though they've never even seen it running since 2003!
Even worse are the users who know what SharePoint can do, and expect every single feature turned on at the first attempt.
Getting expectations right can drive better user adoption, help to drive self-promotion of the platform and battle the good old "cultural change" issues that always crop up with any new system.
3) Placing too much importance on hardware costs
Time and time again I see companies complaining about hardware costs .. and they sacrifice their system quality as a result.
"surely we don't need 32GB on SQL .. lets see if we can manage with 16GB?"
"are you sure we need three WFE servers? How about we put in two for now?"
These kinds of conversations drive me mad for 2 reasons:
a) You usually spend more consultancy money in meetings that you actually save on hardware
b) hardware typically makes up no more than 20%-25% of the total project cost.
If you compare it to the implementation (requirements, consultancy, user workshops, infrastructure builds, software licenses, development cost, testing, capacity planning, implementation, training, support, administration and ongoing operations, monitoring, publishing, firewall and gateway setup?) then the actual physical production servers are a fraction of the total project cost.
The end result is a system that is too slow, can't handle new features being installed down the line, and needs upgrading every few months because it is too close to capacity.
The net effect of all those mistakes above?
Failed project ...
"SharePoint is a poor product because it is slow, needs rebooting all the time and can't handle many users. It doesn't do what I wanted it to do / I don't understand why we need it .. and it ends up in a mess after 6 months"
but then .. hindsight is always 20:20
Applicable to large organisations :
1. Lack of Ownership
So much time is spent fighting about who owns SharePoint and why, that it takes ten times longer to achieve anything. Make a decision, stick to it, and get the job done. The owner needs hire/fire power and signing rights. It has to be an operational type person who can make decisions in very quick time.
2. Not having a central SharePoint team and budget
So much more could be achieved on the platform if there was a dedicated team and budget to manage and maintain it. All the finger pointing about who does what and when and why is extremely counter productive to collaboration. Business complains endlessly that there are no support mechanisms in place for SharePoint. If you have a large organisation, you need a dedicated team. Fighting about who pays for the training, add-ons, space etc is also an endless war. A central budget will resolve that.
3. Not having a user adoption plan
It needs to include governance, communication, training and support. People are not just going to magically adopt SharePoint. And if you do succeed in your adoption plan, you need systems in place to manage the influx of requests that will come in for all types of things.
I agree with the answers above, and would like to add one more:
Underestimating the Resources Required for Maintaining Momentum-
SharePoint will likely take off like a grass roots movement. Everyone will see it and everyone will want it. If your team is not scoped properly this could cause some issues. In the beginning it will be easier to go slow and allow for proper process but as time passes and need rises I often see organizations “speed things up” and that seems to cause a lot of future issues.
I agree with the answers above, and would like to add one more:
Underestimating the Resources Required for Maintaining Momentum-
SharePoint will likely take off like a grass roots movement. Everyone will see it and everyone will want it. If your team is not scoped properly this could cause some issues. In the beginning it will be easier to go slow and allow for proper process but as time passes and need rises I often see organizations “speed things up” and that seems to cause a lot of future issues.
Number one issue that I've seen is the lack of a governance plan, Martin already touches upon this, but I'd like to re-emphasize. In those organizations that done plan for Governance, SharePoint typically grows more like a weed infestation. That shouldn't deter you from implementing SharePoint properly with proper Governance. If anything that statement should deter you from becoming a cowboy and implementing SharePoint in production.
Your Governance Plan does not have to be perfect on day one, but should be a document or series of documents that outline the rules, policies and procedures that individuals and groups should follow.
Just so you know, SharePoint Governance does not have to be just a collection of papers it is also how you put that guidance to use in SharePoint, read my Practical SharePoint Governance for Everyone for some ideas http://spbuzz.it/mbRRhE
Answer This Question