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.

Share Point skill sets

Tags: Architecture, SharePoint

OK, I’ve blogged about the SharePoint Guidance pack a while ago, but there’s a new version out last month.  Take a look over at http://microsoft.com/spg (SharePoint Guidance) and get some of the details from the product group and P&P guys on how to implement and extend SharePoint as part of your infrastructure, development environment, and platform.

You’ll find information on:

– Architectural decisions about patterns, feature factoring, and packaging.

– Design tradeoffs for common decisions many developers encounter.  (Remember, with architecture there are no single right answers – know what you’re trading off when you make that decision!)

– Implementation examples demonstrated in the RI and in the QuickStarts.

– How to design for testability, create unit tests, and run continuous integration.

– Set up of development, build, test, staging, and production environments.

– Managing the application life cycle including upgrade. (But you’re already using Features, right?  See what else you can do to help out here.)

– Team-based intranet application development.

But be aware that this release isn’t focusing on:

– Content-oriented sites that use Web content management.  (See some of my other posts for these)

– Internet and enterprise-scale SharePoint applications.  (Again, we’ve covered this before.)

– Multilingual SharePoint applications.  (If you’ll leave me good links for this, I’ll be glad to post!  Being only English speaking (or these days, Texan speaking….) I’m not the best qualified to speak on this particular topic.  (Pun intended.)

– Scale or security testing of SharePoint applications.  (To be covered in a later post if I have a chance – this is VERY process/organization driven.)

Tags: Architecture, SharePoint