The Content of Your SharePoint 2010 Project Plan

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 3

Create the SharePoint 2010 Quality Plan

The SharePoint 2010 Project Plan (which we will go into detail after this section) should ensure that the contractual requirements of the project are completely fulfilled. On a large project a project plan might be produced for each identified subsystem that is part of the overall product.

The SharePoint 2010 Project Plan complements the SharePoint 2010 Quality Plan; duplication of information or instructions from one plan to the other should be avoided. In simple terms, the SharePoint 2010 Project Plan details the what, why, where, and when aspects. The Quality Plan determines the project policies and the aspects of how and who.

During your initial meetings with the client, you identify the client’s requirements. These requirements are then used to produce the SharePoint 2010 Quality Plan. The SharePoint 2010 Quality Plan details the business requirements and specifies how the project will deliver these requirements. At the end of this chapter is a diagram depicting how the SharePoint 2010 Quality Plan and the SharePoint Project Plan connects together. That diagram also states the entities (such as configuration management, risk management, work breakdown structure etc.) connects.

The SharePoint 2010 Quality Plan includes the following:

• Project organization and responsibilities
  
• Risk management
  
• Subcontract management
  
• Design and development life cycle
  
• Configuration management
  
• Verification and validation plans
  
• Acceptance and delivery

You might be thinking, “OK, when I install SharePoint 2010, I can do all of that at the same time or ignore it.” If you choose to proceed like that, you will be responsible for signing off on all the implementation to the client’s satisfaction; you will be assuming the client does not need to be satisfied. I think that’s a mistake. You would be very unlucky if you were pushed to provide a companywide SharePoint 2010 solution and there's no team currently looking after the technology and no person who knows about how it was designed in the first place. Things are not going to go very well if you adopt that method!

To build a SharePoint 2010 Quality Plan you need to use the Project Startup Checklist. This checklist has a section called ‘Produce Plans’ and the Quality Plan is an item in that section. Once a Quality Plan draft is completed you should indicated a Y (for YES) in the Y column and give an identifier so that people can locate the Quality Plan in the reference column. So, continuing on from the headings given above you would be able to create a Quality Plan.

Project Organization and Responsibilities

The SharePoint 2010 Quality Plan needs to be defined clearly with the help of the business stakeholders. To do this, you need to delineate the relevant areas of the business—first you identify who the key stakeholders are and then identify who in the project team needs to interface with the technical and business teams that will be supporting the product. Technical teams who are the people who will be administrating SharePoint and managing the servers which provide SharePoint services. Business teams who will be supporting SharePoint team sites and content on those sites. These Business and Technical Teams will have responsibilities listed. For example, one Technical Team could be called ‘SQL Database Team’. Therefore, they will have certain responsibilities to the SharePoint implementation – looking after the SharePoint SQL Databases will be one of those responsibilities. Likewise, Business Teams will have responsibilities too. For example, you could have identified a Business Team who would be responsible for testing a SharePoint Site or SharePoint feature. Responsibilities will create Objectives (for example, in order for the Business Team to test SharePoint they would need SharePoint Training). Make sure you make a point of recording with each member of the project organization responsibilities and objectives. To formulate a work schedule, you need to ensure that you know who is responsible for what in the business. For SharePoint 2010, there are two camps you must deal with. The first camp includes personnel who look after and support the technical infrastructure—for example, Active Directory, Microsoft SQL Server, Microsoft Exchange, the firewall and security elements, and so on. This is the technical camp. Then there is the business camp. The people in the business camp will shape your SharePoint 2010 environment; they will tell you what needs to be in the environment, how it will function, who will own the implementation, who will test it, and so on.

First let’s make a list of groups within those two camps, and then list the name of the person accountable for a particular service in a group, as well as their contact details. This is one step in forming the Project Startup Checklist.

After you have identified who is responsible for what in the company, you need to start involving your own team (meaning yourself, the architect, the business analyst, and others). The Project Startup Checklist refers to your team-building efforts as “Appointment of Project Staff.”

Note that you do not need to list everyone on the technical team because it’s the responsibility of the technical manager, as a decision maker, to identify who they are. For SharePoint 2010, you must know who is currently responsible for the infrastructure (including security), messaging, user data store, and database. And because we are talking about SharePoint 2010, the infrastructure includes technologies such as SQL Server, Exchange Server, Active Directory, and Forefront TMG

You need to systematically identify and assess the potential risks to the project. By this, I mean risks to the entire project, not to some internal and technical component of SharePoint 2010 (which are risks covered later as part of configuration management). Also, these are not risks related to compliancy and access to SharePoint 2010 content on sites (which are risks covered later as part of SharePoint 2010 governance).

