Planning SharePoint Solution Delivery

Defining controls to manage SharePoint solution delivery

As the SharePoint solution delivery program is being designed, build in controls that manage communication and authorization. Without mechanisms to ensure that there are reviews, reporting, authorization for changes, and managing documentation, there will be miscommunication and misalignment with goals. The result in many cases would be that the solution program gets dropped or withheld indefinitely, or it runs into a cycle of noncompletion (because the scope has not been reviewed and then confirmed, for example).

Therefore, once the delivery program has been defined and a schedule set, you must ensure that other organizational aspects of the program are addressed. These areas should be detailed in the SharePoint business case, as discussed next.

Ascertaining progress reporting needs

You must periodically update the sponsor (and members of the delivery team, as necessary) on the progress of the SharePoint solution implementation. To do this, you should first agree with the sponsor how reporting should be performed and the mechanisms used to do so. For example, you could use the delivery schedule in SharePoint to send out email notifications when a particular task is completed. There are other methods of progress reporting as well. You could summarize progress on a page on the SharePoint site and have that available for viewing, or provide a report based on a template that is provided from a Reports document library. For the purpose of standardization, choose one method of progress reporting. The key is to attempt to centralize reporting and to make things as easy as possible for those who need to access the progress reports. The last thing you need is the sponsor not reading the progress reports or assuming things about the delivery, which could well happen if progress reporting has not been defined or agreed upon. Once agreement has been reached, record the reporting requirements in the Outline Plan.

As delivery manager, you are responsible for controlling the delivery and taking the necessary actions to ensure that the solution is delivered to the expected outputs (that is, the business requirements). This means guiding and coordinating team tasks. You should make sure that the delivery team meets regularly to check the progress of the relevant tasks and to forecast other tasks to be performed in the future. You should also assess the issues that arise and mitigate any risks of tasks not completing on schedule. In my experience, the best way to assess issues and collate progress reports quickly is to request a brief progress or checkpoint report from each of the team members. You can gather this detail by recording the details in a SharePoint task list, which can then be linked back to the Deliverables app (previously shown in Figure 3-3).

By using the SharePoint tasks list, reporting progress can be captured for each task (see the Task list app example in Figure 3-4). That could then be used to add detail to a weekly report. Alternatives to this approach include creating a SharePoint custom list that holds the reports. Figure 3-6 shows an example where the SharePoint Task list app has been connected to the Deliverables app so that further detail of a high-level task can be captured, and progress of the related task recorded.

Identifying who can authorize changes

Typically, the only individual who can make changes to a solution delivery program is the SharePoint sponsor. However, the SharePoint sponsor could choose another individual close to the delivery program to authorize changes on his or her behalf. You must ensure that the details of how to contact those who can authorize changes is recorded. When changes come—and they will—make sure that they are critically reviewed to ensure that they do not affect the delivery scope. Whether there is a change in scope or not, there may be further ripple effects down the line; alterations may require further review to ascertain any risks, issues, and dependencies. For example, if the task is to build a SharePoint site that houses a customized app, and then it is expanded to include building another app, this change needs to be scheduled and resourced, and any issues concerning support, maintenance, and training need to be considered as well. Therefore, reviewing each change and seeking approval for it is vital. The impact of getting a solution delivery wrong due to lack of getting approval or failing to record the reasons why the approval was required could lead to User Adoption issues, both during and after delivery.

Keeping the stakeholders informed

Good communication leads to User Adoption, as does keeping the users informed and enthusiastic about the implementation of a SharePoint solution. There will invariably be changes concerning the SharePoint solution as it is being designed, built, and implemented. Changes in requirements can be rapid and unpredictable—even the organization can change focus and priorities, which can affect the progress (or even the need) for a project. You should have regular points of review to ensure that what is being provided continually meets user requirements. The reviews need to be formal since they involve making and recording decisions. These reviews should be built into the delivery schedule, and those attending should include both delivery team members who are accountable for the relevant tasks leading up to the review and the stakeholders.

Figure 3-6 An example of a Task List app connected to the Deliverables app in SharePoint.

Documenting your SharePoint implementation

There will be a lot of documentation as you work on your SharePoint solution. You will need to centralize all of it because each SharePoint solution is a historical (and auditable) event in the evolution of the software’s use in the organization. Creating a structured method of recording the schedule, maintaining tasks, and monitoring progress, costs, issues, and risks (and in fact, any communication concerning the delivery of a SharePoint solution) is vital. For example, if a change is required to a solution one year after it has been implemented, then having the original documentation of the implementation of that solution is crucial. Do not simply rely on placing a copy of the solution into an inventory as a record of implementation. SharePoint gets updated, sites receive new content and design, technology evolves, and business requirements change. That means you have to know not only what solutions have been deployed, but also how those solutions where implemented and who was involved in doing that. As previously mentioned in this chapter, consider creating a SharePoint site as a delivery program site to store and manage everything.

There will be a lot of documentation as you work on your SharePoint solution. You will need to centralize all of it because each SharePoint solution is a historical (and auditable) event in the evolution of the software’s use in the organization. Creating a structured method of recording the schedule, maintaining tasks, and monitoring progress, costs, issues, and risks (and in fact, any communication concerning the delivery of a SharePoint solution) is vital. For example, if a change is required to a solution one year after it has been implemented, then having the original documentation concerning the implementation of that solution is crucial. Do not simply rely on placing a copy of the solution in an inventory as a record of implementation. SharePoint gets updated, sites receive new content and design, technology evolves, and business requirements change. That means that you have to know not only what solutions have been deployed, but also how those solutions were implemented and who was involved in doing that. As previously mentioned in this chapter, consider creating a SharePoint site as a delivery program site to store and manage everything.

Here is a case in point from a SharePoint consultant:

• I worked with a financial corporation in America that had many employees and documentation for over 1,000 apps housed in the World Trade Center when it was destroyed on 9/11. They lost all their people and all that documentation on that one day. It cost them millions of dollars to migrate the apps to SharePoint because they had not originally stored configuration records about the apps.

• —Bill Pitts, director, Portals and Collaboration, Salient6, Inc.

Establishing controls for SharePoint solution delivery

The path to implementing a SharePoint solution successfully is based on the structure and management of the controls applied to delivering that solution. All too often, SharePoint solution delivery programs fail because no control was established from the very beginning. If no control is assigned to the program, then any policies oriented to the solution after its implementation will fail. You can use the checklist in Table 3-3 to ensure that the solutions delivery plan has controls in place.

Table 3-3 Controls checklist for SharePoint solution delivery