Planning – resources

Adding resources also adds to the cost of our project, but in most cases, the resources requested will be needed to implement and support the project. Resources are generally handled by your project manager but with full transparency supporting the IT team and management. Everyone involved needs to make sure that there is a good project plan as part of structuring this project and make sure there is the availability of resources, as well as enough team members to support it. The team also needs to make sure that they have the cycles to start and finish the jobs they are assigned to complete.

There could also be concerns with resources that have been assigned to the team where there could be other projects these resources have that could take priority or eat into the time they can spend on the project. One of the biggest errors I have seen in the field is under-resourced SharePoint projects. This is one area where you do want to pay attention and make sure you either hire personnel or contract the positions to get the work completed.

The change management board and operations teams also come into play in planning as since we are adding or changing resources within the environment, these changes need to be confirmed by the owners of the environment. This can also add more pain to the implementation and take up time you were not planning for. Make sure to add in planning for this change review to make sure there are no hidden scenarios where you will get behind on the project. One thing you can do also is talk to this group before you get started. This will help them understand what's coming and they may be able to give you details they may need to move forward successfully. I notice this especially in secured areas where the SharePoint service would be used.

Another issue that is always seen from my experience is that I will run into a SharePoint admin that has not had much experience with the product and/or there is one SharePoint admin supporting a large farm alone. I have also seen cases where SharePoint is running without any real supervision but relied on heavily within the company. In these cases, these scenarios almost always bring to light the issue that the support personnel are overwhelmed and do not know where to start to fix issues and expand when added requirements arise. The team, in some cases, can also be running the help desk, managing customers, applying updates to the servers, and supporting all other areas that come with the SharePoint territory. Make sure you budget for the right size team for the environment you want to support.

Here is an example of a resource matrix to support SharePoint:

Figure 2.5 – Resource matrix

To avoid scenarios where you have overwhelmed support personnel, management needs to understand that this product is not easy to implement, manage, administer, support, and maintain. The platform requires many skill sets, along with experience, to really support the environment in the right way. There are many best practices that can really drive you crazy if you do not have experience with the product that will creep up on you at a later time. There is a reason why these best practices are used and specified in the Microsoft documentation to support the environment, so do not bypass them.

Being new to the product or not as well seasoned can really cause projects like this to fail. Your resources should be somewhat seasoned in the SharePoint space and you should have a good understanding of the product. Remember that your project is only as good as the people implementing it.

The outcomes of this resource exercise should help create thought processes around gathering resources to support the platform for the help desk, site collection admins, and farm admins. The support for the platform is essential and we should not hesitate to get these resources in place before starting the implementation. Training and knowledge sharing also make a big difference in these roles; do not forget it!

I can't tell you how important it is to have resources available that understand the product and can help make supporting the product easier using separated roles that bring together a team of knowledgeable professionals. You will see a big difference in how users perceive your service and how less complex the support process can be.

Assessment review

An assessment review is a meeting of the minds of IT and management supporting the efforts of the implementation. This could mean your CIO, director, and, in some cases, the CEO would be part of this meeting. The goal of this meeting is to review your assessment and its results. As assessments can be done over intervals of time, these meetings may happen when assessments are needed for the farm environment. The attendees would have a chance to review the document before the meeting so that they can come to the meeting with an understanding and questions about the document as well. This gives those teams a heads up on what the project consists of, gives them an idea of the resources that may be needed during this project, and helps them to plan for what resources can be provided for you to work with during the project.

This is a somewhat difficult task because you do not want to overstate the project goals and you do not want to show huge costs for the project, nor do you want to overstate the requirements with solutions not needed. When management is reviewing whether to approve the work, you want to be cautious and explain things in good detail (where they need to be explained) and leave some areas out that are common and not elaborate on them in great detail if no questions are asked. This is because the scope of the meeting could be directed in the wrong direction due to comments on details that are already clear and understood.

However, we should be prepared for anything during the meeting and questions could come out of the left field. Make sure you know your presentation well and practice it with the other team members so that everyone understands the direction the meeting should go. If things are rehearsed or talked about in depth, there will be no error in the delivery of the message sent during the meeting. Keep the meeting simple and to the point, validating the assessment and areas of concern, how you plan to remediate those concerns, and the direction or path for the future.

Management will be all ears and listening to certain details. In the meetings I have been a part of, most managers and even executives do not want to hear too many technical details. They want to hear concerns, fixes, and costs, as well as how you are addressing those concerns. Those areas of technical concerns help with new solutions you plan to implement, but overall, management has no ears for IP addresses, protocols, and so on in most cases.

Now, I am telling you this from my experience, but there could be some CEOs and upper management who may want to hear more technical details to figure out why you are heading in a certain direction for the platform. Some CEOs and other management are technical, and in some cases, you will need to explain your position more thoroughly. You need to gauge your situation and plan for it accordingly.

Prioritizing requirements

As things change within an organization, the goals set out within an organization may change as well. When an organization makes those changes to its future goals, this can bring changes in personnel, security, structure, and business processes. As part of those effective changes, IT can be affected, which can bring change to the way the IT department delivers solutions and secures data and content, platform support, governance, and other IT policies, which, in turn, will affect the way the technical teams support the enterprise.

As a part of the goals of this planning prioritization exercise, we need to define the purpose and motivation for our new or migrated SharePoint farm to this newer version of SharePoint Server 2019. When defining priorities, please consider the following items:

• Top tasks
• Milestones
• Deliverables
• Schedules
• Organizational charts
• Resources

All these areas can affect our implementation project in ways where we will need to rework our project schedule. We don't want this to happen, so planning around current and long-term projects is a must to avoid any situations where you have to, for example, change your schedule or resources in the midst of implementation. If you want management to get involved and give you some grief, just let that happen and you will see things fall apart.

Another example would be a change in deliverables. If we had a certain set of deliverables and all of a sudden you forgot about RBS, and have to make a change where you have to go back and ask for money, this brings the pain. You want to make sure you prepare all areas, especially technical solutions that form the environment, to support the farm and its functional components.

Prioritizing what's important as part of the implementation is needed because there are logistics involved as well. You need hardware before software, you need a network before you can configure servers, and you need SQL installed and configured before SharePoint can be installed. These examples help you understand how important order is in your project plan.

With that, there will be some tasks that take priority in these examples. In the case of ordering software, finding out when the software would be delivered is an example. The delivery of equipment and software can ruin a project plan as well. It's best to get a list of the items you need to start the process before you get started writing your project plan, so you don't have any items that fall by the wayside. Licensing and even funding sometimes take time to procure, especially in government projects. Make sure to put in requests once you finalize your architecture so that these areas can be in the works while you are finalizing your plan.

This is a good place to start evaluating the timing and prepping resources. Look over your work and make sure you have taken everything into consideration. Changing things now can make a big difference in your timing, so you do not want to change too much at this point. Also, evaluate the platform you are proposing. Make sure you're making the right decisions and press forward.