Microsoft Project Server Deployment Plan Contents PMO Requirements 4 Number and Type of Project users 4 Types of Project users 4 Project managers 4 Resource managers 4 Team members 4 Portfolio viewers 5 Administrators 5 Business Requirements 6 Create the Enterprise Project Management

Microsoft Project Server Deployment Plan Contents PMO Requirements 4 Number and Type of Project users 4 Types of Project users 4 Project managers 4 Resource managers 4 Team members 4 Portfolio viewers 5 Administrators 5 Business Requirements 6 Create the Enterprise Project Management

Microsoft Project Server Deployment Plan

Contents
PMO Requirements 4
Number and Type of Project users 4
Types of Project users 4
Project managers 4
Resource managers 4
Team members 4
Portfolio viewers 5
Administrators 5
Business Requirements 6
Create the Enterprise Project Management (EPM) deployment team 6
Identify Key Stakeholders 6
Identify internal expertise resources 6
Managing resources 6
Identify Business Objectives 6
Executive and Stakeholder workshops 6
Identify management role impact 7
Prioritize business objectives and create a Master Deployment Plan 7
Establish milestones and metrics 7
Inventory processes 7
What processes exist and can be adopted? 7
What processes must be designed 7
Process whiteboard workshops 8
Resolve impacted management roles 8
Adopt, adapt, and design processes 8
Review, adapt, and accept designed processes 8
Automation Design and configure 8
Appling the process design document 8
Design and implement standards 8
Pilot EPM Tool 9
Install / configure / migrate data phase 9
Training 9
Run active projects 9
Lessons learned and document 10
Roll out into production 10
Go-live 10

?

PMO Requirements

Number and Type of Project users
We need to understand the maximum number of users that we need support.
Also to categorize users into different types and how many of each type.
PMs, Resource Managers, Administrators, Team Members and Portfolio Viewers are some on the types of users we will need to configure and calculate the percentage.
Types of Project users
The types of users that we will support, and the percentage of each. These types are as follows:
• Project managers
• Resource managers
• Team members
• Portfolio viewers
• Administrators
Project managers
Project managers are responsible for overseeing and completing projects, sometimes coordinating with other project managers and resource managers in the organization. Project managers use Project Professional to do the following:
• Create and publish projects to Project Web App
• Modify projects based on feedback
• Assign team members to project tasks
• Track progress by incorporating task updates from team members
• Determine target and actual project timelines and costs
Resource managers
Resource managers are responsible for managing resources and defining skills based on capabilities. They work with project managers and other resource managers to ensure that qualified resources are assigned to tasks in projects. Resource managers use Project Web App to do the following:
• View workload and availability by project over time
• View workload and availability by resource over time
• Add team members to project teams
• Post issues and upload documents
• Use Portfolio Modeler to determine resource availability
• Modify resource skills and other codes
Team members
Team members are resources who are assigned to complete tasks. A team member typically works on several projects and is responsible for completing assigned tasks according to schedule. Members of the team will use Project Web App rather than Project Professional.
Team members use Project Web App to do the following:
• Meet deadlines by identifying current and upcoming tasks to prioritize daily work
• Report time spent working on tasks by entering progress in timesheets
• Delegate and add tasks
• Record and respond to project-related issues and risks
• Link issues to tasks
• Submit status reports
• Work collaboratively with other team members on project-related documents
Team members use Outlook to do the following:
• View assigned tasks
• Report on assigned tasks
Portfolio viewers
A portfolio viewer is a user who uses Project Web App to view status or reporting on a project or multiple projects. For example, a portfolio viewer can oversee several different projects that are managed by different project managers to gain an overall perspective on schedule and budget. Project Web App is used by the Portfolio viewers to do the following:
• Use Portfolio Analyzer to view project and resource reports
• Issues submitted to project and resource managers for resolution
Administrators
Administrators manage access to the Project Server and related applications. Administrators use Project Web App to do the following:
• Define views for timesheets
• Lock timesheet reporting periods
• Create standardized reports
• Add and delete team members to and from the Enterprise Resource Pool

Project Manager Team Member Administrator Resource Manager Portfolio Viewer
PMO Member Manufacturing Information Technology Department Director C-Level
CI PM Quality Control PMO Director Department Manager VP level
Quality Assurance
Human Resources
Facilities
Clinical Operations
Materials Management
Document Control
Finance
Information Technology
Client Integration
Regulatory
Purchasing
Business Requirements

