Planning SharePoint Solution Delivery

In this chapter:

Microsoft SharePoint 2013 provides an incredible number of benefits that can empower business users, enabling them to collaborate; tag, rate, and publish content; and track tasks. Even with all this technical capability, none of it will be meaningful to users unless there are plans set to design, implement, and communicate training to users. SharePoint solution delivery is a combination of providing the solution to meet user requirements, and then ensuring that users can adopt those solutions. This chapter covers the basics of planning solution delivery through plan formation, managing outputs, and engaging sponsors and stakeholders.

Providing a SharePoint solution is not something that can be achieved by one person. You will need to build a solution delivery team to design and implement the solution. The structure of the delivery team very much depends on the solution scope, the solution’s complexity (technical implementation and business User Adoption), and how the solution fits into the SharePoint environment (including the support and maintenance of that solution going forward). The kind of human resources required for implementing the solution to an on-premises SharePoint environment will be different from off-premises SharePoint. SharePoint Online, through Microsoft Office 365 off-premises solutions, is implemented in a Software as a Solution (SaaS) environment. This represents a shift from traditional on-premises software solutions.

With SharePoint on-premises, solution implementations usually involve internal technical staff being involved because they govern the internal SharePoint platform under which the solution would operate. There would be technical and security-related policies concerning how any solution is deployed. This also relates even to SharePoint off-premises environments that are Platform as a Service (PAAS), where the environment is available in the cloud but still managed by a SharePoint team.

Delivery of SharePoint to an organization is based on meeting the organization’s information and collaborative challenges. Here are several actions that will be requested:

• Creation of a SharePoint Farm

• Creation of a Web Service

• Implementation of an off-the-shelf app (including customization)

• Implementation of an off-the-shelf app (not including customization)

• Implementation of an SharePoint built-in app

• Implementation of a third-party tool (to provide extra functionality to SharePoint)

No single person can deliver any of these solutions. Implementation of SharePoint is not simply a technical installation—it requires business and technical teams to work together. Therefore, a team that offers various types of people skills will be required to help implement and support the solution. Chapter 7, “Organizing the Delivery Team,” describes the roles required to deliver a SharePoint solution delivery program. In Chapter 8, “Building a SharePoint service delivery model,” the “Build in support to aid service delivery” section provides more information on the roles required to support the solution.

Therefore, to analyze, design, build, test, and deliver a SharePoint delivery program, you will need to put together a SharePoint delivery team. Let’s now examine in greater detail how to do this.

Setting up a SharePoint delivery team

As previously stated, SharePoint solutions are limited only by the imagination of their creators. They can be designed and implemented using SharePoint on-premises or off-premises. However, the construction of the delivery teams differs depending on the desired result. Regardless of the kind of solution implemented, there are support requirements to consider, which then increase the team size required (because this may include internal teams, external teams, or both). Consider using external providers who can help build your SharePoint delivery team. Table 3-1 describes the types of providers and their offerings.

Table 3-1 Types of services to deliver and support SharePoint solutions

Organizations may simply want guidance or perspectives concerning SharePoint or best practices and may be looking for consulting services as well. Others may want to apply a consultant’s expertise to specific objectives, and that is where consulting blends into professional services. Extending the train of thought even further, where the organization wants very limited involvement and is looking for a vendor to own and provide the full service, managed or outsourcing services typically are engaged.

The reason that these concepts are important lies in the way that they relate to the proximity of the solution to the organization. If, for example, the organization is just procuring an off-the-shelf solution, for example, then they typically would need basic support and training services. On the other hand, if an Office 365 environment is being provided as a managed service, the organization would ask the vendor to manage the entire environment from a support perspective and have very little involvement with the product itself.

The size and complexity of the solution being delivered will also identity the size and skill sets required to deliver the solution. A solution could be as simple as implementing a Microsoft Access packaged app solution from the Office Store, or as complex as delivering customized apps or full-blown SharePoint environments.

There are three types of SharePoint solution delivery teams:

