Planning SharePoint Solution Delivery

  • 6/15/2013

Building the SharePoint delivery plan

A core aspect of the SharePoint delivery program is planning. Planning describes the work required to implement the SharePoint solution. You should prepare two sets of plans. The first is the Detail Plan, which includes the delivery schedule. The delivery schedule is a progress bar chart used by the delivery manager and team members to control their day-to-day work. The second plan is an Outline Plan, which is a management summary used to present the overall progress of the delivery to the SharePoint sponsor and other interested parties. This should show the stages, milestones, and other important activities needed for an overview.

The Detail Plan manages the business case and all associated documentation concerning the implementation of the SharePoint solution. It is a complete record of the delivery program, which describes the implementation of the solution, including the User Adoption planning. The Detail Plan includes four segments:

  • Envision This segment includes performing the initial investigations, creating the business case, confirming the success criteria, and stating the high-level milestones for progress reporting.

  • Plan This segment includes creating the team, building technical and user (business) requirements, confirming the design of the solution, and determining a User Adoption strategy (communications and training).

  • User Adoption This segment includes the provision of communications, training, and education. It also includes the testing and validation tasks carried out by the users.

  • Build This segment includes the tasks necessary to build and then operate (deliver and provide service for) the solution.

There is another segment, Closure, which relates to the official completion of the delivery and is validated by the success criteria detailed in the Envision segment. This segment is discussed in more detail in Chapter 11, “Managing workshops and closing the delivery program.”

Figure 3-2 shows the format of the SharePoint delivery Detail Plan, including some high-level tasks. The dotted arrow lines show how the segments are connected. As stated, a key aspect of the Detail Plan is the delivery schedule, which lists the work required to implement the solution and when it must be completed. You should lay out the Detail Plan and work closely with the needed delivery team members (including the sponsor and stakeholders) to map the relevant tasks to the solution and record them in a Gantt chart. Ensure that each task is assigned to one or more team members. The Detail Plan forms the basis for progress reporting and gets recorded in the Outline Plan.

Figure 3-2

Figure 3-2 Format of a SharePoint Delivery Detail Plan.

You should ensure that there is a place to centralize the business case, delivery plans, and other documentation such as user requirements, issue logs, and risk logs. Use SharePoint to accomplish this. The delivery team could use a SharePoint site as a central location for all its activities; the site also acts as a showcase to sponsors and stakeholders, and of course, it also can be used to record delivery progress.

Taking this idea further, here is a scenario depicting the implementation of an app to a SharePoint site:

Scenario 2: Fabrikam wants to implement an app into its SharePoint environment. The company has enlisted a delivery manager, who has created a small team to help deliver the solution. The delivery manager wants to use a SharePoint site to contain the Detail Plan, so he would have a central place to manage high-level tasks in the delivery schedule. The SharePoint site also would be used to keep related documents and contact details for the team. The tasks stored in the site would be assigned to team members, as is any relevant documentation to be managed.

Figures 3-3 and 3-4 depict an example of how Fabrikam could have used SharePoint components to help manage the delivery program as described in Scenario 2. Figure 3-3 shows an example of a SharePoint 2013 site using the built-in Deliverables app, and it also illustrates the Detail Plan relevant to implementation of a SharePoint solution.

Figure 3-3

Figure 3-3 The Deliverables app in SharePoint.

Figure 3-4 shows the Detail Plan as a task list. Note that two extra columns have been added: an Accountability column, which shows the contact accountable to the task; and the Related Document column, which is bound to content stored in a documents library, showing the title of the document related to the task. Figure 3-5 shows the contacts list, which is bound to the task list as the Accountability column.

Figure 3-4

Figure 3-4 An example of a high-level task list from the Deliverables component in SharePoint.

Figure 3-5

Figure 3-5 A sample delivery team list has been created using the Contacts app in SharePoint.

Using SharePoint to build the delivery plan, contacts, and documents is a great way to help ensure that information is centralized. There are other benefits, too, particularly in aiding early User Adoption to business members who have access to the site and implementing solution apps for SharePoint sites. For example, the solution app could be deployed to a subsite of the delivery team’s SharePoint site and demonstrated there, and then the results could be captured to a list that can aid the business review at the closure of the delivery program.

As previously described, the solution delivery schedule is required to identify the tasks to be achieved, including information about those tasks (for example, who will be doing those tasks and the time frame in which they should be completed).

As already has been pointed out, each task in the delivery schedule must contain a set of associated information. The details of delivery plan structure are given in Table 3-2. When you’re building the delivery program schedule from the Detail Plan, perform a review of work required. Some parts of the delivery program will form Work Packages in their own right. For example, an element of the Detail Plan could be to configure Search. This could have a number of subtasks, like obtaining service accounts, defining the scopes, and identifying crawl rules.

Table 3-2 Structure of a Delivery Plan

Items to include in the Delivery Plan



Stages represent the natural high-level break points in the program life cycle. Examples include Initial Investigation, Feasibility, Development, Implementation, Operation, and Closure.

Work Packages

Work Packages represent the clusters of work within each Stage, focused on a key deliverable. For example, one Work Package could be the customization of a SharePoint app to meet user requirements. Another could be the testing of that app by selected business users (who are also part of the delivery team).


Activities are the individual components of work within the Work Packages that must be undertaken to complete the project. Each Activity should be defined in terms of its start and end dates and the name of the individual accountable for its completion.


A single, specific person should be accountable for every Activity and Work Package in the delivery program.


Milestones are significant events (often representing gates at the start of a Stage) that should be used to monitor progress as a summary.


Each of the key Deliverables defined in the program should be shown in the plan (indicated in the business case).


Include Reviews at key points throughout the program when progress and performance can be evaluated. This is particularly important for the Validation portion of the program, where the solution has been made available to the business users for testing.


All inputs from (and outputs to) other programs must be explicitly shown. This is very important for cross-related programs. For example, in the implementation of a SharePoint farm, there could be related programs of work from various work streams; there could be one centralized delivery schedule with all work streams connected to that schedule.


Using the delivery program, include Costs for materials and resources against each Work Package. At the end of each Review, outline the costs for delivering the Stage as part of the outline plan that summarizes progress.