Chapter 6
116 Chapter 6 Gathering the Resources for SharePoint Implementation
Figure 6-1 SharePoint 2010 Projects Web Database template.
From the Projects Web Database site you can create interfaces completely with Microsoft
Access 2010. This enables you to design a fully functional Project Management site to man-
age resource gathering for the SharePoint 2010 implementation using Microsoft Access
2010 features. You can also take advantage of further customization using the data reposi-
tories (as tables) and fine-tuning the functionality of the forms.
The SharePoint 2010 implementation project is split into three phases: the Plan phase, Build
phase, and Deploy phase. You can easily transpose this approach into three subprojects and
use all the processes and procedures in this book.
Chapter 3, “Content of Your SharePoint 2010 Project Plan,” details the three phases of a
SharePoint implementation project.
Figure 6-2 shows an example of the three phases injected into the Open Projects tab of a
SharePoint 2010 Implementation Projects Database site.
Chapter.6
Using SharePoint 2010 Sites for Project Recording. 117
Figure.6-2. The Open Projects tab on the SharePoint 2010 Implementation Projects Database
site.
The Projects Web Database template includes Open Projects and Closed Projects sections.
These sections can be used to determine what phase has been completed. Each of the
phases are linked to a project. Because of this, you can define tasks for each of the phases.
Figure 6-3 shows a few of the typical tasks that would be included in the PHASE 1: PLAN
phase.
Figure.6-3. Tasks that appear as part of PHASE 1: PLAN.
The tasks listed in the relevant sections are assigned to contacts who are listed on the
Users tab.
Chapter 6
118 Chapter 6 Gathering the Resources for SharePoint Implementation
Building SharePoint 2010 Resources: The Tasks Ahead
As mentioned earlier, various tasks must be completed to ensure you have all the infor-

mation needed to move into the next phase (Build). To make it easier to understand,
tasks must be completed at each stage. Table 6-1 lists the relevant tasks along with a
description of each and a suggested resource you can use to help you build the resource
documentation.
Complete each of these tasks, and use the resources in Chapter 11, “Making Sure SharePoint
Meets User Requirements,” and Chapter 12, “Producing the System Specification.”
Note
These tasks do not run back to back, and depending on the environment being created
not every task requires all the resources noted. These are given as a guide so that when
you develop your SharePoint 2010 Project Plan, you are aware of the work to be car-
ried out in a particular phase (and as such the resources you’ll need). Additionally, and
as a reminder, this book will not describe the details of how you build the resources; it
describes what is required. To aid you, I’ve added TechNet links and other useful Micro-
soft resources where appropriate. A significant amount of resources and support are
also available on the Microsoft SharePoint site, which is located at ro-
soft.com/en-us/sharepoint/default.aspx.
Note
“Task” is the Work Breakdown Structure Task heading, and “Description” and
“Resource” refer to what must be done for the task and who is responsible for complet-
ing that task, respectively. You’ll need either Microsoft Project 2010 to enter these
tasks, or you’ll need a Gantt list from SharePoint to store these tasks and map them
against the documentation gathered.
Table 6-1 Relevant Tasks Needed for Building Resource Documentation
Task Description and Resource
Define Vision
Statement
The project manager agrees with the client and technical authority
as to what SharePoint will do for the organization.
Success Criteria This item is a statement about what constitutes a success when
SharePoint has been released to the client.