Create the Enterprise Project Management (EPM) deployment team
Several resources will have to be assembled in order to bring this project from the idea phase all the way to production. Key steps in the idea phase are:
Identify Key Stakeholders
Identifying the business/product owner of the system is critical to a successful EPM deployment and must be done almost immediately. The business owner will be the person who uses the benefits of the completed system and sees the value in going through what it will take to complete it. There may also be one or several executive sponsors.
Identify internal expertise resources
Determine the business owner and executive sponsors, the project team should determine what internal expertise is needed and available to move the project forward. Internal knowledge of the organization’s processes, practices, procedures, roles and responsibilities and where data can be located to drive the process will be essential.
Managing resources
This project as a project! We need to make a project schedule, a budget, a charter, allocate sufficient resources etc.
Time to accomplish this: Two weeks.
Identify Business Objectives
Identify the scope of the project, break that scope into phases then create a plan for the work.
What to accomplish in this phase:
Executive and Stakeholder workshops
There’s no way to get around this. The whole purpose of creating an EPM environment is to better enable management and end users to make business decisions. So the relevant management personnel will need to invest some time at the beginning of the process to help identify what decisions will be made using the system.
This is the opportunity for the deployment team to get two very important things while they have management’s attention. First, the commitment of management to the process, the effort and the ultimate benefits. Second (and far more important), the managed expectations of management. The most common management expectation is that this can be accomplished in a few days or a few short weeks. The results from these workshops will be the business objectives that will make up the scope and ultimately determine the schedule.
Identify management role impact
Once the business objectives have been agreed to, there will have to be a session or two identifying the impact on the roles and responsibilities of management. Resource capacity planning is always a request of the EPM system.
Prioritize business objectives and create a Master Deployment Plan
The plan should be broken into phases. The prioritization of which objectives to go for first is an essential element of success at this point. The top two or perhaps three objectives will be put into a phase and push everything else downstream.
Establish milestones and metrics
Create milestones into the project and also measurable metrics. With any project, making sure it is staying on track is important.
Time for this work: Four weeks
Inventory processes
We need to determine what processes will ultimately need to be automated in this phase.
What processes exist and can be adopted?
We need to start looking at what processes, practices, and procedures already exist in the organization for the business objectives identified in this phase and determine which can be adopted within the new EPM environment. There is a two-sided benefit to finding existing processes that can be adapted with little or no work. 1. They are created already and known to the users. 2. Adopting them makes a subject matter expert of the author in that process and in doing so, eases deployment.
What processes must be designed
Not all of the processes, practices, and procedures we need exist currently, we have to identify what’s missing. That can be harder than locating processes that exist already.
Process whiteboard workshops
For those processes that require work to be adapted or for processes that need to be created from scratch, we will need some workshop sessions with a white board. Walking through the process and all its implications is best done with the people who will live it once it’s done. Document everything.
Resolve impacted management roles
For any of the newly designed processes that affect roles, authority, hierarchy, or existing responsibilities, we will need to organize meetings to resolve them. The result of which is a draft of the process guide.
Time to accomplish the processes exercise: Four weeks.
Adopt, adapt, and design processes
Review, adapt, and accept designed processes
Process exercises that had happened previously will not include everyone’s input so, it is essential to get the draft of the new process guide published to the stakeholders and managers. The output of this process is a completed and accepted process document.
Time to complete process guide: Eight weeks

Automation Design and configure
Appling the process design document
Once we have the tool, we can start creating system design documents that start with our process document and end up in functional specifications. We’ll probably want a Development instance of our new EPM system installed so we can test or verify certain design criteria. For the first time, a system expert in the configuration of the actual system is required on board.
Design and implement standards
There are numerous standards that will need to be established. Each and every one of those standards carries implications in the system architecture and design. The calendar for example is often overlooked. Will we have one calendar or many? Will we have resource calendars? Who will have the authority to change them? Do we know the effects on the schedule and progress data of changing a resource calendar? And so on … Here are some of the elements of our EPM system that we will need standards for:
• Calendars
• Naming conventions
• Resource hierarchy
• Resource load standards for project and non-project work
• Rates and costing standards
• Roles and responsibilities
• Approval structures
• Project and task hierarchies
• WBS and other coding structures
• Document management
• Communication templates
• Project templates
• Design and implement dashboards
• Design and create links to external systems
• Design and create workflow
• Design and implement reporting
• Design and create EPM tool training
• Review design with all affected parties
Time required for this phase: Twelve weeks
Pilot EPM Tool
Identify the pilot group and get them working on it.
Install / configure / migrate data phase
Install the newly configured system in a Test server (not the development server. We’ll continue to use that for future phases and as a support and training system).
Training
Make sure our pilot personnel get the training they need to use the system properly.
Run active projects
Now, have those pilot projects be managed based on the processes, practices, procedures and automation that we’ve spent so much time defining. The pilot needs to have a schedule itself that is often oriented around how long these projects will last.
Lessons learned and document
Once the pilot project is complete, it’s time to reassemble and see how what was created solved the challenges that were set for it. If there are adjustments, corrections, or basic changes to make, now is the time.
Time for a complete pilot project and review: Twelve weeks.
Roll out into production
Go-live
It’s time. Roll out the use of the new system to the appropriate users and migrate the appropriate data. Don’t forget training, support, and follow up as the system goes live.
Time to rollout is highly dependent on the number of total users: Four weeks.