Building Your SharePoint 2010 Team

Today we continue our serialization of excerpts from the forthcoming eBook, Managing and Implementing Microsoft® SharePoint® 2010 Projects (Microsoft Press) by Geoff Evelyn.

from Chapter 5

What Is the Terms of Reference, and Who Creates It?

The Terms of Reference (TOR) document is created by the project manager using information from the SharePoint 2010 Quality Plan and Project Plan. The items within the Terms of Reference are used to specify who has the authority and responsibility for the various areas of work. These items should always be reviewed to ensure they reflect the size and scope of the SharePoint 2010 implementation. The TOR is written before you assemble the team, meaning that you don’t attempt to create it until you know what needs to be done, who is going to do it, and in what context it will be done.

Note
You will need to create a TOR for each member of the team since each will have different responsibilities. All TORs are to be entered into one document and you should make a reference to the TOR document from the SharePoint 2010 Quality Plan in the section Project Organization and Responsibilities. Changes to a TOR are updated in the TOR document.

What you don’t want is a situation where the client has given you resources because they assume your team will be just like any other IT project out there. SharePoint 2010 should not be treated that way because it is a content management system. This means the storage, sharing, auditing, security, tagging, and categorization of project information requires the business to be an integral part of the project. If you think of SharePoint 2010 as just another software product and that installing it simply involves a click here, a click there, and a brief installation exercise, you’ll find that it will not solve many business issues. Also, by taking such an approach, you would fail to use your team’s skills to the extent required by the product. This flawed approach at the start ultimately leads to the failure of the SharePoint 2010 implementation.

So, you start by creating a TOR, which the client or the client’s technical authority then signs off on. This document gives you and your team focus and helps you put in place your SharePoint 2010 project mantra. In the following sections, I’ll discuss who the key people are on a typical SharePoint 2010 implementation team.

When building the TOR for your SharePoint delivery team, make sure you write each one in a standardized way.

Project Manager

The project manager has a single, overarching responsibility: to deliver the successful completion of the project within the guidelines of the budget, resourcing, and scope. The delivery effort requires planning, control, and technical judgment—the project manager’s responsibilities are primarily related to planning and control.

Project Manager Role

For the project manager to carry out his responsibilities, he requires the full support of the client’s business group; therefore, the authority to plan and implement the SharePoint project is granted by the client through the Terms of Reference for the project manager role. The project manager, then, has the ability to recruit the team and set the terms of reference for each team member. It is absolutely critical that the project manager has final say on this, and any alterations to any individual’s TOR must be agreed to by the technical authority or client and the project manager.

To support the project manager in larger SharePoint implementations, you should include a project coordinator, who will help gather and organize documentation. Essentially, in larger projects, the project manager requests support from the project coordinator for things such as document and data control. This support role is useful in SharePoint 2010 because the coordinator can manage the project site within the SharePoint 2010 One-Stop Shop (which is discussed in more detail later in the chapter).

Terms of Reference

The SharePoint project manager is responsible for the following:

• To plan and control the activities of the SharePoint 2010 project by maintaining an up-to-date program and cost-to-completion tracking, monitoring project progress, and initiating corrective action where required
  
• To ensure that all staff allocated to the project are gainfully employed, minimizing contract effort
  
• To liaise with other managers in the business group and line of business (LOB) when planning staff allocations to ensure that the project’s requirements for staff are met; that vacancies are identified in good time where they exist; and staff, whose allocation to the SharePoint 2010 project is ending, are reassigned as quickly as possible after their assignment is complete
  
• To ensure current and planned expenditure is contained within approved budgets, and to ensure that no work is undertaken without authorized financial cover
  
• To ensure that the team adheres to the SharePoint 2010 Quality Plan
  
• To provide technical guidance to project staff, or to delegate such guidance to a nominated member of the team
  
• To delegate the management of tasks and subtasks where appropriate, and to ensure that the management of those subprojects conform to the SharePoint 2010 Project Plan and SharePoint 2010 Quality Plan
  
• To manage project risks using, where appropriate, a formal risk register within the SharePoint 2010 Project Plan
  
• To ensure that technical reviews are held and recorded and that follow-up actions are discharged and closed down
  
• To provide monthly reports or, as otherwise directed, record the status of and outlook for the project
  
• To check, in conjunction with the designer technical authority, that staff members allocated to the project have sufficient qualifications and experience to do the work they are being tasked to undertake
  
• To contribute to staff performance reviews as part of the appraisal process
  
• To manage the equipment and facilities under your control in accordance with company policies and procedures
  
• To communicate matters of company, divisional, and local issues to staff, and to represent their concerns to your client manager

The SharePoint project manager has the following authority:

• Tasking of staff assigned to the project
  
• Authorization of all formal project documentation
  
• Financial authority, within the limits set
  
• Authorization of time sheets for project staff

SharePoint Technical Authority: SharePoint Architect
The SharePoint architect is a key resource for the SharePoint implementation. This person is knowledgeable of the platform from the operating system through dependent technologies such as DNS/WINS, firewalls, infrastructure design, capacity, growth, performance, and resiliency. This person also must have a strong understanding of what it takes to fulfill a SharePoint 2010 business requirement.

In summary, this person will be very knowledgeable about SharePoint 2010 Foundation and SharePoint 2010 Server.

SharePoint Architect Role

Because this role is central to the provision of a SharePoint platform, the project manager and the client’s technical authority must work together to recruit this individual (because this is a client-facing role). This person will interface with the SharePoint project team, the client’s technical teams, and the business (for example, information analysts) on a daily basis. It is the SharePoint technical authority’s design, the communication of that design, and the output of that design to the configuration of SharePoint 2010 that maps to the client’s vision, so this person does need to be highly skilled.

Terms of Reference

The SharePoint architect will be responsible for the following tasks:

• Advising on the design and analysis techniques, as well as on procedures that should be used in the SharePoint project
  
• Detailing disaster-recovery specifications
  
• Detailing capacity plans
  Detailing network security
  
• Providing support to the project manager in reviewing the customer requirement; helping to produce the requirement specification

SharePoint 2010 Administrator

The SharePoint 2010 administrator is responsible for the initial configuration of the platform and follows the rules stated by the SharePoint architect and technical authority. She provides the groundwork for SharePoint monitoring and diagnostics.
There are a number of excellent tools within the central administrator function in SharePoint 2010, including a SharePoint Best Practices Analyzer and Health monitor, which will help administrators solve problems. Additionally, the ability to manage the SharePoint 2010 environment—in terms of disaster recovery, backups, and reporting—is much improved.

SharePoint Administrator Role

It is important to have a SharePoint administrator in the early days of the SharePoint 2010 implementation because the administrator becomes a third line of support after SharePoint 2010 is live.

Terms of Reference

The SharePoint administrator is responsible for planning, operating, maintaining, and optimizing the SharePoint 2010 environment. On a day-to-day basis, this person is expected to work with other internal teams defining services, hosting, and maintaining security authentication and data mirroring. This person also works through central administration monitoring quotas, throttling, reporting, and carrying out system maintenance.

The SharePoint 2010 One-Stop Shop

SharePoint 2010 is an awesome tool for project management document control and planning. It provides all the relevant features and benefits, allowing you to build a successful and repeatable project management office. This project management office will include and become the SharePoint One-Stop Shop for the organization, functioning as a crucial resource.

One-Stop Shop Role

This SharePoint 2010 site will house everything related to the SharePoint 2010 implementation. This includes policies, statement of operations, FAQs, “How Do I” files, performance and resiliency information, backup information, requests for sites, keywords, and even an Admin section for SharePoint 2010 administrators to use.

Terms of Reference

The SharePoint One-Stop Shop is responsible for the following:

• Serving as the central repository for all project-related material related to the implementation of SharePoint 2010
  
• Provisioning of collaborative features that allows information to be shared among project members and project visitors
  
• Providing a home for any organizational SharePoint 2010–related topics

Interfaces: Teams in the Organization

A significant number of components and platform technologies are connected to any installation of SharePoint 2010. What makes SharePoint 2010 really special is that you can add further components to it with ease. Of course, you would never connect all of this yourself, because you are not “Super-Person”! You need various teams to work with you. Also, by bringing in these teams, you increase their knowledge of the platform and ensure they have an understanding of it from a technical and support perspective.

Here are a few of the technologies required to enable SharePoint 2010 to operate:

• Active Directory
  
• Microsoft Office Exchange
  
• Microsoft SQL Server
  
• Microsoft Windows Server

Some people might argue that they can easily install SharePoint by themselves in a single-server environment. While this is achievable, it’s not really advisable. If you install SharePoint, Active Directory, Exchange, and SQL Server on a single server, you’ll end up with not having an easily scaled solution or a supportable platform. Some SharePoint projects start that way and then fall into trouble because the person installing SharePoint has not factored in at the start of the implementation where the client wants to go with SharePoint. And that person has not identified what the user requirements are and worked out how SharePoint will grow with the organization.

Summary

All implementation technical teams are similar, but SharePoint 2010 projects are not a pure technical effort. A SharePoint 2010 implementation requires people with business skills, technical skills, project skills, information analysis skills, training skills, and so on.

A SharePoint 2010 project implementation team also requires a clear set of tasks. These tasks, related through project Work Breakdown Structures right back to the SharePoint 2010 Quality Plan, are tied into the Terms of Reference for each of the team members. The project manager builds these TORs because that person is accountable to the project.

In any SharePoint 2010 implementation project, there are many technical tasks, business tasks, and key people that are required:

• Design: SharePoint architect, SharePoint administrator, business analyst, internal teams, and external teams
  
• Taxonomy and Metadata: Information architect
  
• Governance: SharePoint architect and information architect
  
• Build: Internal and external teams, SharePoint architect, and SharePoint administrator
  
• Configuration: SharePoint administrator, SharePoint architect, and internal teams
  
• Deploy: SharePoint administrator, SharePoint architect, SharePoint developer, and internal teams
  
• Test Quality Assurance: Client business elected, and technical authority
  
• Support: SharePoint administrator
  
• Maintenance: SharePoint architect, SharePoint administrator, governance (business)

While it is possible that the people in the preceding list can be drafted into the project as a mixture of consultants and internal staff, it is vital that a budget is available to outsource the expertise if it is not available in the organization where SharePoint 2010 is to be implemented. Good examples of outsourcing are the SharePoint architect, SharePoint developer, and SharePoint administrator because these roles require deep SharePoint knowledge that might not be available in the client organization. You might have to bring in further expertise if in-house experience is not sufficient (for example, SQL teams, Exchange consultants, and Active Directory consultants).

All of these teams are identified by the project manager, who consults with the technical authority when negotiating the availability of internal technical team resources.

Under no circumstances should someone be randomly elected “The SharePoint Techie” and be made responsible for the design of SharePoint 2010 if they don’t know the product deeply. Making your Windows Server administrator the SharePoint architect and administrator, for example, is courting disaster.

SharePoint 2010 features such as enterprise content management requires a combination of SharePoint architect, business analysts, and information architects, to ensure client and user requirements are fully investigated in a large organization. The business analysts glean the current business process and map this so that the work processes can be streamlined to SharePoint 2010. Information architects ensure metadata and taxonomy are applied to these processes—and that these are implemented into enterprise content management using the skills of a SharePoint architect. If the user requirements require further work on features that are not directly available in SharePoint, a SharePoint developer will be required as well.

For example, SharePoint 2010 Search feature enablement requires the same three people, as well as similar interfacing with internal technical teams—for example, the requirement of what needs to be included in search needs to be factored in (for example, what locations need to be searched; what sites need to be searched; when is search updated; and who can update search scopes, search keywords, tagging, and so on). This includes security as well (another interfacing team in this regard is the information security team).

A proper and successful SharePoint 2010 implementation is achieved through a combination of dedicated, skilled staff that has been given clear goals. Those goals must not only be achievable, but they must have detailed output through configuration management (the output from your team in implementing SharePoint 2010).