Resource: Project manager
Chapter.6
Building SharePoint 2010 Resources: The Tasks Ahead. 119
Task Description.and.Resource
Assemble Project
Teams and Define
Roles
Related tasks for this item include the following:
•
Recruit team members.
•
Create a Terms of Reference (TOR) for each member.
•
Assign roles and resonsibilities in the TORs.
(Review Chapter 5, “Building Your SharePoint 2010 Team,” for more
information on these tasks.)
Resource: Project manager and technical authority
Gather Technical
Requirements
Related tasks for this item include the following:
•
Detail SharePoint 2010 requirements.
•
Detail technology architecture.
•
Create SharePoint Server hardware and software inventory.
•
Create client hardware and software inventory.
•
Detail computing environment (communications rooms and

so on).
•
Create client service delivery model.
•
Detail content and audit activities.
•
List client and server licenses.
Resource: SharePoint architect, administrator, interfacing teams
(for example, Desktop, SQL, Active Director, Exchange), technical
authority
Gather Business
Requirements
Related tasks for this item include the following:
•
List audience requirements.
•
List user productivity requirements.
•
List access and permissions.
•
List content management requirements.
•
List migration requirements.
•
List taxonomy/metadata requirements.
Resource: Business analyst, end users, project manager, SharePoint
architect
Design Objectives Related tasks for this item include the following:
•
Map SharePoint 2010 against current computing environment.

•
Confirm integrated software strategy (for example, using
Microsoft Office 2010).
•
Investigate storage requirements.
•
Determine strategy for communicating project details to staff.
•
Determine information architecture approach.
•
Determine branding requirements.
•
Review with client and achieve signoff.
Resource: Project manager, SharePoint architect, technical author-
ity, client
Chapter.6
120. Chapter 6 Gathering the Resources for SharePoint Implementation
Task Description.and.Resource
Identify Coexistence Investigate and resolve company and external partner operating
systems, protocols, topology, and service delivery models.
Resource: Project manager, SharePoint architect, technical authority
Create a Test Lab Related tasks for this item include the following:
•
Select locations.
•
Confirm space, environment, power, and network requirements.
•
Design logical and physical configuration.
•
Determine access, roles, and permissions to the lab (includ-

ing the change control process, such as configuration
management).
•
Sign off.
Link (server requirements): />library/cc262485.aspx.
Resource: Project manager, SharePoint architect, SharePoint
administrator
Risk Assessment Related tasks for this item include the following:
•
Identify and analyze risks.
•
Investigate and detail escalation.
•
Evaluate quantity impact.
•
Document risks.
(For more information on the SharePoint risk-management pro-
cedure and how to use it, see the online article titled “SharePoint
Risk Management: at: />riskmanagement.aspx).
Resource: Project manager, technical authority, client
Project
Communications
Related tasks for this item include the following:
•
Plan, build, and deploy a communications strategy.
•
Define who should be informed, how the communications
should be delivered, and the timeframe and standards to be
followed.
•

Document and sign off on the strategy.
Resource: Project manager, client, technical authority
Define Education and
Training Strategy
Related tasks for this item include the following:
•
Define requirements.
•
Define education strategy and delivery for end users.
•
Define education strategy and delivery for interfacing teams.
•
Document and sign off on the strategy.
Resource: Project manager, SharePoint architect, interfacing team
(using an external trainer is a possibility)
Chapter.6
Building SharePoint 2010 Resources: The Tasks Ahead. 121
Task Description.and.Resource
Review Software and
Hardware
Related tasks for this item include the following:
•
Investigate client hardware and software, compare them to
SharePoint 2010 hardware requirements, and document the
differences.
•
Investigate the current desktop applications and determine if
an upgrade to Microsoft Office 2010 is beneficial.
•
Upgrade hardware/software if needed. (Note that this could

end up being another subproject!)
•
Document and sign off on this task.
Resource: Interfacing teams, technical authority, SharePoint
architect
Plan Security Related tasks for this item include the following:
•
Define the framework of SharePoint 2010 service accounts.
•
Define the framework of logical content.
•
Investigate internal security (for example, Active Directory,
infrastructure connectivity), including connectivity to Internet.
Resource: Interfacing teams, SharePoint architect
Performance Planning Related tasks for this item include the following:
•
Investigate, document, and confirm connectivity and band-
width, both current and required.
•
Investigate, document, and confirm network performance lev-
els, and diagram network topology to meet requirements.
•
Document and sign off on the plan.
•
Upgrade the network as required. (Note that this could end up
being another subproject!)
Resource: SharePoint architect, interfacing teams
Disaster Recovery and
Continuity
Related tasks for this item include the following:

