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
Posted
06-29-2008 11:34 PM
by
toni