• Short-term This kind of delivery team is established only for the duration of the delivery. This could be a consulting service, or members of an existing SharePoint team (where the solution delivery is non-complex).

• Cross-functional This kind of delivery team provides necessary skill mixes. For example, in the delivery of an on-premises SharePoint farm, resources may be required from other parts of the organization, which are responsible for support parts of the technical infrastructure. Examples of this include Microsoft SQL Server teams, network teams, and platform-building teams. Also, you should consider that in most deliveries, individuals are required to represent the business to provide guidance on user requirements; they are also part of the delivery team because they provide skills relevant to understanding and defining business requirements. Most delivery teams for SharePoint are cross-functional.

• Frequently part-time This kind of delivery includes members who are fulfilling line and delivery tasks.

Bearing this in mind, it is essential that from the very start you fill the key delivery roles (business sponsor, and delivery manager). See Figure 3-1 for an example of hierarchy of roles.

Many of the team members are likely to be part-time or have other daily duties to attend to, so get their line manager to agree what their commitment is and how changes to that commitment should be handled. The line managers may wish to, or be asked to, undertake a quality assurance role (as described in the “Adding quality to your delivered SharePoint solution” section in Chapter 2, “Defining the SharePoint solution scope”). If so, this must be agreed upon.

For each team member, you should write a Terms of Reference agreement describing the responsibilities of the role and ensure that each team member signs it. Once this is done, summarize those roles in the SharePoint solution’s business case.

FIGURE 3-1 A typical SharePoint delivery team’s roles and hierarchy.

When a SharePoint team is working well together, they have complementary skills and are committed to delivering a SharePoint quality solution and user experience. You should aim to build a delivery team that has an environment of openness and trust because this creates a solid communication base. Doing this right when you set up the delivery program is ideal. Even if you are clear on what needs to be done, you should allow some time for the team to understand and contribute, because that will lead to greater commitment and better results. You do not want a delivery team starting as in the following scenario:

Scenario 1: Fabrikam uses On-Premise SharePoint for basic collaborative services. Its HR department had a request to enhance the People directory, housed in a third-party system. The department wanted to use SharePoint social features and decided to use the skills and tagging features, as well as the SharePoint profile builder. For this to happen, the third-party system would need to be integrated into SharePoint. A delivery manager was selected to deliver the enhanced People directory in SharePoint through integrating the third-party system. The delivery manager, who had a good understanding of the existing directory, drew up a plan of action. However, in that plan, he did not check with the HR team. His reasoning was that the implementation would be faster using a consultancy. The delivery manager assumed that the consultancy would know intuitively what had to be done, and he stated that he did not want “too many long, drawn-out discussions and workshops.” The delivery manager requested that the consultancy start building prototypes for a new People directory to replace the third-party system. Unfortunately, when the consultancy staff met with HR to demonstrate one of the prototypes, they faced a hostile reception, which resulted in backtracking and chaos. There were many angry exchanges, and the delivery manager was blamed for inadequately communicating his intentions to HR. He was also blamed for the failure to construct the delivery team and not keeping all parties informed concerning the delivery plan. Finally, Fabrikam executives intervened and replaced the manager with another individual from the same department, who better understood the business requirements. Replacing this manager cost time and money, including him needing to work hard to rebuild confidence and trust with the HR department.

SharePoint solution building can be highly charged and fast paced in the beginning, and eventually, it will become part of the organization’s standard operations. The delivery team will form and then form again as more SharePoint solutions join the environment. Choosing the right people for your delivery team is a vital element of an evolving SharePoint environment, and those people need to be willing to be part of the team. That said, willingness to participate in a SharePoint delivery team does not guarantee SharePoint solution implementation success; ability to function within the team is also vital. When people are thrown into a SharePoint delivery program, those without experience will flounder and will need assistance. Plan the team according to how focused each person is, and ensure that managers also focus on promoting good SharePoint knowledge building of their team members. This creates strong delivery successes, and creates SharePoint champions, who then can further promote and showcase their skills and creations.