The SharePoint 2010 Project “Mantra”

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 2

What Is the SharePoint 2010 Project “Mantra”?

Suppose you have been chosen as the project manager of the Let Us Integrate SharePoint 2010 Into Company XYZ project. The first question you need to answer is, “Why use SharePoint 2010?” There could be many reasons:

• The organization (or the client) has islands of information and applications.
  
• The organization has demonstrated slow responsiveness to business and user needs.
  
• The client is suffering from the effects of custom development and maintenance.
  
• There is currently poor information sharing inside and outside the organization.
  
• The client is having difficulty finding the right content, data, and people.
  
• There is increasing information management risk within the organization.

As a project manager, your task is to deliver your project on time and at the lowest possible cost. To do that requires combining the resources of both the business side of the organization and its technology department. Business resources are members of the organization who will provide details concerning the client vision; the information they provide is crucial to the format of SharePoint 2010. For example, they will determine how sites look, what the taxonomy is, and what metadata is associated with content. Technical resources refers to the equipment required: hardware (servers under which SharePoint 2010 operates and that it communicates with) and software (SharePoint 2010, Office 2010, and associated components and technologies), including third-party products. There will be business challenges, such as those brought about by changes in organizational structure, by the clients’ vision, and by the clients’ processes. There will be external challenges too—for example, those brought about by legal and economic issues.

Whatever these challenges, your SharePoint 2010 project mantra is critical. The project mantra shows how the project will evolve and align with your client’s aspirations. It shows your enthusiasm about SharePoint 2010; your stakeholder group will likely feed off of that enthusiasm.

A key part of making the mantra meaningful is adopting an evangelistic and realistic approach to implementing SharePoint 2010. Therefore, as project manager, you don’t just need the typical organizational and scheduling skills (say, from a methodology such as Prince). You need to have an enthusiastic approach and appear to your peers and colleagues as having high-level skills in defining a collaborative environment that’s responsive to change. This doesn’t mean you need to have already implemented dozens of SharePoint 2010 projects and features. It means that you follow a specific method and that your SharePoint 2010 Quality Plan reflects that method.

The SharePoint 2010 Quality Plan is discussed in detail in Chapter 3, “Content of Your SharePoint 2010 Project Plan.” To get the details required in the SharePoint 2010 Quality Plan, you need to address some important areas: your knowledge of the product, an understanding of the client’s vision for SharePoint 2010, and the scope defining the client’s requirements.

Your SharePoint 2010 project mantra helps you to easily describe the key features that SharePoint 2010 has and how they meet the full range of needs of employees, partners, and customers, individuals, and teams. The features provided, for example, might include MySites, team collaboration, department sites, enterprise intranet, and Internet presence, all aligned with an enterprise search facility.

The client should be left with no doubt that SharePoint 2010 will make information and knowledge sharing intuitive and easy. SharePoint 2010 includes smart live editing of text on the page; it has content controls, Visio Web integration, browser support, and the Office Ribbon. In short, it includes features that enable the client to control and reuse content while reducing information-management risk, which leads to faster and more insightful decision making.

The SharePoint 2010 project mantra involves understanding your client’s SharePoint 2010 vision, understanding the product, and delivering the product in the most useful way for the client.

Your First Steps

You cannot easily implement SharePoint 2010 yourself because you will find (from reading this book for a start) that this requires you to carry out many pieces of work as well as control the time frame and the client. You need a team to help you, and that team needs to be defined based on the scope the client has indicated.

The team ethos will ensure that the project focuses on defining, developing, and deploying SharePoint 2010 based on the client’s requirements. (This is discussed further in Chapter 5, “Building Your SharePoint Team.”) To build your team, you need to have an understanding of planning and controlling a SharePoint 2010 project as well as an understanding of the client’s organization.

By gaining this understanding, you are preparing both yourself and the client. Preparing yourself allows you to carry out investigations and build your team. Preparing the client allows you to understand their knowledge so that you both can define your collective expectations of SharePoint 2010.

For example, you need to determine whether your client has used SharePoint 2010 in the past or whether they are currently using SharePoint 2010. The answer to this question is critical because it will give the Project/Program Manager an immediate indication of the top-level project scope; therefore, the answer to this key question and related questions must be gathered at your first meeting with the client.

During this initial meeting, you will also need to find out whether or not the client has gone through SharePoint 2010 implementation pain. You must come to understand the client’s experience of this pain because it influences how the users will view the platform going forward.

SharePoint 2010 implementation pain occurs when the relevant SharePoint 2010 plan did not succeed or issues came about seriously disrupting the SharePoint implementation, causing business disruption, financial loss, bad publicity, or any other consequences the client did not expect or desire. This pain could be caused by one or more of the following factors:

