Planning SharePoint Solution Delivery

Engaging your sponsor and stakeholders

As already mentioned in previous chapters, stakeholders are those affected by the delivery program. A SharePoint sponsor is a manager or executive who acts as a visionary. He or she is advised by the delivery manager of the SharePoint delivery program and can articulate how the SharePoint can meet the solution requirements. Both are stakeholders, as they are both on the delivery team. However, there are also people who take no direct part in the delivery program as team members, but whose activities will be changed in some way as a result.

When releasing SharePoint as a solution, where the implementation of the platform into an organization is required, the number of individuals affected could be significant. Therefore, you must identify stakeholders and their power (that is, are they decision makers, influencers, or require consent?), so that they can be enrolled in the delivery program at an early stage. This is done to ensure that stakeholder power does not cause the delivery to fail later. You should always have a backup plan in case your stakeholders use their power to undermine your delivery plans.

Scenario 3: Fabrikam is implementing a SharePoint solution that is a system to automate its sales process by automatically emailing documents marked as Sales. Following an investigation, the suggested procedure is to provide an extra option in all document libraries that is a component of the SharePoint solution. The functionality will be implemented as a new button in a SharePoint document library. Heading the delivery team is a SharePoint-savvy business manager who believes in a top-down approach and wields significant power in determining the shape of the solution. Believing that the only users are from the Sales department, he communicates with that department directly. Some weeks later, the solution is deployed across the entire company and into all SharePoint document libraries and all sites. Calls come streaming into the IT help desk from confused and dissatisfied users. The callers are asking questions like, “What is this button in my library?” “Why were we not informed about all this?” “How do I use this new doohickey?” and “My library is much slower—is it because of this new button?” As a result, the solution is removed, pending further investigation. The solution has yet to be implemented because the time frame to deploy the solution has passed, and the business has moved on to other challenges.

This scenario describes a typical problem when you implement a solution without taking stakeholder power and identification into account. If stakeholders are not involved in the development of the solution, the outcome can be disastrous, resulting in wasted effort, time, and money.

The delivery manager and the SharePoint sponsor must ensure that all stakeholders are adequately briefed on the solution being implemented. Care must be taken concerning the level of communication provided. Too much data will drown them, but not enough will mean that users will not give the delivery the level of priority that the delivery program team wants.

Enrolling stakeholders, and keeping them engaged, are taxing but essential tasks. You accomplish them by both a formal communication plan and by “enrolling behavior” on behalf of all the delivery team on a planned and opportunistic basis.

Stakeholders make up a vital part of the User Adoption process. By encouraging stakeholders to become “SharePoint champions,” they become warriors on behalf of the cause, helping users come to grips with new SharePoint solutions and, in turn, helping SharePoint evolve. They also are critical to the creation of policies related to platform Governance of solutions that have been implemented going forward.

Stakeholders need to be identified as part of the initial investigation into building the business case. There are three kinds of stakeholders:

• Those who have a positive attitude toward the delivery program

• Those who have a negative attitude toward the delivery program

• Those who are not committed one way or the other

For each stakeholder or group of stakeholders, consider the following questions:

• Do they play a decision-making role in the delivery program?

• Can they exert influence (positive or negative)?

• Is their consent required for the delivery program to succeed?

Now consider the following scenario:

Scenario 4: Fabrikam needs to implement a SharePoint solution that will affect the entire organization. The SharePoint sponsor says that contact should be made with the customer director, who manages a team responsible for the areas of the company most affected by the new solution. His consent will be required to gain access to his team members. The team members are potential users of the new SharePoint solution. The chief executive has informed the SharePoint sponsor that two additional people, Phil and Jim, could be used to influence the customer director’s consent and act as SharePoint champions. After further investigation, the delivery manager discovers that Phil works with the customer director, Jim is a key member of the engineering team under the engineering director, and that a significant number of potential stakeholders are involved. Therefore, the delivery manager and SharePoint sponsor create a Stakeholder influence map, which is updated some more after discussions with each of the potential stakeholders.

The diagram in Figure 3-7 shows the connections between the identified stakeholders and identifies who is a decision maker, an influencer, someone whose consent is required, or those who must be targeted for User Adoption planning. The plus and minus signs, zeroes, and exclamation points shown with each stakeholder indicate whether that person is positive, negative, or noncommittal, or whose attitude is unknown. In Figure 3-7, which shows an example SharePoint delivery stakeholder map, Phil is indicated as a “feed” to the customer director, and Jim is indicated as a “feed” to the engineering employees.

You should consider a stakeholder map a useful way to help build an initial business case; the map adds clarity to stakeholder communication, attitudes, and approval levels. However, stakeholders are not identified only so you can find out whether they will consent to or are positive about the delivery. Consider that point when engaging with stakeholders: either you will require information from them or they need to be influenced with respect to the delivery of the solution, and they might need a demonstration of how SharePoint would solve their information and management challenges.

Based on the type of communication that the stakeholders require, choose wisely the medium, timing, and the kind of consent required. Also, ensure that all stakeholder information is recorded in the plan, and tied to the relevant milestones concerning the release of the SharePoint solution.

In the “Building the SharePoint delivery plan” section earlier in this chapter, I suggested a method of using SharePoint to record and manage the delivery plan for the solution which was to construct a site whose sole purpose was to manage and communicate the delivery of the solution and progress. If you have such a site, consider providing the stakeholders with access to it. This will give team collaboration a major boost because that is where anything to do with the delivery program is located, including all reports and decision-making documentation.

Because SharePoint solution delivery is scheduled into segments (see the “Preparing a SharePoint delivery program” section earlier in this chapter), consider assigning decision-making stakeholders to the sign-off of the relevant gate at the end of each stage. As stated earlier, consent of stakeholders is not the only thing required—you also need to get their approval of a solution that will meet their (and their relevant users’) needs.

Figure 3-7 An example of a SharePoint delivery stakeholder map.