One question that keeps coming up again and again is what should I look for in a SharePoint guy. I get asked this a lot and from many different directions, but it’s a large enough topic that I’ve resisted following my rule and blogging the answer to any question I get asked more than once. Recently I was held down and made two write down some of the advice I’ve been giving out over the years because I needed to give that answer to a very geographically dispersed group. Since I finally put it down I thought I’d share it with a wider audience.
You can find the slides that are used for this presentation at my slide sure link below. But the main gist of it is that asking for a SharePoint “guy” is really not the best way to staff a successful SharePoint project (no surprises yet, I’m sure). SharePoint projects, and many shapes and sizes – just like general app dev projects. They can be anything from intranets to knowledge management to document management to collaboration to, well, you get the idea. SharePoint projects can also vary in complexity from slight modifications of an out of box install two entire enterprise systems written on top of the SharePoint platform.
The first question has to be what type of project or you undertaking? What is the scope? How does it map to what SharePoint (in its various editions) already provide? What functionality are you leveraging OUTSIDE of SharePoint, and how much of it will stay where it is and how much should transition over? What timeline are you looking at? Will you be migrating content, and if so will you be migrating straight or will there be a cleanup/management step in there? The list goes on.
When you actually have a good understanding of your goals, that’s when you choose what skill sets you are looking for during the project cycle. The deck shows some of the skill set and roles mappings that I’ve witnessed on various SharePoint projects. It doesn’t dictate exactly which roles you absolutely need, how many in each role, or were multiple roles can be filled by single people on various projects. Some projects I’ve seen have had literally hundreds of people from Architect Teams to content managers involved. Some have had a single person wearing all of the hats on the project and working with other groups for the details. So I wouldn’t dream of telling the team on the ground what they should do, but I hope the breakdown showing what I’ve seen in my experience can help advise them. I’m sure they’ll be plenty of questions, I look forward to a lively debate in the comments section on this post.
