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 :)