Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Causes for Failures (or partial failures) of SharePoint projects

  Asked By: Krista    Date: Feb 28    Category: Sharepoint    Views: 1443

I was just wondering, what are people seeing for reasons for failures of a SharePoint project (or partial failures). Here’s my list, they’re not exactly exclusive and it’s definitely not exhaustive…

Bad Expectations – They’re expecting a silver bullet so no matter how good the product is it won’t measure up.
Document Management – “SharePoint is a document management system what do you mean it’s not designed to support 3 million scanned images.” They don’t understand what SharePoint means by document management.
Poor terms definition – What does collaboration mean?
Poor/Lack of understanding of how it works – What do you mean I have to write code to get Single-Sign On to work. I thought it was magic.
No Compelling Reason – there is no compelling reason for people to use it.
No ROI – There’s no return on investment so it’s quickly abandoned in favor of the flavor of the month.
Tools Syndrome – IT departments that look for tools to solve their problems rather than looking for solutions. These folks typically have lots of boxes of tools that they’ve purchased but never used.
No Launch – Whether the launch is done hard (with fanfare) or soft (quietly, grass roots) it can be successful. Not being sure which approach you’re using generally doesn’t work.

What did I miss?



26 Answers Found

Answer #1    Answered By: Alison West     Answered On: Feb 28

Very complete list….

This isn’t contributing, just adding, but what I have come across the most is poor expectations and lack of understanding. Users don’t  understand how to use it and expect it to do too much. That may loop back to another reason  of failure being lack of training or support/learning resources (within the organization).

Answer #2    Answered By: Freddy Heath     Answered On: Feb 28

Lack of adequate training sounds like a good  one to add.

Answer #3    Answered By: Joanna Dixon     Answered On: Feb 28

I hope you won't mind if I add:

Lack of exploration of and\or aversion to "Out of the Box"

And this one:

The IT department's preference to "code" solutions  that are actually
MS Office integration solutions.

My Opinion: The SharePoint efforts that includes a substantial
focus on MS Office integration has a better chance gaining
the "inertia" a portal needs to succeed. The bait here is "Users
already know Office." The hook is "SharePoint replaces their My
DOcuments Folder."

Answer #4    Answered By: Damon Garner     Answered On: Feb 28

Perhaps adding:

rushed deployment leads to poor look & feel of portal/site, so users don’t  like it
Political considerations force SharePoint to be used in ways not intended: CMS system, for example
Politics between groups leads to killing SharePoint when it threatens established groups/processes/budgets/jobs……

Answer #5    Answered By: Sharonda Mcfarland     Answered On: Feb 28

Some good  points here and I think the biggest issue is around expectations. Too many people  see a flashy brochure and are sold on the “Portal to end all Portals” (even though they have no idea what a Portal is). While you can accomplish almost anything using the SharePoint platform (given vast amounts of time, money, and resources) it will never measure  up to users expectations when they’re trying to say compare SharePoint against a local Access Database or some VB app someone wrote.

The biggest problem to overcome is mindset and culture. People in most organizations (and yes, I’m being a little blanket statement-y here) generally don’t  want to move from the comfort of their tightly held file based system  with icons on the desktop to everything that’s already in their start menu. They acknowledge that everyone has a copy of the latest specs for a document  on their desktop, My Documents folder, Z: drive and email folder but don’t want to switch gears to a single place where it can be controlled, versioned, etc. and the issue of “who has the latest copy” problem goes away. It’s a culture shift but who knows how to install that change even if you can show its for the better (much like trying to convert a waterfall development shop to agile).

I don’t agree with your “No ROI” statement. I don’t think ROI has been presented, studied, or shown correctly for most portal deployments/conversions but mainly with the issues I mentioned above of mindset and not technology. Organizations need to look at SharePoint as a long term investment rather than some quick hit win. In the long term, having a controlled single source document or a meeting place online that will reduce say status meetings is a measurable benefit, but only if you accept it and get on the boat. If you’re the type that keeps printing out every email you get (and I’ve seen some managers that do this) then you’ll never benefit from any new technology, SharePoint or otherwise.

Will SharePoint fail in general because of this? Of course not. You’ll still have the die hards that keep local copies of documents because that’s what they do (and offline capabilities like Groove and vNext is going to make that even easier). Even with the cool tool we call .NET, there are still people that live, breathe, and (gulp) enjoy JCL.

Answer #6    Answered By: Cory Brooks     Answered On: Feb 28

Three things:

1) Delivering Value and Generating Use

Forget ROI, you won't get there unless you deliver something of value to the
users that they will actually use. How many of us have seen site set up, an
initial flurry of usership, then a fall of of users then silence. My
personal opinion on this is that even when we find a good  application for
the technology, that its the little things that get them. That's my next

2) Difficulty in Collaborative Usage

Here I am talking about usage of a "collaborative" nature where different
users are intended to "create" content together. Kit Kai has the most full
explanation of how to do this and I am not going to reproduce that here, but
I will say that the complexity involved is way above the heads of most
users. The problem where if you simply click on the file and edit it then
try to save it just to find that it is read only if very troublesome. Then
the user is guided to "save as" in some other place. Users lose the new
version on their local systems, ask why it isnt on the server etc. It
defeats the purpose of "where's the most recent version."

Kit was very good at explaining how to do collaboration  on a document, the
problem is that the functionality presented just does not work  in my real
worlld where users click and expect to just do their jobs without lots of
technical understanding. To me, this is a huge issue that I must overcome
with code  etc. before I can expect the system  to have any chance of success.

3) Customization Complexity

This is related to #1 and #2 above. To generate continuing users (i.e.
delivering them value) and to create a site that serves their needs,
customization is required. sharepoint  is a coder's worst nightmare. No
CAML editor, no real documentation worth a crap, no OOTB integration with
user controls, etc. etc. Its a house of cards too, remove one and the whole
system comes crashing down. Normal coders can't handle it. Think about it,
only the truely experienced with systems folks are here and we have
troubles, what about that poor coder who knows crap? Simply stated, they
dont try or don't succeed in trying to customize this thing.

Generally, I'm sure some of this is my feelings. I'm looking forward to a
more mature sharepoint in the future, but for now, I do what I can.

Answer #7    Answered By: Ruth George     Answered On: Feb 28

I'd agree that using the product  to a fitting need is important. I'd add
that the overall need kind of has to be collaborative.

What are some of the organizational environments that use sharepoint  best?
Which ones worst?

For me, I work  in medical academia, and the target use is for supporting
research teams, sharing files etc in WSS sites for their "Labs." The
Browser access to files is critical there, because folks arent always on PCs
(many love Macs) and many are in different domains, or at home or on the
road. The usefulness of WSS inside any given lab is directly proportional
to the desires of the lab director to use sharepoint. Often they can buy
their own PC to serve as a lab server and someone cobbles together a
solution that works  for a while. Or they simply trade files by email and

What I am doing now is creating an environment to develop academic
publications. Same basic need regarding browser file access. In this area
though, some level of document  management of reference publications is
needed, so I am using the Sharepoint Document Libraries, but I don't think I
am misusing them as the library of reference documents won't get to be more
than a few thousand. I have the advantage here that I work for the senior
staff, so that will create motivation for others to use it if they want to
get the senior staff as authors on their paper.

Anyhow, one would think that the medical academic environment is a spot on
application for Sharepoint.

Answer #8    Answered By: Peter Peterson     Answered On: Feb 28

I've actually seen developers actively working to discredit SharePoint
so that they can continue using technologies that they are familiar

Answer #9    Answered By: Kalyan Pujari     Answered On: Feb 28

How about this. I’ve seen Microsoft Partner discrediting SharePoint…

Answer #10    Answered By: Laura Walker     Answered On: Feb 28

What do you mean by “discrediting” SharePoint? I’ve sold against SharePoint when it’s  not the right solution for the customer… I’ve never seen a partner go out of their way to say it’s a bad product  only a bad fit.

Answer #11    Answered By: Gopal Jamakhandi     Answered On: Feb 28

Saying SharePoint 03 is a lousy solution… But they are basing their experience on SharePoint 01… so its very unfair… I can’t mention the name, except that it is a mnc…

Answer #12    Answered By: Kristina Cox     Answered On: Feb 28

Good point about Mindset/Culture. I’ve been trying to quantify that aspect and it’s  got many facets.

As for the ROI, it’s more of an abandonment problem. I’ve not seen the process completely play out with SharePoint yet, however, I see the lifecycle happening. Intranets were “cool”. They were built. They had no ROI. They were abandoned. IT shops quit making investments in their Intranet because they couldn’t justify it. I’ve seen this pattern play out over and over again as I go to deploy SharePoint. What I’m beginning to notice in deployments that others have done is that IT has stopped making investments in SharePoint. No training, no support, no new features, functions, or deployments. I see this as the early indications that there won’t  be enough investments to sustain the long-term life of the solution. A lot of this is based on the adoption rate, but I don’t  believe that encompasses all of the factors.

