SharePoint Planning and Control: Start as You Mean to Go

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 4

All SharePoint 2010 Projects Must Be Planned and Controlled to Ensure Success

The planning and control procedure addresses the planning and control of all customer contracts related to the platform and formally authorized work. All SharePoint 2010 projects must be subject to formal project planning and control procedures appropriate to the type, size, duration, and risks involved. This procedure is associated with the SharePoint 2010 Quality Plan, the SharePoint 2010 Project Plan and the SharePoint 2010 Project Startup Checklist.

The Project Manager’s Responsibilities

The client provides the Project Manager with his/her Terms of Reference (TOR). This Terms of Reference must include the following statement:

The project manager is responsible for the planning and implementation of SharePoint 2010 and will engage his or her SharePoint 2010 team to deliver the client’s requirements.

The Project Manager will need to appoint other team members and generate their TORs (as listed in the project startup checklist ‘Appointment of Staff’ section’. You can also refer to Chapter 5, “Building Your SharePoint Team,” for more help in identifying the rest of the team and their TOR.

Both Project Manager and Technical Authority Are Essential

As well as a Project Manager, a Technical Authority is absolutely critical to the successful implementation of SharePoint 2010 and supports the Project Manager. The technical authority to plan and implement the project is delegated to the Technical Authority by the client through a TOR generated by the project manager.

The Technical Authority is there to ensure that there is a connection between project management and technical resources, and also to ensure that the delivery of SharePoint 2010 can be implemented and supported by the organization. They also ensure there are the relevant technical resources within the organization to support the project. The Technical Authority is not a project manager for SharePoint, but rather, a coordinator of technical resources by the business and signs off the delivery of SharePoint (from a technical perspective) on behalf of the client.

The Project Manager is essential.

A SharePoint implementation project cannot exist without a project manager. The project manager is not a SharePoint architect (though in small projects you could have the same person be the architect and project manager if the SharePoint architect can interface with both the technical and business aspects of the project.

The principal areas addressed by the project manager are these:

• Planning and authorizing the execution of the project—for example, the work required to collate business requirements; the work required to map those requirements to a SharePoint 2010 solution; the work required to build a SharePoint 2010 instance, including relevant features such as the training of the client and handover of SharePoint 2010 to the client.
  
• Defining the tasking procedures by which SharePoint 2010 is implemented—for example, capacity planning, configuration management, and so on. These tasks are then taken on by the SharePoint 2010 architect.
  
• Defining and implementing the appropriate progress-monitoring procedures—for example, a SharePoint 2010 One-Stop Shop, procedures to manage SharePoint 2010 after it is live.
  
• Maintaining the project records.
  
• Ensuring the project has been set as “Started” and “Closed” when required.

Although the project manager is delegated commercial authority on the project, it is recommended that support is given to her concerning the issues of major purchases (for example, servers, SharePoint 2010 user licenses, contract amendments, and so on).
If the project manager needs to exercise his responsibility in a different manner to that allowed by the procedures referenced, this circumstance must be identified in the SharePoint 2010 Quality Plan and the Quality Plan must be authorized by the business manager.

The preceding guidance is very important. A SharePoint 2010 implementation needs to be treated carefully so that the project does not go out of scope or out of budget when implementing features.

Let’s explain that with an example: The project manager of company XYZ gets a contract to install SharePoint 2010 and is provided a Terms of Reference explaining his responsibilities by the client. The business leaves the project manager to deliver the project. The project goes over budget, but this is not spotted by the business manager. The project manager, exasperated, goes to means outside of the Terms of Reference to get further funds for the project.

In this scenario, the project manager likely will lose face with the business manager. As such, the project is bound to fail or or introduce significant SharePoint implementation pain.

The SharePoint 2010 Architect Is Approved by the Project Manager and Technical Authority

It is vital that when providing SharePoint 2010 you enlist individuals who have a thorough understanding of SharePoint 2010 and who can describe how features of the product can be applied.

In my experience, there has been confusion between the purpose of the architect and the purpose of a developer. To me, a developer builds things. An architect designs things. That’s not to say that a developer cannot be an architect and vice versa.
I had a client who needed a SharePoint environment that was a simple installation for a small business of five people. I spent half a day with them, gathering information concerning their pain points, what they currently do, and how they want to improve what they do. They kept stressing that all they needed was somewhere to share information. I described the features of SharePoint concerning document management, upload, download, retention, and archiving, and they got pretty excited. At the end of the meeting, they said, “We really like all the stuff to do with content management in SharePoint, and we need to embrace that in our work process. We have a number of paper-based processes that we would like to get automated. Can we do that?”

“Of course,” I said.

Now, does that answer “Of course” mean that you bring in a developer right away? No. Because you are not customizing anything yet. You are designing. You have not even looked at whether certain features in SharePoint will meet the requirement. An architect with a developer’s hat on could determine whether that is or is not the case and, if necessary, suggest to the project manager that resources are required to carry it out.

Let me clarify the top-level roles for a SharePoint implementation again. There are two sides: client and project. The client side is represented by the client (aha!), typically by someone acting as the technical authority representing the client’s technical infrastructure. This person is usually the service delivery manager or a technical lead responsible for all of the other technical leads who will interface with the technical teams within the SharePoint project team. The project side is represented by the project manager and a SharePoint architect. When bringing in a SharePoint architect, it is important that this person, who also embraces the Design Authority role on SharePoint 2010, shall be made by the project manager in conjunction with the technical authority appointed by the client. By doing this, it further ensures that the technical authority’s vision of SharePoint 2010 can be realized.

Why?

Because the SharePoint 2010 architect is there to ensure the SharePoint 2010s feature set is mapped to the infrastructure of the business.

Other Authorities Required within the Project Organization

For SharePoint 2010 implementation projects requiring large teams or involving multidisciplinary groups, the project manager should prepare a project organization chart, linking it into the company structure. In addition to listing the project manager and the SharePoint 2010 architect, the chart should show any other authorities on the team—for example, the software development manager, quality assurance manager, configuration control authority, server build teams, user directory and messaging teams, and so on. The project organization chart can be included in either the Quality Plan or Project Plan.

As well as being a reminder of who does what when carrying out the SharePoint 2010 implementation, it serves as a record of who is responsible for what component. Here’s an example: SharePoint is installed in an organization where there is no record of who installed the product. Worse, a third-party component was installed through a subcontractor and there appears to be no record of this.

This example simply shows there will be significant issues going forward concerning the support and management of the platform if there is no one accountable and there is no documentation detailing how SharePoint was installed. A project organization chart shows the authorities for the project, including all those who are responsible for a relevant section of the project. All parts of the organization chart need to show what area of the project is covered and who is covering it.

A Review Must Be Held Before Acceptance

Prior to starting the project into the Design Phase, a review of the Quality Plan, Project Plan, Risk Management and Configuration Plan needs to be carried out by the project manager, client and technical authority. This is the last opportunity the company has to reassess whether the project can fulfill the requirements of the contract for the stated price.

Incredibly, this critical aspect of implementing SharePoint 2010 is the least looked at.

Reviewing the Quality, Project, Risk Management and Configuration Plans is done to ensure that there are no major unforeseen changes between the agreed-upon delivery and the contract.. For example, a statement of requirement of SharePoint 2010 at the bidding process may have changed again at SharePoint 2010 Quality Plan delivery. As with all SharePoint 2010 implementation reviews, all are organized by the project manager who involves the representatives of the team(s) relevant to tasks prior to the review. As the implementation project gets underway, reviews should be carried out on a regular basis throughout the plan and build phases of the project. I’ve found it best to go for a weekly review, on the last working day of the week, just before everyone goes out for a drink or for an end-of-the-working-week get-together. This is to gather updated news concerning the progress of the project, including any issues reported by the team, client, or stakeholders. These meetings should be marked on the Project Plan, and none should be canceled. If you do miss any, the timeframe for the project might increase because issues in reviews have not been resolved or communication throughout the project team will not be efficient.

Prepare the Plans During the Startup Phase

The Startup Phase of a SharePoint 2010 implementation project is defined as the period from the acceptance of the contract through to the establishment of the major project plans.

The SharePoint 2010 Project Plan and the SharePoint 2010 Quality Plan are two key documents that must be prepared before any detailed investigations of client and user requirements can occur.

The SharePoint 2010 Project Plan Is Used to Monitor Progress and Control All Resources

The SharePoint 2010 Project Plan defines the what, why, where, and when on a project. It should address or reference the following topics in one document:

• Section 1 — Project Overview
  
• Section 2 — Milestones/Deliverables
  
• Section 3 — External Dependencies
  
• Section 4 — Assumptions/Restrictions
  
• Section 5 — Work Breakdown Structure
  
• Section 6 — Program Schedule
  
• Section 7 — Resource Requirement
  
• Section 8 — Project Reporting

At a minimum, the SharePoint 2010 Project Plan should consist of a Gantt chart indicating the Work Breakdown Structure (WBS), project schedule, and resource requirements.

Note
Use a Gantt chart to plan how long a project should take. A Gantt chart lays out the order in which the tasks need to be carried out. Gantt charts shows dependencies between tasks and let you see immediately what should have been achieved at any point in time. A Gantt chart lets you see how remedial action can bring the project back on course. For representing deadlines and other significant events, it is very useful to include this feature on a Gantt chart. Microsoft Project 2010 includes this capability. More information about that product and Gantt charts can be found at http://www.microsoft...ips-tricks.aspx. SharePoint 2010 also includes Gantt chart views on any SharePoint repository that includes a start and end date.

Throughout the project, the Project Plan should be used as a key document to monitor progress toward delivering the requirements.

Tasks Must Be Planned to Meet the Delivery Schedule

The SharePoint 2010 project needs to have a Work Breakdown Structure (WBS), dividing the work into constituent tasks that are appropriate to the nature, size, and complexity of the activities involved

Note
A complex project is made manageable by first breaking it down into individual components in a hierarchical structure, known as the Work Breakdown Structure (WBS). Such a structure defines tasks that can be completed independently of other tasks, facilitating resource allocation, assignment of responsibilities, and measurement and control of the project. In a SharePoint project, you might have a set of tasks relevant to installing SharePoint—for example, obtain hardware, define prerequisites, install software, configure software, create site collections, define security, and so on.

An initial WBS should be created during the initial phases of the project and is fundamental to the planning exercise. It provides the basis for the control of resource and, budgets and the recognition of milestone achievements.

Once the contract or task has been authorized, the WBS might need to be enhanced to provide greater detail of the task structure. The WBS must reflect sufficient detail to show clearly the activities necessary to achieve each deliverable. Major tasks within the WBS must have clearly identified milestones that allow the progress of the project to be monitored.

The WBS referencing system should link into whatever numbering system used by the client. From the WBS, a project schedule should be generated, which will consist of a Gantt chart. (Gantt charts are described in the previous section.)
All projects should use Microsoft Project (the recommended version is Project 2010) to generate and maintain the schedule. Additionally, a SharePoint 2010 site should be created as a central project management office for the SharePoint implementation project.

Note
Project Standard 2010 can only save files to SharePoint—all the other functionality requires Project Professional 2010. See http://download.micr...son_desktop.pdf for more information.

If you do not have Project 2010, you can use SharePoint to define a basic project schedule using the Gantt View option.

One more point: In my experience in implementing SharePoint, I have always had already defined an external SharePoint instance running my SharePoint implementation explicitly for the project. Then later, as the Plan and Build phases come in, shift that into a SharePoint One-Stop Shop so that all those who need access to the data can get to it. Note. To provide a basis of education and learning to users concerning SharePoint your implementation of the new platform needs to include a central point where users can go to concerning SharePoint. This is called a SharePoint One Stop Shop. In time, as the business grows with SharePoint and Power Users emerge roles could be expanded so the business takes more control of the One Stop Shop and therefore is even closer to managing SharePoint users. For more information concerning the SharePoint One Stop Shop, please read Chapter 13, “Planning and Implementing the SharePoint One Stop Shop.”

Discuss with the technical authority the options for having a SharePoint instance for the project team in the early stages. This is a good way to go because you have the ability to showcase the project to the client, and later on you can provide it as a historical audit of the project within a SharePoint site when the production version is available and your SharePoint One-Stop Shop is available.

Management of Resources Is the Key to Success

The project manager is responsible for obtaining and monitoring the resources necessary to undertake work. Resource planning should be undertaken in parallel with the preparation of the WBS. Resource levels can then be monitored against requirements throughout the life of the project. In the event of changes to requirements, these should be re-estimated to ensure the work can be completed within the agreed-upon deadlines.

If there is either a deficiency or excess in available resources, the project manager needs to notify the client.

One role of the client is to resolve resource issues across project boundaries (with the aid of its technical authority). With SharePoint, because many teams are involved with the project team, you might need a method of monitoring and controlling these resources. One method is the consolidated “Contract in Progress” form.
Resources shall be formally tasked, by means of written instructions, against authorized plans and budgets relating to the WBS. Examples of acceptable tasking documents are as follows:

• Work Instruction Form (recommended)
  
• Expansion in number of members of the team’s TOR
  
• Memo
  
• A record in the Project Plan
  
• Observation reports
  
• Entry in a day book for tasks of less than five days in duration