10 Steps To Effective SharePoint Project Management

Ok, so as Bob Fox pointed out:

“I have to admit that sometimes I do tend to just say things that should only be thought about and then discarded, but my good friend seems to not follow that logic”

Ok, so that is true, some of the things that I post on this blog are mostly because I am angry about something, but hell, its my blog, so whatever. They are often times just things that need to be said.

Regardless, I was talking to a friend who wanted to yell at me because he was a past project manager of mine, and he read my post “Why SharePoint Projects Fail“, where I tend to place the blame on SharePoint projects failing because of poor management, well not exactly not poor management but lack of particular attributes in SharePoint project managers and program managers. I still think that is the case. However, he asked me what I would do to improve it, instead of just saying “learn SharePoint”. Well fine, I will. Keep in mind; I’m not even a project manager :), so take it with a grain of salt. BTW, these are in no particular order at all.

1) Determine the Scope and Reach of Your SharePoint Project; Don’t Assume an Enterprise SharePoint Deployment

This would be a huge step in the right direction when you are kicking off your SharePoint project. The scope of a project, to PM’s, often times seems to determine its relevancy to their career, which although may be true is not a healthy approach that is conducive to SharePoint project success. When deciding how to manage your SharePoint project, you must determine it’s reach, it’s scope, and its impact in relation to user adoption. This is even more important when architecting communication and collaboration systems. If you are doing a proof of concept deployment, the parameters of your project are going to be vastly different from a largely, go-live, enterprise deployment. There is not one set of arguments that span all SharePoint projects. Don’t let scope creep, and your own pride, murder your SharePoint deployment.

2) Eat Your Own Frickin Dog Food

Use SharePoint to manage your project. Seriously. If you are sending around excel spreadsheets to get development updates, or to implement a change management system for architectural operations, you are swimming upstream in relation to the technology that you are attempting to implement. Build your own little sandbox to track these types of things. Not only will it help with your project management, but it will also make a nice POC that you can show the client as a use case. You don’t just have to say it’s a communication and collaboration system when they ask what this thing will eventually do for them, you can say well, we have been using it to manage this entire project. I can tell you date by date what we accomplished, build reports, and generate some summaries for you if you like.

3) Acknowledge Your SharePoint Developers and Architects

Let’s face it. You have people on your team that took the time to specialize in a product. They took the time to understand what can be a woeful Object Model to understand (let’s be realistic, although it is all C#, migrated C# developers often find having to learn whole new development constructs annoying), and even more so because often times it is so poorly documented. They take the time to sit down off-hours and improve themselves to better themselves for the benefit of your project, often times against their own will. When a developer gets done with a piece of complex SharePoint software, don’t just say OK, great, why aren’t you working. Let them know that they are appreciated, that you knew it was difficult, and that you took the time to understand that although what they do is difficult, it is great that they were able to satisfy the requirements that you set forth. And buy them a beer.

4) Clearly Define What You Expect From Your SharePoint Developers

SharePoint requirements can be so vague. Don’t just say “I need a framework that allows publishing.” Hmmmm, that might be a little vague and ambiguous. Exactly dictate what you need, what the interface is supposed to look like (which is unbelievably important with collaboration systems, and Visio is your friend), and what your performance benchmarks are. I generally don’t just write out my software requirements in a glob of crap. I usually break them down, during the first run (these wouldn’t be the software final requirements, but what I do in the initial engagement meeting when starting to get an understanding. THEN comes formal requirements documents that can be delivered), into the “Overall Software Goal”, “Interface Interaction Components”, “Aggregate Procured Functionality”, “Used SharePoint Deployment Mechanisms”, “Overall Environmental Considerations”, and “Software Performance Benchmarks”. Again, this is usually what I do during the first meeting, and then I get more detailed. Maybe I should post my software requirements template, I might do that.

5) Talk to ALL your SharePoint developers, and don’t pick favorites!

I hate when this happens. You may have Lead SharePoint Developers, Senior SharePoint Developers, and Junior SharePoint Developers. They are all very important to the success of your project. It is common that Junior Developers do not get any acknowledgement for their work because they are often doing sweatshop class development that gets handed higher up the change for consumption in the greater, overall software. The role that they play is still critical, and someday, they are going to be senior developers, that you may be managing. Talk to everyone on your team, and get a feel for what everyone is doing. It makes me feel important when a project manager takes an interest in what I am doing, although it just may be some plumbing that is going to get consumed higher up the chain.

6) Get off my ass! Stop Micromanaging me! And sometimes I need a break.

SharePoint development can be FRUSTERATING. Particularly when you are breaking new ground into areas of development where they are not a lot of resources or documentation that you can turn to. Developers know what they are doing is important, but hovering over them like a vulture is going to do nothing but make them nervous. And sometimes, frustration gets to the point that you need to walk away and revisit the code. Often times, this is the only way that a problem gets solved. I can’t count how many times I am sitting there cursing that the SDK says this documentation has yet to be written, having stared at my code that really does look like it should be working for two hours, had a quick smoke, came back and solved it in 15 seconds. It is necessary sometimes.

