Why SharePoint Projects Fail

I have been involved with a lot of SharePoint projects, a real lot. For some of these, I play the role as the architect as well as the developer, however for a lot of remote projects (which I do a fair amount of) I am doing component based development, so generally handing things off to the “architects” that are staffed internally as organization FTE’s, and whom expect to receive a simple, installable package. I like playing this development role on occasion because it affords you very, very unique insight into the project operations, a higher-level view of the overall project, where you don’t have a huge vested interest outside of a particular deliverable, and basically you can make some very interesting conclusions and observations without fear of reprisal.

There are several reasons that SharePoint projects will fail, which can occasionally be out of the reach of the parties involved and not really the fault of a particular person that is involved in the project. In my experience however, this a more rare occasion than being the fault of one or many members of the team.

Therefore, before we get started, let’s break down the very, very general roles that we see within SharePoint projects. There are of course several others than this, however for the sake of argument, let’s just keep it simple and target the three major groups that are fairly universal:

Developers – Obviously the most important :-). Regardless, developers are the ones that are generally responsible for building components that plug-in to the SharePoint framework or using the available objects extend the framework for new functionality and behavior. Developers generally work with architects in order to help them design and build applications that tie into SharePoint in order to heighten system awareness and automate maintainance tasks.

Architects – Responsible for the setup and design, configuration, administration, and maintenance of the SharePoint environment. Generally, these members will wear many hats throughout the life of the project since their job role will mandate that they graft several types of technology. Although it is not common, often times architects will design and build small applications that help them in their day-to-day tasks on the project.

Managers (Project and Program Managers) – Ok, I won’t go on another management rant. I promise. I have had some GREAT project managers and program managers in the past, whom have not only helped direct me to successful project completion but have taught me a great deal about increasing my own skillset in a variety of categories. In the managers category I am going to lump program managers and project managers together, however the roles that they play are usually very different. In any respect, management is responsible for greasing all the wheels outside of doing grunt work on the project such as doing budget management, talent acquisition for staffing the project, managing the deliverables, shoomzing the client, etc. etc. etc. you get the idea. If you have a manager that is willing to even sit down and do code reviews with you, I’d be frickin shocked (I have, in the past, have managers that did this, and they were the fore-mentioned great managers).

Now for the meaty subject of this post. The reason that I see SharePoint projects fail the most is because of the last group. Management (ha! you knew that was coming!). And the reason is the management that you generally see involved in SharePoint projects lack two main things. These two main things subsequently branch out into other poor aspects that derive from this lacking which make their character and skillset completely inappropriate for a complex SharePoint project.

The first lacking spawns from companies often making the mistake of considering having management, or project management experience, enough to manage anything, and certainly enough to manage a SharePoint project. This is completely not the case. Project management when building a ham sandwich is not the same as complex software development project management. Sure, some of the same principles apply, but they are unbelievably different. Sticking a general project manager or some greenback fresh off a PMP course onto a SharePoint project will not only make the project go awful, it will generally, IMHO, fail. I was once in project negotiations with a small dental insurance firm based out of San Fransisco, and within 5 minutes I knew that I wasn’t going to take the project. There were two people involved in the discussion, one whom was BASICALLY the program manager, and another who was going to play the role as a project manager. I went and talked with the program manager first:

Adam: So the PM seems like a nice guy

Pro Man: He was a floor manager at Kellogg (the cereal company), for about 7 years, he has great management experience.

Adam: He managed software projects for Kellogg? That is neat. I wonder what they developed. I bet it would make for an interesting conversation.

Pro Man: Well, he didn’t manage software projects, more the actual product line.

Adam: You mean he managed, what? Like the actual floor where they made cereal?

Pro Man: Exactly.

Adam: Ok, what software projects has he managed? Or more relevantly, what SharePoint projects?

Pro Man: I don’t think any, but he has great management experience.

Adam: So if I was to walk up to him, and ask, hey, do you think that I should do a SharePoint list rendering via XML/XSLT transformation or piece-meal CAML querying he would have no idea what I am talking about?

Pro Man: I would say it is doubtful.