With my clarification, do you still disagree?

Answer #13    Answered By: Delbert Frederick     Answered On: Feb 28

I'm going to assume with MNC you might mean (or translate to) MCS (Microsoft
Consulting Services). Maybe not, but I concur. I've seen MCS guys who worked
with 2001 and not ever touched the 2003 version yet try to measure  it using the
same ruler. That's like giving a movie a bad review without seeing it.

Answer #14    Answered By: Kalyan Pujari     Answered On: Feb 28

MCS is not a partner of Microsoft right???

Answer #15    Answered By: Allison Stewart     Answered On: Feb 28

I’ve seen what you’re talking about here with regards to out of the box functionality. Mainly I see people  look at the problem and say that they don’t  do it precisely the way that sharepoint  has it implemented. So it must changed. They don’t evaluate how trivial it would be to shift what they’re doing to make the existing out of box SharePoint functionality work.

I’ve been thinking about how one might best approach  a SharePoint project. Is it an infrastructure project? Is it a Software development project? Or is it a large packaged deployment project? I think that the right answer is that it should be treated like a large packaged deployment project  (like an ERP system). The problem with this is that few people have any experience on how to make those projects  successful. In short it comes down to Install and configure what you can, code  where you must. Most organizations don’t understand  how important this perspective is. Of course, if we tell people that SharePoint should be run like an ERP project we’ll make them run away yelling something about the insanity of it all.

As for it organizations coding solutions, I put this into the general category of culture. People like to continue doing what they’re doing because it’s  comfortable. A culture has been created around those activities and they see no need to change.

Answer #16    Answered By: Emmett Hyde     Answered On: Feb 28

One of the interesting things that I hear you saying is that it’s  too hard  to eliminate the little quirks that cause people  to not use the system. In other words, there are a few things that Microsoft got wrong that are making it hard for users. I find it interesting because we have precisely the opposite problem too. IT departments try to make too many changes to a recipe that mostly works. Of course, I don’t  have any answers. I just have an observation.

Answer #17    Answered By: Michelle White     Answered On: Feb 28

I agree that IT departments can easily make solutions  that don't work  well
enough to gain user acceptance. My opinion, its not the amount of
customization, work or whatever you put into the project, its that the
resulting system  can be used effectively to meet its mission.

Think about that when you next hear a junior IT person say "Well see you
just click this drop down and select Edit in Microsoft Word." Right, as if
that will work. The user will click the file and open it read only in two
shakes of a dog's tail. This when that Jr. IT person is not around to see
the disaster that ensues. That's when we find the Jr. IT person is really
chasing another for a date, ya know ... kids today.

And FWIW, the quirks can be removed in any given circumstance, but the
removal is painful. It's more in the knowing that they need to be removed.

Answer #18    Answered By: Sheena Ray     Answered On: Feb 28