7) SharePoint development can be frustrating, difficult, and prone to error. Inflate and expand your timeline.

Overestimate EVERYTHING. I have worked with some brilliant programmers, but sometimes development isn’t nearly as straightforward with typically .NET development, and it takes a little bit longer. Although the requirements may be clear, often times things aren’t documented very well, and you are breaking new frontiers in SharePoint development. Although the requirements may be clear, it is safer to just keep the timeline as inflated as possible. And always, always, assume time for research. Developers often need time to learn what other people have done to gather the right approach, to see if the approach that they are thinking is right, and to see whether the thing that you are asking for is even feasible.

8) Help to foster a relationship between Operations and Development

This war is in every organization I have been in. Operations hates development, development hates operations. Operations always complain because development is making changes on THEIR servers, development always complains because operations are hindering their deployment of new software. In a SharePoint project, these two teams are going to work so close together, they are married in some weird sort of way. They must work together well in order for the project to go well. More often than not your SharePoint development is going to be extending the SharePoint framework, which operations is responsible for, so they must, must work well together and respect each others jobs.

9) Read a SharePoint book.

I am not asking you to be a SharePoint developer. That’s not your skill set. You do other things that I appreciate. But if you take 15 minutes a day, and start to understand a little bit more of the technology, think about how much more efficient the project would be. I can elaborate issues that I am having, you can understand them, and hell, maybe even suggest a direction for me to go. Because PM’s are often times responsible for interfacing with the clients, think about how much smoother your status updates to the client would be. You can exactly define milestones and problems, with all the detail that is required, and if the client has internal staff in their to translate whether you are truly making progress, you can eloquently describe the problems to keep everyone at ease. This is so important.

10) Conforming to a new SDLC doesn’t happen overnight. Don’t push it. I hate that.

Most developers will be accustomed to whatever SDLC you want, but it doesn’t happen overnight. Coming from an Agile environment and getting pushed into CMMI is a real bear, and it requires a lot of assimilation. Sometimes the concepts just seem so inefficient and worthless. But a developer WILL eventually get the hang of what you want, but it will take a little bit of time before everything is running smoothly. You may have the most talented developers in the world, they could be frickin brilliant, but if you try to force their hands to conform to what you need RIGHT AWAY, they will be unbelievably inefficient.

I am sure this list could be expanded vastly, and that I haven’t hit everything. This was just something that I felt I should respond to on a late Sunday afternoon, while enjoying a cold Blue Moon outside on a fine South Carolina day :)


