Planning – overview

Planning a new SharePoint environment or a migration from an older SharePoint environment requires us to define future goals for collaboration solutions within our enterprise, as well as research to provide clear requirements and project schedules. Whether it's SharePoint or other collaborative applications, planning to add additional systems to your environment requires great insight. This requires attention to detail and building teams that can do the work to support the scheduling and delivery of the application.

For the record, I am not a project manager in any light but I understand what things should be identified as specific to a SharePoint implementation project. It doesn't take a PMP certification to understand the tasks and timelines needed for a successful implementation. These certified project managers look at these tasks differently from architects and measure against them using other mechanisms. In this planning chapter, I am just going to touch on the areas needed to help you as an engineer or architect understand your responsibilities and what areas need to be concentrated on as part of this process from an IT standpoint.

SharePoint is often a huge piece of the pie or central focus for many enterprise collaboration environments. There could be other cloud apps or large applications that play a part as well, but in this planning exercise, we will concentrate on SharePoint with some caveats where the integration or confirmation of other applications needs to be present in our plan. With SharePoint, there could be integration with the cloud or other Microsoft communication platforms, such as Teams, Skype, or OneDrive, which could play a part in how fast we can provide our environment to our user community. This may also require a different team or consultant who may be providing those services.

As you saw in the first chapter of this book, we assessed our environment, new features, and deprecated features, and did an overall assessment of our current state, be it new or already in place. In our planning process, we will use those documented areas to determine what needs to be completed to finish our project and what resources we may need to do so. We will also determine the time it will take based on these assessed areas by using the data to figure out what tasks are needed to complete the project.

These tasks could range from reporting or the clean up of our old environment to working to create our new environment. Some of our tasks could even relate to our last SharePoint project and the requirements will remain the same or look very similar. If you have an old SharePoint project plan, you can use some of those areas in that plan for a new project for SharePoint Server 2019. SharePoint at its core does not change, as you will see when we install a VM and host servers. Most of everything you have done in the past you will also do now. You will install SQL Server and SharePoint, which works very similarly to in previous installations. This can be said about every SharePoint installation we have installed since SharePoint 2007, with the exception of those environments where SQL Express was used for a single server installation, as this is not supported in SharePoint Server 2016 or 2019.

Goals and objectives

As part of our goals and objectives for our SharePoint project, we should proceed to start our planning by finding out the goals of the enterprise solution from a company standpoint. We want to make sure to understand how, as a company, they would like to use this collaborative environment to support the goals of the company. We also want to find out general information supporting the project, which would include information such as funding, completion expectations, and any other details related to the project.

This project will take a team effort as all requirements and tasks may not be specific to a central group. Coordination of these efforts is very important and should be completed before you start on any project, especially SharePoint projects. During this project, you will have internal meetings with many different teams supporting the project individually and collectively. This would include all external team representatives from the different specialist areas, such as Active Directory (AD), networking, database, server, governance, management, and user community, and whoever is a stakeholder in this implementation. These teams will need to be assembled, which would be a requirement before starting any technical configurations.

There could also be other projects in progress or in the planning stages that relate to your SharePoint project. This could mean integration points and/or other types of intercommunication that would need to happen to make sure your project is successful. An example of that could be an AD restructuring project. AD would be required to be completed before SharePoint could be installed and configured due to the fact that AD is the method of authentication needed for users and service accounts to be functional. AD restructuring, be it on-premises or on the Azure cloud, as a project could put our overall project on hold because identities needed for administrators and service accounts would not be able to be created. The reason AD restructuring is important is there could be a change in the domain structure or we could be upgrading to a newer level of server, cloud, or integrated authentication method, such as SAML. This could delay your project if you are bound to using this new AD structure.

One of the goals we need to understand before going forward is to determine the architecture and the reason SharePoint is being implemented. The architecture is important because it drives our cost, which also drives what resources we need to support the environment. As part of our assessment, we found out things that we need to change within our current environment and things we need to bring to the table to support our SharePoint 2019 environment. Let's take some fake data and make some determinations from that data to create some architectures to work with.