• As you might recall from the mention of the project mantra in earlier chapters, the client has a vision of the SharePoint 2010 implementation as benefiting the organization by providing a boost in productivity. If there is a risk that any of these client benefits cannot be attained, this risk must be communicated to all people in the list of stakeholders (stakeholders are listed in the Project Organization and Responsibilities section).Organizational Productivity Addresses process automation, information access, and roles. This is a client productivity goal – individuals in the organization should be able to work more efficiently using SharePoint 2010.
  
• Personal and Team Productivity Addresses user enablement, user adoption, and ease of use. This is a client productivity goal – individuals in the organization should be able to faster understand how to use SharePoint to meet their information objectives,
  
• Infrastructure Productivity Addresses responsiveness, reduced complexity, and reducing TCO (Total Cost of Ownership) This is a client and technical authority productivity goal. SharePoint as a platform should be responsive, resilient and reduce TCO (e.g. reduce hardware and software (licensing) costs)

In any organization where you are going to implement SharePoint 2010, you need to adopt a risk management process and the document stating the process should be referenced in this Risk Management section

This section of the SharePoint 2010 Quality Plan titled Risk Management would detailing the top-level risks and what strategy will be taken to mitigate these risks.

Subcontract Management

You might at some point in the implementation of SharePoint 2010 require third-party aid. For example, you might want to bring in a developer team to customize SharePoint 2010, or you might need to provide a third-party feature for backup tasks, restore functions, and so forth.

Before going down this route, you need to ensure that there is a need to bring in a party outside of the selected project team. Don’t get caught in the syndrome known as “developing beyond SharePoint 2010.”, In any uncontrolled development, whether software or hardware, falling prey to such a syndrome can have a serious negative impact on the productivity of the platform, resulting in SharePoint 2010 implementation pain to the client.

The topic of SharePoint 2010 subcontracts is normally raised when it is considered, for whatever reasons, more effective to place discrete packages of work relating to an existing SharePoint 2010 environment in the hands of a company outside of the organization. The SharePoint 2010 Quality Plan needs to state that it will or will not advocate the use of these services as part of the implementation. If the service is required, the this section of the Quality Plan needs to state the nature of the engagement with the subcontracts and specify that the project manager will follow organizational principles and rules governing the hire of such contracts.

Design and Development Life Cycle

Various factors discourage the design and development of a SharePoint 2010 implementation: it costs money, it uses the time of the most highly skilled people, the time spent in producing the plan can delay the start of using it, this life cycle could cause inflexibility in the implementation approach, or estimation of this life cycle is difficult. These objections do not detract from the importance of proper design and development.

The requirement for SharePoint could be as simple as this:

The installation of a SharePoint 2010 environment, which can be accessed via the Internet by a company worker.

According to the above statement, the basic design delivers a SharePoint 2010 extranet. To complete the design and development you would have to review security features of SharePoint 2010, and need advice from the Information Security in the organization concerning internet access policies. Further investigation is always required to document and provide a detailed design.

The detailed design of the SharePoint platform would not go into the SharePoint 2010 . The SharePoint 2010 Quality plan merely lists the various design aspects the client requires as these become schedules of work on the Project Plan. Design and Development of SharePoint 2010 is a two staged approach. First, you will need to detail the client aspirations using the three ‘productivity’ statements. These are described in the the above section Risk Management (Operational, Personal and Team, Infrastructure Productivity). Using those productivity statements you can map them to these questions and complete the Design and Development section of the Quality Plan.

• Collaboration Questions (Operational Productivity): What kind of data do you produce? Do you want users to create their own sites? Do you have any geographical regions or any regions overseas? Are there any governance concerns, such as branding or storage?
  
• Technical Questions (Infrastructure Productivity): Where are your data centers? What are the Change Management procedures? The Procurement processes? The Installation processes? Where are the Backup environments? Where are the Developer environments? Does a Test Lab exist?
  
• Content Questions (Personal and Team Productivity): What Web content do you have? How do you manage publishing online content?
  
• Search Questions: What do you want to include in the search? How big is the content you want to search? Who can access these locations? What should be excluded? What kind of data should be crawled?

The second stage of Design and Development requires the gathering of detailed user requirements and technical requirements. The process for carrying this out is covered in the Chapter 11, “Making Sure SharePoint 2010 Meets User Requirements” and Chapter 12 “Producing the System Specification”.