• The budget did not match the scope.
  
• The project scope could not be achieved.
  
• The project ran out of time.
  
• The project team ran away. (I’ve seen that happen!)
  
• The education of the users, team, or both did not succeed.

The users missed the meaning of SharePoint 2010 – the implementors failed to sufficiently educate the users and did not explain a definition of SharePoint (for example not even explaining to the users ‘SharePoint is a collaborative technology that allows users to create and manage their own web sites’.

By getting the client to divulge the details of these pain points, you can itemize them and provide initial responses to the client to ensure the issues will be addressed or avoided in future projects. Additionally, the client might even indicate what they have done to prevent the problem from affecting them further—for example:

Company XYZ implemented SharePoint but did not manage to implement a requested feature because the project team ran out of time. The SharePoint project was then handed over to the business resources. The knowledge of the missing feature is detailed and known. However, the client is unable to use SharePoint to solve productivity issues because the feature is not available. This was the client’s implementation pain. To prevent the client from experiencing this pain again, there was agreement to rigorously check the scope of all future SharePoint implementation projects and to provide alternatives or agree on a different method of working if user requirements cannot be met.

By meeting the client and gathering information so that you understand the current implementation level of SharePoint 2010 in the organization, you understand its basic usage within the organization and more. You have your first boost of SharePoint 2010 project mantra and you can make your first attempt to help the client create their vision of SharePoint 2010.

NOTE
Your SharePoint Project Mantra increases in accordance with the knowledge you have gained of what the client wants (their vision). Additionally, as the clients understanding of SharePoint grows in terms of how SharePoint will benefit their organization, the SharePoint Project Mantra increases.

The SharePoint project mantra ensures that the team doing the tasks is highly motivated, and wants what you want, as the project manager, to succeed and to exceed expectations.

Know Your SharePoint 2010 Features

You need to have a grasp of what features are available in SharePoint 2010. This knowledge will help you focus the user requirements and find solutions to the organization’s information and management collaboration challenges.

There is a mass of information available from Microsoft concerning the product scope for SharePoint 2010 (describing what SharePoint is). There is also a massive amount of support for the product from Microsoft, including information provided from articles written by SharePoint 2010 experts in the field.

During the initial phases of your SharePoint 2010 implementation project, you will elicit information concerning what the user requirements are. These requirements then need to be mapped to key features so that detailed work concerning the configuration and deployment of those features can be pursued. The information gathered from the business analysis with the user base is used to drive the system specification, which is made up of the relevant features needed.

SharePoint 2010 has significant improvements over SharePoint 2007; however, I want to be clear—this book is not going to give you a list of these improvements. Neither is it going to detail how you should install those features. It will provide a list of SharePoint features so that you know what is available to meet a client’s requirements.

Engage the Right People

There are two types of client personnel you need to engage for performing the implementation of SharePoint 2010: business and technical. These are the key stakeholders and decision makers. The business client provides the vision. The technical client provides the infrastructure. They both have requirements. This is the same for nearly all product installations—they require technical and business input.
Later, you will discover that you need more than one person to implement SharePoint 2010 properly. To assist you, you need someone who deeply understands SharePoint 2010, and you need someone who can quickly come to grips with and understand the organization as well as translate business requirements into technical requirements.

The technical client (also known as the technical authority) will be interested in the infrastructure side of SharePoint 2010, including the following topics:

• How responsive is the product?
  
• How is it going to reduce installation issues and make it easier to train the support team?
  
• How is it going to reduce the cost in the mid-term? For example, will more servers be needed as the requirement gets bigger AND how much does the software cost?

The business client will be interested in whether SharePoint 2010 will solve productivity, information, and management challenges concerning collaboration and sharing data. The issues this person will likely want to examine are the following:

• Can the users come to grips with SharePoint? Can they build their own sites and then work and distribute their content easily?
  
• Can the users learn the product quickly and re-apply things they know from using the current tools in a SharePoint 2010 environment?
  
• Is SharePoint 2010 easy to use?
  
• Is SharePoint going to help automate work processes?
  
• Is SharePoint going to secure content?
  
• How do you control SharePoint 2010 (or at least be advised how to control it)?

As detailed in the “Your First Steps” section, your initial meetings with these two clients will help you understand the nature of their environment and, at the same time, get a feeling for their requirements.

Ask the Right Questions

In asking the right questions concerning what the client wants for the SharePoint 2010 implementation, you are setting the scope for the top-level part of project, refining the project plan, recording key user requirements, and scoping the infrastructure.

The kind of questions you ask are based on the client’s organizational objectives, the content they carry, the applications they use, and how searching for content is carried out. You also need to look at how content is formatted and how information is structured.