Help
from Chapter 6
Building SharePoint 2010 Resources
In the Plan phase for the SharePoint 2010 implementation, tasks are focused on gathering software and hardware resources. The resource information related to these resources includes user and technical data, provided against a backdrop of the client’s current system performance, resilience, disaster recovery plan, and business continuity plan.
During the resource information-gathering phase, reviews compare what has been made available to what the client needs are, and they are adjusted against the timeframe and funds available in the project budget. The reviews also take into account the client’s vision of the predicted budget as defined earlier in the SharePoint 2010 Quality Plan.
SharePoint 2010 software and hardware resources are many. They are detailed and complex and often need to be recorded and quantified with care. You’ll need to strike a balance between providing a system that can be scaled for growth in a carefully managed way and one that is scaled for growth by having everything switched on just because you think the client might need it.
For example, I was called by a client who had a problem with their SharePoint implementation. It had seemed like a good implementation when it was set up—the scope of the delivery matched up with the client’s support and resiliency arrangements. However, a problem developed with a service that automatically took information from a database and posted the outcomes into a SharePoint list. The client had over 300,000 items in one list, and the list was still growing. They noticed their search function starting to slow. They also noticed that the search index was growing out of control. They were running out of disk capacity. From a quick check of the list configuration, I noticed that it had “Include in search” switched on, meaning that all items would be included in the search index. Another check also identified that the Business Data Connection (BDC) included the indexing of all the fields so that they were included in the search scope also.
Although that example might be a little too detailed, it makes the following points:
- There is little point in switching everything on unless there is a direct requirement to do so.
- You need to review and justify exactly what is required to deliver SharePoint to the client.
Additionally, some implementations of SharePoint 2010 fail to recognize that features need to be balanced. This means you must follow a program of events to get all features required from SharePoint and that risk management needs to be carried out at every stage of implementing SharePoint 2010.
For example, apply these considerations to a car. You want to buy a bigger engine for the car to make it go faster. But if you don’t research whether the brakes are sufficient at higher speeds, you could be heading for an accident!
Therefore, make sure you compile a complete list of assets, and then set out a configuration management plan to deploy them.
SharePoint 2010 technical resources are split between hardware and software expertise, so the individuals responsible for identifying the physical nature of the SharePoint 2010 technical configuration must be skilled in the platform. Put another way, they need to know not just the engine but the entire car. They must have system analyst skills so that they can be relied upon to collate, record, and design according to standard procedures and practices. They also need to be able to follow rules about how the data will be captured and where the data will be stored because that data needs to be accessed by interfacing technical teams.
What Procedures Detail Rules Concerning SharePoint Project Resource Data?
Think carefully about your document control and records retention strategies. Going down the route of assuming, “I could easily get a record of all SharePoint 2010 resources by making a couple of phone calls and then enter that straight into my notepad,” is probably not going to make you many friends within the interfacing teams—especially if they have processes that ensure the data is recorded in a format they are happy with. However, one of the best ways to capture the data is using SharePoint 2010, because you can ensure that the data captures meet the format the interfacing teams are happy with, that it is standardized, that its far easier to collate, and—very importantly—it’s a repeatable exercise.
Using SharePoint 2010 Sites for Project Recording
SharePoint 2010 has excellent project-management recording capabilities. A starting point for taking advantage of these capabilities is to create a Projects site within the SharePoint One-Stop Shop specificially targeted at being the database for the SharePoint 2010 implementation. In the previous chapter, I mentioned that you should approach a SharePoint 2010 implementation by already having a Project site (for example, a proof-of-concept environment) for the SharePoint project team. You maintain this team site until you have a SharePoint production environment, and then you migrate the team’s SharePoint 2010 Project site into that environment as part of the SharePoint One-Stop Shop. SharePoint 2010 includes a site template that allows you to create a Project site as I just described. It is the Projects Web Database template, which you access from the Create screen (click Site Actions --> New Site when visiting the home page of the site), as shown here:
The Projects Web Database site you create interfaces completely with Microsoft Access 2010, which enables you to design a fully functional Project Management site to manage resource gathering for the SharePoint 2010 implementation using Microsoft Access 2010 features, including taking advantage of all the data repositories (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.
The following figure shows an example of the three phases injected into the Open Projects tab of a 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. A few of the typical tasks that would be included in the PHASE 1 PLAN phase are shown here:
The tasks listed in the relevant sections are assigned to contacts who are listed on the Users tab.
Building SharePoint 2010 Resources: The Tasks Ahead
As mentioned earlier, various tasks must be completed to ensure you have all the information needed to move into the next phase (Build).
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 carried 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 Microsoft 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...nt/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 completing 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.
What Is the Output of the Resource Gathering?
After you have documented all the tasks, you can create a SharePoint 2010 Requirement and System Specification document. After you complete it, you put the Requirement and System Specification document through a verification exercise, which is required prior to seeking signoff on it. That signoff is crucial—it marks the start of the next and final stage of SharePoint 2010 implementation: the Deploy phase.
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 requirements 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 co-ordinated 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
Client 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 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.
Example #2
Client 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 needs 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. Information analysts might be required (if available) to provide a higher level perspective on how these “keywords” are defined for the organization. SharePoint architects and administrators are then needed to ensure the search functionality as well as SharePoint 2010 Managed Metadata Service are 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 co-ordinated effort within the project team to ensure that data is defined, prioritized, and scheduled as tasks so that SharePoint 2010 recieves 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 necessary 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 they also manage access to the locations where SharePoint 2010 is to be delivered (for example, the 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
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 database administrators (DBAs). That means there must be co-operation 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 generation of service accounts, their permissions, disaster recovery, backup, and so on. That 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 afer the platform and how. If support for the topology is not agreed, there will be difficulty for SharePoint 2010 to scale up beyond the physical topology, because the topology is what defines the level of 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 architecture, you factor in resilency. So, for example, you might indicate that the hard disk drives are set up as a Storage Area Network (SAN)—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—so that you are able to attach or unattach drives to SharePoint servers for disaster recovery reasons.
Therefore, 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
- An installation guide that uses all of the preceding documents to install SharePoint 2010 according to the topology defined in the first document listed and that covers the actual steps from start to finish (that is, from basic server SharePoint 2010 installation through site collection and service application configuration).
- Testing documents to verify and validate the installation completed
These seven documents are also used in the creation of the SharePoint 2010 Requirements and System Specification document.
Learn more about this topic from Managing and Implementing Microsoft® SharePoint® 2010 Projects.
With this practical guide, you’ll gain project management best practices for implementing SharePoint 2010 in your organization, and learn expert techniques for tuning your system to match the communication and collaboration needs of your users.