I'm not sure how it works  in your neck of the woods but here in Canada (and I
think the U.S.) MCS is just a department of Microsoft (although they don't call
them departments, can't remember the term now).

Answer #19    Answered By: Jaime Weaver     Answered On: Feb 28

Subsidy? I think it should work  the same everywhere…

Answer #20    Answered By: Damon Garner     Answered On: Feb 28

Regarding why SharePoint projects  sometimes fail. Here are two quick lists for you from my own experience.

A. I think of SharePoint project  success/failure in terms of four areas:

Project planning and management  (common to IT projects in general, since the portal is deployed typically as an IT project)
Expectations regarding the role the portal will play in the organization
Expertise and tools  available to bridge the gap between expectations and the base technology
User adoption and support, especially during initial deployment

B. The specific functional issues with SharePoint that I have found come into conflict with people’s expectations of the portal are:

We can’t figure out which site to use when we need to do something or store something
We can’t keep our sites consistent with each other when we make changes
We can’t restore items that have been deleted
We are still relying on a webmaster to do everything
We still have a lot of isolated islands of information

Clients expect and deserve honest advice on the strengths and weaknesses of the product  as it exists, and realistic suggestions as to how to make best use of the technology available to them. Sometimes SharePoint needs help, and every now and then it just isn’t the right way to go for particular needs. But it can usually play some useful and successful role, especially in an organization that already uses Office documents heavily to share information and no document  management strategy at all, or one that has a lot of activity around ad hoc teams. SharePoint is particularly good  at letting people  put up usable pages quickly  for a short term goal like generating a proposal or making a complex decision involving several people. With some forethought and help, it can be made useful for other kinds of things as well. Sold as as if it were a full-featured document management system  or as if SharePoint itself were a complete intranet in a box, it has a lot of potential to violate people’s expectations and lead to project failure, I think. Deploying SharePoint effectively for the kinds of things it is sold for involves more planning in more different areas than first appears for typical IT projects, and that is the biggest challenge to SharePoint projects in my opinion.

Answer #21    Answered By: Karla Morrison     Answered On: Feb 28

>Sold as as if it were a full-featured document  management system  or as if SharePoint itself were a complete intranet in a box, it has a lot of potential to violate people’s expectations and lead to project  failure, I think.

I just want to add to this… SharePoint is not a document management  system. My boss told me before, that when Microsoft tried to sell SharePoint as a dms, they were shot dead by their customers… So please, SharePoint is not a dms, but a collaborative platform or a portal… This way, we can manage expectation a little bit better…

Answer #22    Answered By: Patricia Richardson     Answered On: Feb 28

I agree with your comments. Organizations that have a lot of information in various forms, but where every local group has its own way of organizing it, are the classic starting place for many successful SharePoint deployments. They have an existing need to be able to make decisions together, they have organized information, and they have motivation to solve  the problem, but they don’t  have a common language and common set of procedures to apply to it.

SharePoint first makes it possible for them to rapidly put up sites that solve some small part of the problem, and then second begins to give them a common language for talking about how to address the rest of the problems. So the deciding factor in the success of those “bottom up” deployments (driven by users or project  teams) is whether the people  who have the most critical information to share begin routinely using the product. If they do, the other people in the team begin relying upon it, and the more that happens, the more other people begin to find it useful when they see the example being set. The parallel issue for a “top down” deployment strategy (e.g. a corporate SharePoint intranet project) is whether critical information from a small but centrally important group relies on the product  and uses it successfully. Typically in a corporate deployment this is HR policy information or IT support  information.

I think you made an excellent point also that in a “bottom up” locally driven deployment, SharePoint is typically competing for adoption with ad hoc but extremely convenient solutions  like email. So the success of SharePoint then depends on whether people see benefit over and above email, some benefit that outweighs the convenience of ad hoc solutions. In a top down (corporate) deployment, it is the management  that expects a benefit from more efficient employee communication and so they enforce new working practices involving SharePoint.

Optimally, you would have both the “push” and the “pull” … you would make SharePoint sites useful for individuals and small communities (“pull”) and also provide working practices across local organizations and teams (“push”).

The initial pull (for me) would mainly be browsing, searching, and alerting; people would be able to find information by its use rather than by its history and author, and know when the most relevant documents to them are changed. The push would be some way of categorizing the sites themselves and policies for publishing links to important documents for browsing purposes. Used together, this drives a moderate initial growth of portal use in the organization, and at that point it has established a role in the organization relative to other technologies, and there is a good  basis for evaluating the next steps in deployment.

Medical academic documents have a clear but “multiply realized” categorization scheme and there are different things that specific groups may be doing with them, so I would agree strongly that this should be a very good application for the unique things that SharePoint does well!

Answer #23    Answered By: Alexandra Patterson     Answered On: Feb 28


Answer #24    Answered By: Christop Mcfadden     Answered On: Feb 28

I agree – there is a difference between saying SharePoint isn’t a good  fit and SharePoint is an inherently bad product.

Answer #25    Answered By: Stefanie Ruiz     Answered On: Feb 28

I realize that my perspective on this product  is unique. But, I look at
Windows SharePoint Services as the first few tools  in what will
eventually be a Swiss army knife. I certainly don't think that
collaboration is a necessary element, even though the sample application
that Microsoft ships part and parcel with the platform to demonstrate
how it can be wielded does a great job showing how the platform can be

I don't think that SharePoint will replace every enterprise application
(SQL Server and ASP.NET will have their place), but WSS can (and
eventually will) tackle 80% of the common business requirements. Once in
place, over time, the demanders will be able to maintain these
component-based, list/library centric applications on their own.

Answer #26    Answered By: Damon Garner     Answered On: Feb 28

Admittedly, SharePoint v2 is not a full blown document  management system
(in fact it has less document management  features than v1 had).

That said, I think that Microsoft is going to focus back on document
management functionality (to meet the demands of SOX) in the next
release putting it back onto the document management system  stack.