Create an upgrade communications plan (Project Server 2010)

Who is on the upgrade team?

For small deployments, the upgrade team might consist of only one person. For larger deployments, on the other hand, several people with different roles can be required, as described in the following list:

• Server administrators   The server administrator performs most of the upgrade tasks. There must be at least one server administrator on the upgrade team because running the Setup wizard requires someone who is a member of the local Administrators group on each front-end Web server.

  Note

  Farm administrators might not be local administrators for the server.

• Project Server administrators  Project Server administrators are trained to use the various Project Web App configuration and control features. They are responsible for modifying and maintaining general settings of the EPM application such as enterprise global codes, Project Web App views, Microsoft Project Professional global settings, and so on.

• Database administrators   If you have a separate database administration team, you must coordinate with it to schedule the upgrade and perform the upgrade, especially if you plan to use the database-attach upgrade method.

• Server security teams   You must coordinate with your security teams, such as the Active Directory directory services team, to verify accounts and permissions or to take advantage of the new policy settings that you can apply for Project Server 2010.

• Client deployment team   Communicate with client deployment teams to coordinate deployments of the new Project Professional 2010 client and server applications. The client deployment team also has to verify that all Project Web App users support the new browser requirements (Internet Explorer 7.0 or newer). Backwards compatibility mode (BCM) allows you some flexibility in scheduling your Project Professional 2010 client upgrade. This team should also contain a representative for the Project Management Office (PMO).

• Developer staff   If you have custom templates, Web Parts, Web services, or other custom elements associated with your Project Web App sites, you must work with the people responsible for developing or customizing those elements to ensure that you can create new versions of these custom elements or verify that these elements have been upgraded correctly. You must also ensure that custom applications developed to work with Project Server are still functional. This is especially true when you are doing a database-attach upgrade where many of the customizations will have to be redeployed manually to the new environment..

• Project Server users   This group can include general Project Web App users, team members, Project Managers, Timesheet managers, and all other people who access data in Project Server. You must communicate to both Microsoft Project Professional and Project Web App users about when the upgrade will occur and what they should expect with regard to changes. If you have existing Project Professional 2010 users, you must notify them about features that will be enabled when you disable backward compatibility mode in Project Server 2010. Prior to the upgrade process, you must inform users of tasks that they should do to ensure that the project data that they work with is in an upgradeable state. Communicating pre-upgrade tasks to end-users (for example, "ensure that all projects are checked in") helps prevent problems during the upgrade

• Network engineers   Network engineers must work with server administrator to do tasks such as creating new DNS entries, and so on.

• Sponsors and other stakeholders   You might have other people in your organization involved in the upgrade planning process. Make sure that you include them in your communication plan appropriately.

  Note

  An upgrade team can include one or more members in each role, depending on your organization.

When and what to communicate to the upgrade team

In general, the server administrators and shared services administrators set the timeline for upgrade, and site owners are notified only when the process is about to begin. However, because team members have their own tasks to perform at particular points in the overall upgrade process, make sure that you have a solid plan to communicate the progress of the upgrade to all team members so that everyone knows when it is time to perform their particular tasks.

The whole upgrade team must work together to determine the following:

• The upgrade approach to use   The "Determine upgrade approach (Project Server 2010)" article contains information to help you decide which kind of upgrade to perform. The report generated by the pre-upgrade checker is also important to consider when you make this decision.

• Dates and times to perform the upgrade   We recommend (especially for an in-place upgrade) that you upgrade when site usage is low. For small single-server deployments, upgrade may be completed in less than a day. For larger deployments, such as server farms with large amounts of data, it can take much longer. There is no way to determine the precise length of time that will be required to upgrade. Because of this, it is very important to communicate with other team members involved in the upgrade process in addition to end-users. The day or days that you choose for upgrading should be far enough in the future that the upgrade team has enough time to complete all of the preliminary steps. When you plan the timeline, make sure that you schedule time to validate the upgraded Project Web App site and project data and also schedule time to implement any changes.

It is important to communicate with site owners, designers, and developers at the following points during the upgrade process:

• Before the process starts, so that they know the general timeline and what their roles in the process will be.

• After the upgrade, so that they can validate their upgraded data and the Project Web App site, and can make any changes that are needed.

When and what to communicate to site users

It is equally important to communicate with the Project Server users about the following issues:

• When their sites will be upgraded   In the case of an in-place upgrade, users must be informed that they will be unable to access data during the upgrade. You must also inform users to leave the data in a state that is ready for migration. (For example, they should check in all projects before the upgrade.) This helps eliminate problems that might occur during the migration.

• When to expect Project Server 2010 to be ready to access   "Ready to access" means that the upgrade team has not only upgraded but also verified the functionality after the upgrade. You must also prepare information that is required for users to connect to the upgraded version such as the new Project Web App URL for an upgrade performed by the database-attach method).

• How the upgrade might affect them and what they should know about the new environment   For example, the Project Web App site will look different and function slightly differently in the new user interface. You can prepare training materials, such as quick reference sheets, to prepare users for any changes that might have occurred in the processes they do in Project Server. You can also point them to available content, such as "What's New" articles, to learn about the new version.

• How to get help   If users find an issue with the data after the upgrade, where can they go for information or help?

Gold Certified Partners

Microsoft has certified several partner companies as experts for EPM deployments and system migrations. You can find partners on the Microsoft Web site by searching for EPM solution providers at Microsoft Solution Marketplace (https://go.microsoft.com/fwlink/p/?LinkId=187521).