The Design and Development section of the SharePoint 2010 Quality Plan therefore requires:

• A statement concerning what kind of SharePoint platform is needed
  
• A paragraph describing the high level design options
  
• A paragraph describing the references to the user and technical requirements.

Configuration Management

Configuration management for SharePoint is a process, the detailed recording and updating of information that describes the hardware and software which make up the organizations SharePoint platform. Configuration Management means that you can record information concerning versions and updates that have been applied.

The Configuration Management section in your SharePoint Quality Plan should briefly describe the nature of your Configuration Management System that your organization uses, and who will carry the responsibility to update the Configuration Management System (typically this is a specifically assigned individual, but can be assigned to each member of the Project team, however, this means training them on how to use the Configuration Management System!). If there is a process / policy / procedure regarding Configuration Management that needs to be referenced.

Configuration Management is crucial since it allows, for example, a SharePoint Administrator to find out what is currently installed on a particular SharePoint server, or to find out what version of a 3rd Party application is installed.
This topic is so important it has its own chapter: Chapter 10, “SharePoint 2010 Configuration Management.”

What kind of information should be captured in Configuration Management?

• Makeup of the infrastructure (for example, farm topology, server physical nature, Windows operating system, and connected systems).
  
• Software and hardware assets (SharePoint 2010 version, connected systems versions—for example, location of binaries, hardware details, serial numbers, MAC addresses, service accounts, and so forth).
  
• Modification and procurement (including details about alterations to the hardware or software and any information concerning how or where they were obtained). For example, in SharePoint 2010, it includes details about the specific configuration carried out.
  
• Tracking and audit (including details concerning installation, alteration, and who carried out the installation or alteration).

Configuration management involves controlling the specifications, drawings, software, and the related documentation that define the functional and physical characteristics of SharePoint 2010 down to the lowest level, in order to assure standardization. Configuration management provides a documented, traceable history, including any modifications or variants. You absolutely must have configuration history for SharePoint 2010.

Some Configuration management systems are connected into a Change Management or Service Desk system. These are systems that allows people to record requests, incidents and raise requests for changing hardware, software or a setting in an production environment. For example, if any modification of the platform is required, an individual (or nominated) would raise a service or change request to ensure the work went through the correct approval and other processes before being done.
Hence, Collection of information that needs to be recorded in your Configuration Management System is a continual process, and is not recorded in the SharePoint 2010 Quality Plans Configuration Management section. Only the details about the location of the relevant policy, who is responsible for Configuration Management, and referred documentation that describes the Configuration Management Plan / Policy / Process is needed.

Verification and Validation Plans

To fulfill the client requirements, you would ensure, of course, that there is an agreement on what constitutes a completed SharePoint 2010 implementation To do this, you need to prepare a Verification and Validation (known as V&V) plan. In this plan, you might be required to provide specific acceptance tests to ensure that SharePoint 2010 meets the client’s requirements. (This can, for example, include not only the client’s acceptance of the physical environment, but also items such as branding, functionality, resiliency, and so forth.) These acceptance tests can be considered the final stage of validation and require careful planning.

The SharePoint 2010 implementation should be subject to V&V activities to confirm that the logical planning put in place matches the physical environment. This is carried out at the server level and then at the component level, ending with being applied at the SharePoint 2010 application level. The scale of the V&V activities should be appropriate for the size of the SharePoint 2010 installation and the nature of the installation. V&V activities must be planned, documented, and systematically managed in accordance with contract requirements. The V & V Activities are all listed within the V & V Plan. These activities must be conducted at discrete stages of the project and record the following information:

• Acceptance testing of the product
  
• Third-party products to be added to the SharePoint 2010 environment
  
• Internally developed tools to be added to the SharePoint 2010 environment
  
• Modifications that will affect the SharePoint 2010 environment
  
• Impacts to the disaster recovery or business continuity aspects of SharePoint 2010

This section in the SharePoint 2010 Quality Plan would reference the V&V Plan and its location.

Acceptance and Delivery

The “Acceptance and Delivery” section of the SharePoint 2010 Quality Plan states who is going to be responsible for signing off on the project as completed, and it includes a statement of what constitutes a successful SharePoint 2010 implementation based on the project scope. Additionally, it also states how SharePoint 2010 will be handed over to the client. You can’t simply say, “Hey, I’ve installed SharePoint 2010 on your servers. Now I’ll leave you to it. Let me know if it works.”

You must ensure that SharePoint 2010 has been fully tested (a process known as acceptance testing), from its lowest level (accessing SharePoint 2010) to the various advanced features that have been deployed.