12 thoughts on “10 Steps To Effective SharePoint Project Management”

  1. Nice piece of work adam. Taken all the points and whole heartedly agree to everyone, especially the one Get off my back and read a book. Would like to add, the book has to be a general purpose Sharepoint book, not the development types, otherwise i have know PMs doing back seat driving, you know what i mean! and bam…

    Another Step is to think in Sharepoint.


  2. Thanks guys!

    Eventually, I hope to expand this list to include some more points, and than tape PM’s heads to the screens and make them read it :)

  3. Hi Adam,

    Good one mate. Indeed every point is valid and nicely suits to my case. I guess I will start to point all my futures PMs to this before the kick off.

    Looking forward for more posts like this.


  4. It isn’t the PM’s job to understand CAML. I happen to be a pretty technical PM, and I can say that as much as knowing about the technology helps me talk to the developers better, it doesn’t make me a better PM. If a non-technical PM went at a MOSS project alone, they would be in deep doo-doo. However, if a PM doesnt know the technology they are obligated to do thorough requirements analysis and get signoff on scope and the requirements document before the system gets built. BEFORE it gets built.

    Having the whole team actually use SharePoint for the project is a great idea. It works well, and I can attest to that. Sometimes the hardest part of an implementation is getting people to accept the look and feel of something new.

    I think it is always a good idea to take a developer’s estimate of hours and multiply it by 2 for a rough idea of how long things are going to take. Again, however, a PM should be making a WBS and defining work packages with development and not just sitting behind a desk coming up with Microsoft Project files.

    You have to get your hands dirty, as always. I have a major problem with desk-bound PMs. I dont think this is unique to SharePoint. Do you?

    I also do not think that a good PM should be able to sit and do code reviews with the developers. I *like to* do them, but it doesnt make me a better PM. Communication is the key, not technical knowledge. You need to be able to understand the types of problems that developers face, but you dont need to know how to write a CAML query. You just don’t. If anything, you become a pain the the butt, staring over developers’ shoulders. When I was a developer, I did not like my PM to check out my code. That was not their place.

    Most of your comments are applicable to just about any software project. The UI has to be created via wireframes (unless you are going with OOTB look and feel, and if you are, shame on you) and it is a team effort. Design, Project Management, Business Anaylsts, and Developers are all stakeholders.

    I think it is common and understandable for developers to want to scream at their PM, but again, this is the case be is SharePoint 2007, PHP, .NET, or anything else.

    My 2 cents.

    Great post. I like reading your perspective. I am in the middle of a large SharePoint project and some of the issues you touch on are indeed factors in my project.



  5. I agree with you in some respects Josh, and it is very likely the CAML example I put out might have been a poor one and extreme in its own respect, but it was one that was fresh in my mind so seemed appropriate for the relevancy of the post since I was upset about current circumstances, and this, as a lot of posts, are written in a rather heated mood. There were other factors that the PM involved in that project just didn’t have outside of that specific one (that dialogue was rather truncated), which to me made success in the project not very likely, and since my reputation rides on each SharePoint project I am involved in, I had to skirt taking the contract at the risk of losing future contracts. Whether it was a good or bad decision, I am not entirely sure and I guess only time will tell.

    There are some things that I don’t agree with in your comments, and some I really do. Firstly, I think being more technical does make you a better PM; I think it makes who a WAY better PM. The best PM’s I have had (which, granted, haven’t been outside of my verticals / industries outside of the federal sector) have been extraordinarily technical, and while this didn’t contribute to their project management skills / experience directly, it did make me respect them at a higher level. How could I not when someone has 10 years development experience, in although not directly related, software development field? When a technical PM on a SharePoint project asks me to do something, I know that the wheels have been turning in his head a little bit, that he isn’t just giving the obligatory yes sirrreee to the client for a requirement, and that I can speak to him on a certain level. That means a lot to me, a real lot. Besides the enhancement of our conversation regarding an arbitrary requirement, on a man to man level, I tend to be more open to what he says because he isn’t just some used car salesman that has worked his way up the corporate chain via mutual back scratching. Now, this could certainly be a shortcoming of my personality (you probably have read other parts of this blog / site, and I am not 100% on the plane with management as a whole), but it’s just how I am, and I think that feeling is fairly consistent among developers as a cohesive whole. I prefer people that have worked their way up the ranks, not the butter bar types (butter bars, for those that haven’t worked with the military, are generally Second Lieutenant’s who immediately come in as officers to a wing / unit), PM’s that have been in the trenches, put their time in, and deserve where they are at. I guess that somewhat jives with your point about desk-bound PM’s, which I don’t really dig as well clearly.

    Regarding the WBS, I agree with you. It’s not something that I am good at as a developer, and I skill I completely value in a talented, experienced PM. I think when building the WBS however, that a technical PM may be able to more accurately, concretely, and precisely define the individual components that would build up the aggregate portions of a SharePoint WBS. Personally, I would take a less project management experienced, more technical PM’s work breakdown structure, in comparison to a non-technical, more experienced project management WBS, in a second with stipulation. But then again, although there are universal concepts that span project management, I really, really do think that PM experience in any arbitrary field does not, in any way shape or form, make a good software project manager. Then again, project manager I am not  (although I am taking my PMP test in 2 weeks).

    I don’t expect my PM’s to be able to write a CAML query. Would it be nice? Sure. That would be great. We could have a few and talk about building static wrappers for em trading war stories how we improved our SharePoint development experiences. Is that realistic? Not really. But, I do think that they should know what one is. I really do. I think they should be aware, albeit at a rather abstract level, of programmatic approaches when building solutions. They may not be able to write them, but they know what CAML is. They know what it does. They know what it can be used for. They may know the pros and cons to using it in circumstance A and circumstance B. And I think they should be able to legitimately vocalize this type of stuff to the client. I took the time to understand this OM at depth, I think it is only fair that a high level that a PM can learn some of the approaches (again, at a very high level) as well. I will handle the grunt work and enjoy doing the plumbing, and because software development projects do require a certain understanding by all those parties involved, it is only respectful and beneficial to the project as a whole, that a PM take the time to at least get a high level understanding of what I am doing.

    And a lot of these points may be applicable to a ton of software projects; I can see how they could span. I only do one specific subset, and I don’t really touch on any more.

    All in all, I am jealous that I am not on your project. I would love to have a technical PM (which is not my current case in any way shape or form), because, if nothing else, would could go over project stuff over beers and shoot the shit over how the project is going. :)

  6. Amen, brother. How many of these PMs spend tons of time tracking what we do, when we do it, ie. “on our backs” as you most perfectly quoted, when they could be out training and creating the governance standards that so many deployments forget to do until post deployment complaints regarding lack of adoption pop up. I am going to link to your post on my blog. Well done indead!

  7. Lol, my pm is sitting across from me hacking out some gantt chart, and wearing his little blazer with this smug, self-important look on his face. I on the other hand am fucking around with the OM

  8. FRUSTRATE implies making vain or ineffectual all efforts however vigorous or persistent.
    I believe a lot of the stuff I read… at least until I can understand it or prove it wrong… thus I believe a lot of the stuff I read. You had me searching all over for the meaning of frusterate.
    Thanks for the help.

Leave a Reply

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