Adam: I think I will pass on this contract.

Developers don’t respect position, they respect knowledge and expertise. They respect people that know what they are TALKING about, not people that got into their position because they can TALK. Let’s take a little page from our good friend William Wallace from Braveheart:

“Now tell me, what does that mean to be noble? Your title gives you claim to the throne of our country, but men don’t follow titles, they follow courage. Now our people know you. Noble, and common, they respect you. And if you would just lead them to freedom, they’d follow you. And so would I.”

Let’s translate this into software development terms:

“Now tell me, what does that mean to be a good software project manager. Your position gives you the management over our project, but developers don’t follow position, they follow knowledge….”

:) call me Adam Wallace.

This is often a misconception that I see, since a lot of people that are in management, IMHO, got into their position because they are good at selling, and good at talking. These people however, generally are the exact types of people that developers ARE NOT. However, if a balance could be found, where a management person HAD that experience, could talk to both end of the tables with the authority of both their sales pitches, AND understanding, studying, and suggesting development aspects to developers, they would be so much more effective.

Anyways, I am done writing about this.


15 thoughts on “Why SharePoint Projects Fail”

  1. I couldn’t agree with you more. You have hit the nail dead center on the head. I will take the Adam Wallace piece and share it with my PM. Great stuff, Thanks!

  2. Very true…I have been part of similar situations and almost always have declined the project. At the end of the day, you are as good as the weakest link in the team.

    I always say: Choose your team members wisely.

  3. Adam (and all others), if all the managers already had the knowledge you expect and knew how to do what they want the you to do then you would have a hard time to find a job.

    When I hire a developer I’m going to explain the problem to him and what results I expect. The rest is up to the developer.

    If he has a problem, I’m going to listen and if necessary make a decision.

    I have no idea whether I’d prefer the XML/XSLT rendering or CAML, but I’m sure you are able to explain it in a way that a good manager can make up his mind and come to a decision.

    If one can’t explain the problem properly then he probably better calls himself a coder instead of a developer.

    But if you REALLY want an Intranet to fail there is one way: Choose SAP Enterprise Portal. I have never spent more money for less results than in the last three years.

    Now it’s time to correct this mistake.

  4. You misinterpret this post. I am not saying that I, or any others, expect a manager in any position to have a comparable skill set to that off a seasoned developer. Obviously ideal, however completely out of the question from both a staffing and a responsibility standpoint.

    I am saying that he or she should at least, in the very least, be accustomed to the technology so that the decisions that he or she makes in regards to the project are not completely ill-informed. Otherwise, the requirement scope can become ludicrous.

    He, or she, should be able to pick up a book. Read it for 15 minutes a day. Understand what you are asking. Have a clue about the technology. Have an appreciation for when a developer puts in 15 minutes extra after 5 o’clock a day to improve some quality of the software. When they take the time to unit test.

    I prefer to have a manager that has a programming background. I really do. OOP concepts are in a skeleton fashion the same that they were 5 years ago. When I am able to elaborate problems I am having with my software with my manager it helps. I don’t have some idiot hovering over my shoulder saying “Is it done yet?!??! Is it done yet?!?!! Why are you taking so long!!!” He understands I prefer to unit test, to profile my code for memory / speed concerns, and that if it takes me that much longer, to not bother me.

    When they have a programming background, even if it is frickin VB4, or FORTRAN, I don’t care, they still have an appreciation and understanding which goes into creating a piece of software. They aren’t just salesman looking to make you sweatshop out a piece of software just so they can have something to say in their next meeting.

  5. Oh, and yeah, I agree with you. SAP is an absolutely nonsensical product, and the amount of effort that you have to put in to get some rudimentary work done is insane.

  6. i am a developer and i am also feeling and suffering with same situation and here me and my team are torched, we are the developers, who are managing portal and whenever we ask anything to my PM (PMP) , he simply say don’t count me in technical, I am freaking out stressed and exhausted .
    Still I have hope that things will be alright 

    I am strongly agree with your post and feeling and surviving in same situation.

Leave a Reply

Your email address will not be published. Required fields are marked *