How to Staff Your SharePoint Project


Something that has been truly bothering me lately is recruiters or project managers or executives not knowing how to staff SharePoint Deployment projects or staff their Operations teams that support SharePoint.   Too often I receive calls from recruiters looking for SharePoint “Technical Resources”.  Rarely are they looking for people who know how to analyze business processes or manage enterprise information management platforms like SharePoint.    It seems recruiters want hands-on resources who write code and do everything else including administration and configuration.   Unfortunately looking for a jack of all technical trades is just not the best way to minimize risk when it comes to your enterprise application deployment.  I’ve seen too many implementations that have gone wrong or ended up simply re-creating the information mess that already existed in the organization.

So let me outline the resources required for ensuring success of your SharePoint implementation.   It is important to note that these resources do not simply go away once you have completed phase I of your global deployment.   Each one will be required for ongoing governance of operations and continued solutions development and support of business needs:

Program/Project Manager – an individual who not only knows how to manage IT projects, but also understand ECM, information architecture, software and solutions development, IT infrastructure, etc…   They don’t have to know how to write code or know SharePoint administration hands on.  They do need to have some “technical acumen” but they also need to evangelize the solutions to both end users and senior executives.  They need to know how manage and govern an application like SharePoint and have discussions about backups,restores, failover, disaster recovery, taxonomies, etc.  They also need to understand communications, collaboration, knowledge management, business process improvements, ECM, web 2.0 — all the capabilities that an organization might leverage with SharePoint.

Systems Analyst – Having the word “SharePoint” on this resource’s resume is just not required.  There are sooooo many GREAT system analyst resources that I have met who seem be stuck in their current role between IT and the Business.   Perhaps they’re in a Big 4 Consulting firm doing QA work on some legacy or ERP application or custom web development for some large Fortune 500 client, drafting business requirements documents, or working late nights with offshore development teams.  All of these individuals I’ve talked to seem disenchanted with their current role, see little career growth, are tired of their current technology focus, and are looking for the chance to work with an application that the sex-appeal of SharePoint.   It really doesn’t matter if these individuals know SharePoint or have seen it.   Let me repeat that: It really doesn’t matter if these individuals know SharePoint or have seen it. If they are experienced with any enterprise application, the skills are all transferable.   This role is so critical in SharePoint’s success because someone needs to work with the end users and business to understand their needs, map out the requirements and workflows, wireframe site designs, get hands with SharePoint Designer and do light customization and design of sites, and provide QA.  However, there is no reason why this resource needs to know how to write code.   They just need to interact with the business and developers ensure what is delivered to users has some level of quality and actually matches the requirements identified upfront in the project.   Lastly, a systems analyst is not someone who simply leaves once the initial deployment is completed.   This person will be needed for ongoing requests by the business to develop solutions on top of SharePoint.  So many companies have way too many internal processes that are paper based, inefficient, or handled over email….that a systems analyst resource will be busy for at least the next decade.

Solutions Architect and Jr Developers – Okay, so here are the resource who knows how to write code… .Net, visual studio, etc.   Maybe you offshore development and if you do, that’s fine.   However, you better have really really good system analysts and project managers to manage that development and provide the interface and QA to the business — especially if there are language barriers to manage.   Don’t expect these resources to know how to configure SharePoint, install it, or do any administration whatsoever.   However, it definitely helps if they do and can guide your organization in their deeper taxonomy planning, security, and high-level solution design.  Do expect they know the SharePoint object model, know how the performance impacts of developing point solutions on top of an enterprise infrastructure.

Information Architect – Expert in ECM and information architecture.  You’ll pay a premium for this resource, but it’s worth it.   Most deployments overlook the need for this person.  Maybe they have worked with other ECM applications like Filenet or Documentum.   Knowing SharePoint is useful, but not necessarily a must have.  If they have 10+ years experience with ECM applications, they can learn SharePoint’s model very quickly.   In fact, most Documentum or Filenet or Lotus consultants I know who have 15+ years experience all say the same thing — they’re doing exactly what they did 10-15 years ago — just at an enterprise scale and with SharePoint.

Systems Engineer / SharePoint Administrator – a Windows certified resource preferably.  Someone who knows how to install, configure, secure, troubleshoot IIS, OS, hardware, Virtual images, and network issues and in a global WAN or extended extranet environments.   When users can’t access SharePoint, you will not only need a really competent resource here — but you will be buying them drinks often!

Storage Engineer – your SAN or NAS experts who understand performance and storage considerations mostly around SQL databases unless you opt to store files outside of SQL.

DBA – SQL Server experts who should learn how SharePoint stores data and files, how to care and feed for it, limitations, and even options for storing files outside the database, etc…

So don’t understaff your SharePoint project.   The ROI is real and you’re making a mistake if you think you can offshore everything or pay a junior resource $40 or $50/hour onshore.    While some of these roles might be filled by a single person, you will likely pay more for someone who can wear many hats — and you should pay more for 1 person who addresses multiple needs (that normally would be addressed by multiple resources).   In this world, you get what you pay for….so don’t risk an information mess in your SharePoint deployment.   Get the right resource with the right skills for the right job….and yes, I’m available if you need help!  🙂

Share/Bookmark

 

Advertisements

5 Responses to “How to Staff Your SharePoint Project”

  1. This works for me and aligns to my ideas on SharePoint roles. I’m going to reference this blog on my site.

Trackbacks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: