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:
- Consultant
- Account Manager
- Project Manager
- Developers
- QA Lead (QA engineers)
- Designer
- Trainer
- System engineer
7 Responses
thanks. good stuff for us to know and start planning resources
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
@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.
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/
@Andy: I could not agree more. We are also advising the same thing. The post is about forming your part of a project team.
Building the right Factory Floor requires maturing an intake and work classification system.
Not all projects are Large Spend.
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.
Comments are closed.