Building SharePoint Teams
Remember back in grade school when you’d pick teams for sport? Soccer, baseball, cricket, kickball …. the science team. Whatever your passion was, you probably remember the strategy that went into team selection. You need the utility player who can plug into a few spots, the great offensive guy, the defensive guy that no one could get a score past, and that gal who didn’t know much about the sport but boy could she run like the wind!
Putting together the right SharePoint team is like that. A team packed with great defenders doesn’t do you much good – who scores the wins? And the team stacked with great offense – boy were they taking a big risk that a few well executed plays would slip points through weak defense.
When it comes to SharePoint, I see similar team selection all the time with new clients. They tend to look at implementing a new collaboration portal, an intranet for fostering communication, and a customer friendly portal, through a narrow lens. They gravitate to a team of infrastructure gurus, or ace developers, or SharePoint architects and somehow expect those individuals who have spent a lifetime honing technical skills to be masters of user experience, communication, and interface design. Or, they gravitate to a flashy design and seductive user experience, somehow expecting those individuals who are masters of sousing out the right design to match the needs of the business and also make the right decisions for security, scalability, architecture, and supportability.
I’ve found that the right team for executing a SharePoint implementation, and more generally an effective intranet, extranet, or public facing Website, is dependent on a number of key roles:
- Project Lead: A resource skilled in guiding a project to successful delivery through a proven methodology. Not surprisingly, I’m partial to Rand Group’s UpFront Methodology.
- SharePoint Architect: The technical specialist who conceptualizes the overall solution in conjunction with the rest of the team.
- Infrastructure Specialist
- SharePoint Configuration: Their primary focus is configuring SharePoint and laying out pages without writing code. Sure, your developer or Infrastructure specialist can do it, but why pay those rates?
- User Experience Designer/Information Architect: For large projects, this is divided into two specialists. For the typical mid-market implementation, a single individual can successfully fill both roles, given that they have the right training. The User Experience Designer is a user advocate, understanding how people will use the site, and then crafting the navigation, page layouts, and flow from one page to another (did you remember your back link? What about the link to the related page? Does your search results page let you navigate to where you want if you get the right result? Or the wrong result? Or you’re not sure?). User Experience Design is a crucial part of any SharePoint project. The Information Architect analyzes the body of information you know you want to store now, the information you think you’ll be storing soon, and invites consideration of information you didn’t think about storing and comes up with content types, metadata, values, and controls for managing and organizing that information.
- Content Writer: The famous last words of many an unsuccessful SharePoint project are “Don’t worry, we’ve got content under control.” A good SharePoint project needs someone responsible for making sure that useful content gets generated and added. Note: The best implementations have many people filling this role.
Having participated in many SharePoint projects I know first hand that the right team can have a major impact on the success and ease of the project. It’s worth considering the project team, and how to best leverage the talents of your resources for the best results.
– Software Delivered as Promised. No Surprises.