•
Document the current disaster recovery plan (at the SQL Server
level and server level).
•
Document, confirm, and produce a plan for SharePoint 2010
failover, and list disaster recovery requirements.
•
Confirm Recycle Bin and site recovery planning.
•
Document and sign off on the plan.
Resource: SharePoint architect, interfacing teams
Localization
(Language)
Related tasks for this items include the following:
•
Determine and install the languages required on the test
platform.
•
Review the settings using SharePoint 2010 Multilingual User
Interface (MUI). You can find more information about this at:
/>•
Document and sign off on this task.
Resource: SharePoint architect, SharePoint administrator
Chapter.6
122. Chapter 6 Gathering the Resources for SharePoint Implementation
Task Description.and.Resource
Integration Related tasks for this items include the following:
• Confirm the SharePoint 2010 version required (Founda-
tion, Standard, or Enterprise).
• Confirm the SharePoint client tools required (for

example, SharePoint 2010 Workspace, Microsoft Office
Communicator).
• Confirm ForeFront Protection 2010 for SharePoint. You
can find out more information about this at: http://
technet.microsoft.com/en-us/forefront/ff521619.aspx.
• Determine the need for each of the following services.
If they are required, install and configure them on a
test platform. Document and sign off on the following
services: Search Service Application, Profile Service Appli-
cation, Access Services, Business Data Catalog, Excel Ser-
vices, Managed Metadata Service, Secure Store Service,
Usage and Health, Visio Graphics Services, Reporting
Services.
Service applications in SharePoint 2010 are a huge improvement
to the product, addressing many of the scalability compromises
inherent in the SSP model in SharePoint 2007. Service applications
can now be built by third parties and are available in both Share-
Point Foundation and SharePoint Server. Service applications sig-
nificantly impact farm topologies; therefore, it is more important
than ever to understand the core concepts.
Resource: SharePoint architect, SharePoint administrator
Maintenance Related tasks for this item include the following:
• Plan the farm backup and restore strategies.
• Plan granular backup strategies.
• Plan routine maintenance.
• Determine quotas.
• Configure zones and alternate access mappings (AAM).
• Plan site use and deletion.
• Document and sign off on the strategies.
Resource: SharePoint architect, SharePoint administrator

What.Is.the.Output.of.the.Resource.Gathering?
After you have documented all the tasks listed in Table 6-1, you can create a SharePoint
2010 Requirement and System Specification document. Once you have completed your
document, you can put it through a verification exercise, which is required prior to seeking
signoff. The signoff is crucial—it marks the start of the next and final stage of SharePoint
2010 implementation: the Deploy phase.
Chapter 6
Gathering Business Requirements 123
The SharePoint 2010 Requirement and System Specification document is described in
Chapter 12.
Gathering Business Requirements
To begin this phase, you need to identify the business requirements and the people who
will be needed for the implementation.
SharePoint Business Analyst
The responsibility of the business analyst is to collate and clearly record the client’s require-
ments so that they can be mapped to SharePoint. Before the business analyst can collate
the recorded data, a number of resources are required:
•
A location to store the collected data
•
A list of all the key data users and those who have a stake in managing data in the
organization
•
A list of coordinated events to ensure the data is recorded in each area
•
A standard set of questions that can be asked of each group
So, what is the connection between capturing client usage of content and the technical and
software requirements? Let me give you a few examples.
Example #1
C

