Chapter 2 26 Chapter 2 SharePoint 2010 Project Mantra 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 con- tent 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. This is further discussed in Chapter 11, “Making Sure SharePoint 2010 Meets User Require- ments,” to help you gauge and identify SharePoint 2010 features that can solve specific challenges. How to Perform an Effective SharePoint 2010 Implementation An effective SharePoint 2010 implementation has a quality plan, a project plan, a configura- tion plan, testing, validation, and scope details. All of these elements describe to the client (both business and technical) what the SharePoint 2010 implementation is and what has been agreed and signed off on by all parties addressed in the implementation plan. The implementation plan has a number of facets, described in Chapter 3, “Content of Your SharePoint 2010 Plan.” In essence, all the relevant procedures associated with the SharePoint 2010 installation are known or adhered to. In addition, as the project manager, you need to sell SharePoint 2010, and to do that you need to do the following: • Find SharePoint 2010 case studies. • Identify the client’s Microsoft licensing model. • Engage with the client, carry out reviews of the organization, find out what the client wants to achieve with SharePoint, ascertain the technical infrastructure, find out how the client’s users collaborate, find out how users work with Web content, and find out how users search for data. This is called “gathering user requirements.” • Plan your deployment carefully. • Educate and demonstrate. This fosters client adoption. Chapter.2 Negotiate an Appropriate Scope. 27 Successful SharePoint 2010 implementations can be guaranteed to have quite a few of the following attributes: • They have a good proposal. • They start with a good work plan and assume minor changes will occur. • They are structured into smaller projects for the timeframe and ensure that the scope of the project does not blow out of proportion. • They make the SharePoint 2010 project sound like fun. • They have a resourceful SharePoint 2010 architect. • They strike a balance between planning and doing. • They have contingency plans and plan for the worst case in performing critical tasks. • The team members are clear about objectives and their terms of reference. The SharePoint 2010 implementation realizes and addresses three areas of productivity: • Organizational Productivity Addresses process automation, information access, and roles • Personal and Team Productivity Addresses user enablement, user adoption, and ease of use • Infrastructure Productivity Addresses responsiveness, reduced complexity, and cost reduction Negotiate.an.Appropriate.Scope When I say “scope” here, I am not talking about a SharePoint 2010 technical term. This book concentrates on the setting up of SharePoint 2010 from a business perspective; there- fore, don’t expect that the word “scope” is about searching scopes in the SharePoint 2010 Search Crawling feature! A SharePoint 2010 project scope can be described as follows: The work that has to be carried out in order to deliver SharePoint 2010, its services, and specified features and functions; it is the definition of what the project is to accomplish as well as the budget (time and money) that has been created to achieve the objectives. Chapter 2 28 Chapter 2 SharePoint 2010 Project Mantra A good scope needs to be clear and concise. The project name is a good place to begin. Lack of planning in SharePoint 2010 often results in a failed implementation, and that lack of planning is often due to a poorly designed project scope. An effective SharePoint 2010 project name that reads something like “Create a SharePoint 2010 environment to enhance collaborative working in Company XYZ” is much better than “SharePoint 2010 Environment Project.” More concise is not always more clear. The aim of the SharePoint 2010 project name is to document the project so that everyone is aware of what is expected during the life of the project. It also helps provide a vision of where the project is headed and is the projection of your project mantra. Here’s the scenario: you get a requirement to provide SharePoint 2010 to a company, and you have just been appointed to be the SharePoint 2010 project manager. The client has already looked at the product, but they don’t really know what they want. They are sure they want a branded My Site, an extranet, and an intranet, and they think they will want document management features from SharePoint 2010 Enterprise edition. When asked for the scope, the client states it is to “Build and deliver a SharePoint 2010 instance.” Clearly that is not a good scope. To correct this as project manager, you need to create that SharePoint 2010 project mantra and to get the client to review the scope. What is missing is the Quality Plan, which describes the how and why of the project. This is a direct output of the SharePoint 2010 project mantra. There are three critical parts to quality planning that relate directly to the work you are expected to do, and these are contained in the Quality Plan that management will sign off on. The Quality Plan defines the product scope. For example, a product scope for Share- Point 2010 to the organization would be similar to the following statement: A collaborative technology that enables people to easily create and manage their own Web sites. Note Creating an appropriate project scope ensures that the client understands what they are going to get and why they are using SharePoint 2010 to solve the myriad issues that have been stated. You should try to showcase successful SharePoint 2010 imple- mentations and review Microsoft case studies as part of the project scope. You will find many examples at http://www.microsoft.com/casestudies. Chapter.2 Deciding What Not to Do Is As Important As Deciding What to Do. 29 Deciding.What.Not.to.Do.Is.As.Important.As.Deciding. What.to.Do A famous quote regarding SharePoint 2010 is, “If you need to have something happen in SharePoint 2010, the answer is never ‘No.’ The question is, ‘Do you have money to spend if you get to a No situation?’.” Here’s an example of how this observation might play out: Company A wants to adopt a feature to enhance People Search in SharePoint so that when someone searches for an individual, the results display a small list of recent documents that person has created. The reason the company wants this particular search behavior is that it likes to have open access to documents created and to be transparent with regard to who has authored the documents. The company doesn’t have any internal developers familiar with SharePoint, and the budget is tight. However, the client is adamant about having this feature in place. This functionality isn’t available out of the box. You must do some investigating to find out how best to implement this new feature. You should start by examining the company’s technological resources to find out whether there’s a way it can be done in house—of course, that’s not possible in this case. So you need to move on to the second option: determine whether it’s possible to bring in a developer. But wait a minute. By doing this, you are already passing the point of project planning! Here’s another example. Company B has hired a SharePoint team to implement SharePoint 2010. That team has a connection to a third-party development company that will build numerous features for the product to meet a specific client requirement. While building the tool, the development company adds additional features that are not required by the client. It did this because the team wanted to prove they could do it and go beyond client expectations. Unfortunately, in doing this, they created a bigger collection of user documentation to cover the unneeded features and the additional training and sup- port requirements that go along with them. This scenario is infamously known as feature-scope creep. It means one or more features not originally contemplated by the client have been added in. The preceding scenario is a combination of two types of feature-scope creep—customer-pleasing and gold-plating— Chapter.2 30. Chapter 2 SharePoint 2010 Project Mantra because there is a desire to please or impress the customer by adding product features beyond what was requested. Avoid.Biting.Off.More.Than.You.Can.Chew The SharePoint 2010 feature set is so large that failing to carefully manage the scope can easily push you to your limits as a project manager. There are so many interesting things to do in SharePoint 2010 while working on a particular problem that it’s easy to become distracted. As well, solutions you put in place in a SharePoint 2010 implementation might require you to work in maybe three or four areas of the platform. One can easily fall into the trap of discovering lots of interesting and fun things to do. For example, suppose that as project manager you must provide the ability for informa- tion from the user directory to be available in SharePoint 2010. You think, “OK, that’s an easy one. I’ll focus on the User Profiles section of SharePoint 2010.” Be careful—there’s a lot going on in that area, more than just putting in some fancy user properties and working with user metadata. Before long, you’ll find yourself falling into the following traps: • Working extremely long hours • Running into a brick wall because some customization is required • Charging out for developers These actions add increased costs to the project and increase project timeframe. And you might be tempted to justify this to the client as exceeding the scope. But remember, that the objective of the project manager is to deliver what the client wants on time and at the lowest possible cost. You can do this by keeping the following guidelines in mind: • Pace yourself Don’t get stressed and don’t overwork. Doing that will lead to fatigue, which doesn’t make for an effective SharePoint 2010 evangelist! • If you are in trouble, renegotiate the deadline Tell the client what is going on. Ensure that they know what you need and why you need it. The client will understand. • You are not the god or goddess of your SharePoint 2010 implementation clan There are enormous areas to work with in SharePoint 2010. If you are in trou- ble, get help. Don’t attempt to sort it out yourself because that might only increase the project timeframe. Don’t gloss over an obstacle by believing that you will get to it later. If you do that, you are not even following a schedule. If you don’t delegate tasks and manage them, it will just cause you more stress! Chapter.2 Renegotiate the Scope If Necessary. 31 • Regroup This book describes procedures that ensure you schedule time to find out where you are while you are running your SharePoint 2010 project. A well-structured SharePoint 2010 has a regroup day, once per week. On this day, the project team takes a rest from implementation, and as such, you take a rest. Use this time to reas- sess the workload and adjust the schedule. Renegotiate.the.Scope.If.Necessary You might find that renegotiating the scope is required for the following reasons: • You are in trouble because you have bitten off more than you can chew (as men- tioned in the previous section). • A particular client requirement, while possible to accomplish, might require purchas- ing a third-party product or developing a feature, which would push the implemen- tation over budget. • Similar to the preceding point,acheiving a particular client requirement might not be possible within the timeframe established for the product going live. • Delivering a particular client requirement might introduce unwarranted risks into the implementation. To give you a picture of how you might end up in one of these situations, let’s look at an example that illustrates the final point in the list. Client A has requested that the SharePoint 2010 implementation include a record to show views to sites, documents, lists, and any additions or deletions made. As a SharePoint 2010 practitioner, you suggest using either the SharePoint 2010 auditing feature or the analytics feature in SharePoint 2010 at the site level. The only problem is that the available hardware is a single server with a single SQL box without much hard disk space. You explain to the client that the hardware might not be up to the challenge and that it might be necessary to take one or more of the following actions before the desired func- tionality can be implemented: • The hardware must be sufficiently upgraded (which requires more money and more configuration time). • A third-party product must be procured and connected to SharePoint 2010 at a later stage. (This doesn’t directly affect immediate implementation of some functions, but it does introduce additional support issues, costs, and most likely implementing a separate product.) Chapter.2 32. Chapter 2 SharePoint 2010 Project Mantra • Commit to the client request, but have the client agree to accept the risks to the hardware. • Omit the feature or features that result in extra costs (time or money), and push those features into a category of items to be investigated at a later date. What you have just done is carried out a quick evaluation and weighted the outcomes of each alternative. The key thing here is that the client is involved and has a say in which of the alternatives is satisfactory. This is an example of renegotiating the scope, and it should be done for every key aspect of the implementation plan. Let’s analyze a few other reasons you might need to renegotiate the project scope: • Hardware The existing hardware might be a reason to renegotiate scope if the SharePoint 2010 implementation is going to be a medium farm (more than one front-end server, application server, and attached to an SQL cluster) and you find that there is simply not enough capacity in the infrastructure (meaning not enough serv- ers are available or the available servers are not up to the job). • People The proposal to install SharePoint 2010 includes managing the implementa- tion going forward. If you find that the people assigned to the task are not capable of managing a SharePoint 2010 implementation, you need to ensure that the project scope addresses this shortcoming. • Budget Your project is underway. Your SharePoint 2010 implementation is taking shape. The farm is in place, and some development efforts are underway. The client indicates there is a change in the budget for the project. In this case, the scope must be re-evaluated to ensure that the project goals are aligned with the new budget. Avoid.Having.to.Whittle.Your.Scope.Down.to.Nothing The scope of your project to implement SharePoint 2010 is crucial. It states the agreement between you and the client. The one, overriding scope we’re discussing here is the one for implementing SharePoint 2010 according to the client’s requirements; however, most projects have more than one scope because there are at least four stages to implementing SharePoint 2010: Chapter.2 Avoid Having to Whittle Your Scope Down to Nothing. 33 • Stage 1: Content Assessment and Architecture Review An assessment is con- ducted of the way the organization works with data and how individuals work together. Scope 1: Develop a hierarchy that facilitates information management and solves information challenges. • Stage 2: SharePoint 2010 Site Development A basic SharePoint 2010 site struc- ture is developed that provides a practical foundation to address the business and technology issues identified during the content assessment and architecture review. Scope 2: Design a physical site framework and taxonomy, and build relevant SharePoint 2010 portal sites. • Stage 3: Portal Pilot SharePoint 2010 is installed; the solution is implemented and tested in the environment. Scope 3: Provide training and awareness sessions to users and support teams. • Stage 4: The SharePoint 2010 portal is operational. Scope 4: Provide best practices for management and governance. Even though there are scopes at every stage of this implementation, it is important to state clearly and without ambiguity the absolute lowest level of what you can achieve. For exam- ple, consider the scope of Stage 1 of a SharePoint 2010 implementation which is somewhat nebulous: “Develop a hierarchy that facilitates information management and solves information challenges.” We need to examine that scope closely. The real meaning of that scope is the you’re an investigation of the current work processes of the organization (that is, an understanding of how the client personnel communicate and collaborate with content). Based on under- standing these processes, your stated scope identifies how SharePoint 2010 will be imple- mented to solve the client’s information challenges. For example, suppose that the client needs to get SharePoint 2010 up and running as quickly as possible. Because of the time constraints, the client suggests removing the Stage 1 scope. If this scope is removed, there is a serious risk that SharePoint 2010 will not be implemented around any well-planned design or in a way that aligns with any client work processes. Without this scope, the scopes for stages 2, 3, and 4 become either redundant or meaningless. Scope 2 (technically design and implement SharePoint 2010) would then Chapter.2 34. Chapter 2 SharePoint 2010 Project Mantra have to be revisited because the processes of the client are unknown. If the client performs a large amount of Excel reporting and uses external services through SQL, and Scope 1 is ignored, how will you know that you should install Excel Services and investigate and implement Business Connectivity Services to enhance the use of SQL data connectivity? Be careful not to heavily whittle down or eliminate your scopes. At the same time, ensure that the scopes you do put in place are fully understood by the client. Your.Best.Project.Tool.Is.Your.Plan Installing SharePoint 2010 requires a skilled and multifaceted technical team. From a busi- ness perspective, SharePoint requires careful implementation for a client new to content collaboration and sharing. It is therefore important that you have a plan that reflects all the aspects of the installation so that the client understands what is being done, when it is being done, who is doing it, and how much it costs. There is little point in assuming there is a project plan when installing SharePoint 2010 and the client asks “Hey, how is the SharePoint 2010 installation going?” And the reply is “No problem. It is all in my head.” Amazing as it might sound, I’ve seen that happen. There’s good project engineering and bad project engineering. Good project engineering leads to tangible progress. Bad project engineering hinders progress. In the past, project managers have generally used e-mail as the top collaborative tool. So you were likely to hear conversations like the following: “Where is that business case?” “Check my e-mail.” “What about those project risks?” “Ahh, let’s check my e-mail.” “Can you give me your status report on the project, please?” “No problem. Let me check my e-mail.” That approach can work, I suppose. However, if you are running a project team where information needs to be updated, collated, and reviewed by more than one person, that is not a great way to run your project. So ensure that you have the necessary tools available for proper communication. SharePoint 2010 is perfect for this because it enables you to Chapter 2 Your Best Project Tool Is Your Plan 35 centralize, share, and manage all aspects of your project. This functionality can be show- cased to your client as you work together on the project. Remember that your SharePoint 2010 Project Plan defines the what, when, and why on the project. In Chapter 3, “Content of Your SharePoint Project Plan,” I will describe the elements of your plan and how you can place your SharePoint 2010 Project Plan on an Implementa- tion site, managing it using SharePoint 2010 features and functionality. SharePoint 2010 provides you with tools that ensure your project can be managed effec- tively. SharePoint 2010 helps you accomplish this in the following ways: • By centralizing your project documents and project communication You can easily create document libraries to store key project items such as the Business Case, Project Quality Plans, Risk Management Lists, and Configuration Management Plans. In fact, every form and procedure in this book can be created as a list of information. • By integrating existing project management tools (for example, Project Pro- fessional 2010) SharePoint 2010 integrates with Project Professional 2010 so that working on a Work Breakdown Schedule (WBS) is easy. Note Project Professional 2010 is designed to assist project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets and analyzing workloads. The application creates critical path schedules, although critical chain and event chain methodology third-party add-ons are available. Schedules can be resource leveled, and chains are visualized in a Gantt chart. Additionally, it can recognize different classes of users. These different classes of users can have differing access levels to projects, views, and other data. Custom objects such as calendars, views, tables, filters and fields are stored in an enter- prise global which is shared by all users. • By providing tools to automate project management processes For example, you can create a Risk And Issues log and have automated alert processing for it. In this case, when a project member submits a risk it can be automatically e-mailed to the project manager for action and then routed as part of the Quality Plan document in a document library. Risk items in a SharePoint 2010 list can be connected to physi- cal data in a document library. • By providing project reporting using dashboards SharePoint 2010 provides rich and detailed information by graphically reporting content information using built-in charts. . setting up of SharePoint 2010 from a business perspective; there- fore, don’t expect that the word “scope” is about searching scopes in the SharePoint 2010 Search Crawling feature! A SharePoint 2010. have been added in. The preceding scenario is a combination of two types of feature-scope creep—customer-pleasing and gold-plating— Chapter.2 30. Chapter 2 SharePoint 2010 Project Mantra because. Your SharePoint Project Plan,” I will describe the elements of your plan and how you can place your SharePoint 2010 Project Plan on an Implementa- tion site, managing it using SharePoint 2010 features