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 http://technet.micro- 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): http://technet.microsoft.com/en-us/ 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: http://www.sharepointgeoff.com/spsprjmgmt/ 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: http://technet.microsoft.com/en-us/library/cc262108.aspx. • 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. . 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. 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. 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