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.