A friend of mine asked me a very good question: How do you form a SharePoint team?

All development teams are similar, but SharePoint projects are not a pure development effort so slightly different team members will be required. I will try to compare my idea of a SharePoint team with existing roles in MSF. Roles in MSF are complex and you should consult MSF Team Model Overview for more details.

The key person in your SharePoint team is a consultant. Consultant should be familiar with the complete Microsoft platform offering. SharePoint solutions are built on various Microsoft infrastructure products so in order to deliver the best solution to your customer you must choose proper Microsoft products, licensing models etc.

Consultant’s key abilities should be: the ability to recognize customer’s key business challenges and map these to SharePoint feature areas. Your consultant will also be a part of pre-sales process; making presentations and delivering various sales documents. In small teams consultant will also handle project management and education activities and in some cases development. In your team consultant knows most about SharePoint, but he can also consult your customer about collaboration, document management, records management, enterprise search etc.

In the following table I outlined some differences of the basic MSF team model and roles in a SharePoint team. Please note: for smaller teams you do not need 7 roles because some team members can be in more than one role. Please consult MSF for details on this.

MSF Role Cluster
MSF Goal In a SharePoint Team
Product Management Satisfied customer When selling services you need an account manager. AM is responsible to
find open new sales opportunities, he needs only basic knowledge of
technology but a fair knowledge about business processes surrounding it.
Program Management Delivering a solution within project constraints Similar to MSF, but your program manager must know his way around
SharePoint very well! Managing a SharePoint project is not an easy job
for a PM that is not familiar with the product itself.
Development Build to specification A SharePoint developer is not a regular .NET developer, this guy needs to know some additional “tricks”. Patrick did a great job outlining requirements
for a SharePoint developer. If you plan to hire a newby please note
that it takes 3-6 months for an ASP.NET developer to become completely
productive in a SharePoint environment.
Test Approve for release only after all
product quality issues are
identified and addressed
For a larger project you should definitely hire a QA Lead. Consider
unit tests, continuous integration, daily build and smoke test. Testing
SharePoint solutions automatically is hard but is not impossible! It is
a must have for a larger project.
User Experience Enhanced user effectiveness If you are building a SharePoint solution that includes custom design
you will need a designer. Designer should have advanced knowledge of
HTML and CSS and he should be familiar with ASP.NET. In order to
produce some work he will have to learn SharePoint Designer, the key
tool for adapting SharePoint design. It will take some time for a
newbie to learn the tool and SharePoint in order to modify the design
properly. Give a newbie enough time since design customization is not
easy.

For larger projects will need a trainer to conduct education of the end users.

Release Management Smooth deployment and
ongoing operations
It is a good practice to add a system engineer to your team. This guy
should know his way around IIS, SQL, ISA and other core infrastructure
server components. Although most customizations will be done by
developers having a good system engineer will ease the deployment
customizations of production environments.

So, the ideal SharePoint team is:

  1. Consultant
  2. Account Manager
  3. Project Manager
  4. Developers
  5. QA Lead (QA engineers)
  6. Designer
  7. Trainer
  8. System engineer

Related articles:

7 Comments

  1. http:// Says

    thanks. good stuff for us to know and start planning resources

  2. John Ross Says

    I agree with 100% of what you said — however not every SharePoint implementation project warrants a massive team. The vast majority of companies are implementing SharePoint with a team of 3 or less which includes 2 techies if they are lucky. I recommend people start with the SP Consultant you mentioned, gather requirements, then configure the site — no custom development initially. Then identify gaps in the requirements where the ootb functionality can’t do the job and do targeted custom dev. The main point being — I think only the biggest of the big implementations require massive teams. Especially considering what can be done if the ootb features are fully leveraged and someone has a solid knowledge of 3rd party products.

    -John

  3. toni Says

    @John: I could not agree more. This is just a ideal – full team. We also have projects where there is only one full time person (consultant) and a couple of part-time specialists like system engineer, developer etc.

  4. Andy Dale Says

    Good starting point, but I feel this is too Technical minded. You seem to be ignoring the Stakeholders. It is vital you get all areas of the business onboard from the beginning it is not an IT Project.

    officetalk advise all customers to include project team members from all areas of the business and these usually become Super Users after the project goes live.

    Regards,
    Andy Dale
    Information Specialist
    Officetalk
    Suite 7, Haddons Acre
    Station Road, Offenham
    Evesham, Worcs
    WR11 8JJ
    Tel 01386 833 535
    Mob 07920445739
    Email : andy.dale@office-talk.com
    Website : http://www.office-talk.com
    Blog : http://andydalesharepoint.blogspot.com/

  5. http:// Says

    @Andy: I could not agree more. We are also advising the same thing. The post is about forming your part of a project team.

  6. C. Hansen Says

    Building the right Factory Floor requires maturing an intake and work classification system.

    Not all projects are Large Spend.

  7. john Says

    We are implementing using a small team with most with 2 roles. project manager, business analyst, both of which have technical backgrounds and will assit with central administration, content types etc. a technical lead for sp and a sp developer.

    I agree initial implementation should have little or no customisation for thew business.

    I think a scum like approach may be beneficial to users as they really dont know want they want because they havent used a system like this before.

Leave a Reply