lient A is using a software tool to record the state of items in a product life cycle.
This tool is known to the technical staff only from the perspective that they have
to support it; however, they don’t use it on a daily basis (because they are not the end-
users). Hence, they are concerned only with the inner workings of the software (the
engine) and not directly concerned with making it work (driving it).
The data gathering by the business analyst captures how the product life cycle works
and what the client does with the tool to make that happen. This data is crucial because it
allows the SharePoint architect to ensure that the life cycle of the product is mapped to
the features of SharePoint.
Chapter 6
124 Chapter 6 Gathering the Resources for SharePoint Implementation
Example #2
C
lient B creates content that is output in Adobe Acrobat format. The client is keen
to be able to search the output based on keywords injected into the PDF file.
A number of things need to take place. First, the business analyst records the process of file
generation and where and how the keywords are defined and injected into the PDF. Infor-
mation analysts might be required (if available) to provide a higher level perspective on
how these “keywords” are defined for the organization. SharePoint architects and admin-
istrators are then needed to ensure the search functionality as well as the SharePoint 2010
Managed Metadata Service is configured and enabled correctly.
Therefore, there is a direct relationship between the data provided by the business analyst
and the data provided from the SharePoint architect. The business analyst provides user
requirements defined by the business. The SharePoint Architect provides design and system
specifications to meet those user requirements. There needs to be a coordinated effort
within the project team to ensure that data is defined, prioritized, and scheduled as tasks so
that SharePoint 2010 receives the configuration it needs to get the requirements as detailed
in the data.
SharePoint Architect and Technical Authority
The technical authority works closely with the SharePoint architect by providing the nec-

essary experts needed in the field for all the interfacing teams (for example, SQL, Active
Directory, Exchange). These experts provide information that helps ensure SharePoint 2010
fits into the client’s environment. They are also important in helping to procure equipment
(software and hardware), and manage access to the locations where SharePoint 2010 is to
be delivered (for example, server communication rooms and data centers). It is during this
phase that the equipment required is identified and procured and the SharePoint 2010 test
environment is created.
The SharePoint architect creates a SharePoint 2010 physical topology based on the client
requirements concerning resiliency, performance, connectivity, and disaster recovery. The
server model exposed in that physical topology can be a distributed environment.
Let’s look at an example where you provision a small SharePoint 2010 topology based on a
three-tier small farm comprising the following:
•
Two Web front-end servers
•
One application server
•
One SQL cluster
Chapter.6
Gathering Business Requirements. 125
It sounds straightforward. However, this presents an operational challenge. Let’s say the
two Web front-end servers and the application server are to be supported by SharePoint
personnel. The SQL cluster, however, is already supported by a dedicated team of SQL data-
base administrators (DBAs). This means there must be cooperation between the SharePoint
personnel and the DBAs. The teams must aid one another, and the SharePoint personnel
must investigate the DBAs’ rules concerning connectivity to SQL—for example, in the gen-
eration of service accounts, their permissions, disaster recovery, backup, and so on. This also
means that the agreed-upon physical topology for SharePoint will require another level to
be added to the resource matrix, called support of the SharePoint 2010 platform. Support
of SharePoint 2010 is described as the nature of who will look after the platform and how.

If support for the topology is not agreed on, there will be difficulty for SharePoint 2010 to
scale up beyond the physical topology, because the topology is what defines the level of
support that needs to be applied to SharePoint.
Taking the preceding model further, you also need to list the specifications of the servers—
memory, CPU, hard-disk capacity, network connectivity, and so on. As part of the architec-
ture, you factor in resilency. So, for example, you might indicate that the hard disk drives
are set up as a Storage Area Network (SAN). SAN is an architecture used to attach remote
computer storage devices such as disk arrays, tape libraries, and so on, in such a way that
they appear to be locally attached to the operating system on the relevant servers. There-
fore, it is possible to to attach or unattach drives to SharePoint servers for disaster recovery
reasons.
Thus, the information the SharePoint architect needs to gather is significant. Knowing what
to gather is one thing, but there has to be a road map to the installation detailing what
relates to what. I suggest the creation of the following seven documents:
•
A Hardware Architecture document that deals with the topology, Web front end,
application, SQL connectivity, and connected technologies and systems.
•
A Variables and SharePoint 2010 Configuration document that takes into account
software configuration, service accounts, IP addresses, host names, and the service
application topology.
•
A Software and Related Components list that lists software needed (for example,
Windows Server 2008, SQL Server 2008, Office 2010, Visio 2010, Project 2010 and so
on) and other components (for example, dotNET, IIS, ASP, and other prerequisites).
•
An installation guide that includes information about server builds (for the operating
system, disk configuration, and so on).
•
An installation guide dealing with prerequistes related to installation and

configuration.