Project Management Handbook

Project Management Handbook Technical Services

Project Management Handbook

Version 1 – June 20th, 2002

Version 6 Page 1 of 35


Table of Content 1. Introduction _____________________________________________________________________ 3

A. The Project Management Mission _______________________________________________ 3 B. Objectives ___________________________________________________________________ 3 C. Why project management?_____________________________________________________ 3 D. Project Management tools _____________________________________________________ 4

2. Overview of PM Processes __________________________________________________________ 5 A. Roles and responsibilities ______________________________________________________ 5 B. Project Management processes _________________________________________________ 5

I. Standard project lifecycle ________________________________________________________ 5 a. Initiate __________________________________________________________________ 6 b. Analyze_________________________________________________________________ 8 c. Plan______________________________________________________________________ 9 d. Control/Execute__________________________________________________________ 9 e. Transition ______________________________________________________________ 10

3. Detailed procedures ______________________________________________________________ 11 A. General planning guidelines ___________________________________________________ 11

1. Templates _______________________________________________________________ 11 2. Task Descriptions _________________________________________________________ 11 3. Milestones _______________________________________________________________ 12 4. Costs____________________________________________________________________ 12 5. Effort vs. duration _________________________________________________________ 12 6. Resources _______________________________________________________________ 12 7. Interdependencies ________________________________________________________ 12 8. Enterprise Project fields -- __________________________________________________ 13 9. Enterprise Task fields______________________________________________________ 15 10. Grouping_________________________________________________________________ 15 11. Use Notes! _______________________________________________________________ 16 12. Formatting _______________________________________________________________ 16

B. Groups in Web Access________________________________________________________ 16 C. Enterprise Resource pool _____________________________________________________ 16

1. Creating the enterprise resource pool: _______________________________________ 16 2. Managing the Enterprise Resource Pool: _____________________________________ 17

D. Planning process ____________________________________________________________ 20 E. Initial Publishing of a plan to Web Access _______________________________________ 21 F. Reporting Cycle _____________________________________________________________ 23

1. Overview ________________________________________________________________ 23 2. Updating work in Project Plan_______________________________________________ 25 3. Time Approval and Plan Update_____________________________________________ 27 4. Changes to the Plan_______________________________________________________ 28 5. Progress and Status Reports and Views______________________________________ 30

G. Issues tracking ______________________________________________________________ 31 H. Project Closure _____________________________________________________________ 33

Workflow summary __________________________________________________________________ 35



1. Introduction

A. The Project Management Mission Project Management is a team effort that has its base in traditional management theory but has developed its own system of tools and techniques. Project Management is often viewed as simply being a software package that provides a schedule for the project. Project Management is more than that, it is a set of disciplines and principles that support an efficient way of managing a project. The need for a consistent set of tools and a tailored project management framework has stemmed from the desire to have the ability to view real time project status and performance data from the group’s portfolio of projects at any given time. This includes organizing all the projects currently underway, as well as proactively anticipating future engagements. This Project Management Handbook details the processes, workflows and detailed procedures related to the new framework. Its purpose is to serve as a reference manual for the group’s managers as they work to make the processes a part of their daily operation.

B. Objectives Specifically the vision is to implement a framework that will enable the department to: • Improve communication and collaboration within project teams and across all functional

areas. • Improve the project management capability of the IS groups by leveraging Project

Management “Best Practices” and providing a streamlined approach to managing all project activities.

• Leverage the features of Microsoft Project and other tools to facilitate project tracking, time reporting, resource management and status reporting.

• Help facilitate monthly project activity reporting by providing accurate, concise and objective data.

• Provide the capability to present a portfolio view of all projects that incorporates business metrics and critical success factors.

• Create Project Plan templates based on the standard processes and incorporate the appropriate level of detail in each phase. This process will be used as the basis for supporting the project lifecycle and critical milestones.

• Document lessons learned throughout all phases of the solution development and implementation.

C. Why project management? Today, there appears to be an almost unconstrained demand by lines of business that needs to be balanced with the delivery capabilities of the organization. Company-wide initiatives must be prioritized across multiple lines of business, and this greatly complicates a number of issues such as accountability, prioritization and the allocation of limited resources. This often forces Information Services into a reactive mode. To accomplish the objectives, it is necessary to seamlessly integrate PM processes and tools to support people as they perform their roles and responsibilities as project managers and project team members. Processes form the foundation of the solution. A single repository for project plans is needed so that inter-project dependencies can be analyzed and conflicts can be resolved. Integration of time management will ensure that milestones are met. Resource management functions are essential to ensure the organization’s resources are dedicated to the most business-critical initiatives, are used efficiently and are not over-committed. The effective communication and collaboration of everyone in Information Services is essential.



D. Project Management tools Currently Information Services uses Microsoft Project 2002, with MS Web Access, as a 2-tier solution for Portfolio Management.



2. Overview of PM Processes This section discusses PM processes specific to Information Services.

A. Roles and responsibilities • Project Sponsors: Those senior management members who are accountable for the

deliverables of a project at its highest level. The stakeholders signoff on project initiation and closure. They receive information on project status from the Project Managers (progress to date, on time, on budget, critical issues…) and in return make budget and resource decisions. Sponsors can include the Product Manager (customer), the Information Services Manager, or whoever else in senior management that has budgetary responsibility for the project other than the project manager, e.g. the area manager.

• Project Managers: own the project plan, assign resources, request and review weekly status reports (accomplishments, upcoming deliverables, issues, actual vs. baseline), maintain the project plans (create baseline, ensure posting of actual work, prepare reports). They approve/decline updates made by the resources. They are responsible for reporting status to the stakeholders and for managing the work performed by the resources

• Team Members: perform the work assigned to them by the project manager in the project plan. The resources are responsible for reporting back to the project managers on the status of the tasks assigned to them (current tasks as well as tasks that they will be working on in the future). In addition it is the responsibility of the resources to report to the project managers whenever specific issues with the project arise. They may also be assigned the resolution of the issues specific to their tasks.

• Administrator: manages the technical aspects of project management, especially those related to the PM tool package. The administrator keeps track of project charters (or project initiation forms), organizes project plans into a portfolio, creates and maintains accounts for the PM tool set, generates reports and views for use by the project team.

B. Project Management processes I. Standard project lifecycle

The standard project management lifecycle follows the phases: Initiate, Plan, Control/Execute and Close. The process within each phase of the lifecycle is discussed in details below.



The project phases for the IS template map to the project management lifecycle as shown: Phase PM Lifecycle

Initiate Plan Control/Execute Close

Project Phases

Initiate Analyze Plan Design Build & Test Implement Transition

a. Initiate

Building a formal process to handle project requests is a vital step towards eliminating unrealistic workloads and ad-hoc resource assignments. The ability to decide which requests will become projects begins with understanding the definition of a project: a project is a temporary endeavor with a beginning and an end, creates a unique product or service and has interrelated activities. Getting the project management lifecycle started requires certain information from the customer, and other information from the organization performing the project. Inputs to the initiate phase include: • Information on the benefits achieved by executing the request (project business case) • Assumptions and constraints (what the project can/will and cannot/will not achieve) • Information on the criticality of the request (regulatory requirement, product to market issue,

maintenance, etc…) • Information on resource availability Benefits achieved derive from an understanding of the customer’s needs in the context of the enterprise business plan and project portfolio strategy. Understanding the assumptions and constraints up front sets the stage for effective scope management through the life of the project. A formal way to assign a priority level to a project helps the project assessment committee better manage their own workload as well as the workload of the performing resources. Knowledge of resource availability reduces the risk of initiating a project that cannot be supported in the defined timeframe. Goals of the Initiate phase: • Identify the project owner/manager. • Define the high-level, critical deliverables. • Document the charter information for the project in the Project Overview Document (POD). During the Initiate phase, the project assessment committee performs an initial screening on the project requests that come into Information Systems (IS). If the committee agrees that IS has resource capacity to perform the work, the request gets a preliminary approval from the committee. Then the project is assigned a project owner/manager (see Roles & Responsibilities). This action establishes management responsibility for the project and empowers the selected manager to drive the project forward. Having a clearly defined focus of ownership for the project is critical to getting the project ‘off the ground’. The information that is gathered and documented in the early phases by the project owner not only allows the project approval committee to make an informed decision to approve or reject the project, but also sets the stage for the early success of the project team once it is formed. Understanding the customer’s assumptions and constraints helps define the main project deliverables. Defining the main deliverables provides the first look at the baseline scope of the project. The main deliverables are also a key component of the project charter. The project charter document for IS group is the POD. The POD serves to document the reason for performing the project, the high-level scope, preliminary project timing and cost, and resource requirements, among other information. This document provides the department director with the concise view of the project needed to make a Go/No Go decision on the project.



Request

Project OverviewDescription (POD)

Resource AllocationCommittee

RACmeeting

RAC acceptsproject?

Return tocustomer

No

Yes

Prioritizeproject

Assignresources

Place project inportfolio

General info(name, area,customer...)

Benefits &criticality

Resourceavailability

Customer

Managersignature

Scope, Criticaldeliverables,

Costs

Analyze

Informcustomer

Director acceptsproject?

Informcustomer

No

Yes

The Resource Allocation Committee provides project assessment for IS. The following diagram illustrates the Initiation process for an IS project.

1) Every week the Information Services manager and the project managers decide which of the latest change control requests will become project candidates.

2) Benefits and criticality determine priority. 3) Projects are assigned a project owner/manager (see Roles & Responsibilities). 4) A Project Overview Description is completed for each of the candidate projects, and a

unique project identifier is assigned. 5) The department director accepts or rejects the candidate project.



b. Analyze During Analyze, the project owner gathers the information that supports the planning phase, and, if necessary, the development of the Capital Expenditures Request (CER), which funds the project. Inputs to the Analyze phase include: • The Project POD • Customer input on project requirements The Project POD provides the starting point for expanding on the project scope. Customer requirements help drive detail into the scope, and lay the foundation for developing the work breakdown structure (WBS). Knowledge of the scope and requirements allows the Project Manager to identify capital expenditures. Goals of the Analyze phase: • Complete development of the scope document. • Obtain customer agreement on set of requirements. • Complete the CER. The Analyze phase is not as process driven as the Initiate phase. The work requires a solid knowledge of the product desired, and process and resources required to produce it. If the desired product closely resembles previously developed products, the analysis phase can draw heavily on records from previous projects. Requests with more unique aspects require an informed extrapolation from prior experience. The Analyze phase is completed when the CER is approved.



c. Plan The planning phase allows the project manager to define manageable pieces of work and organize them into a schedule. Templates available in the tool provide standard process milestones, but the project manager may also need to define additional milestones based on the specific deliverables identified in the analysis phase. To plan realistically for the project it is important to identify dependencies on external departments (e.g. “get confirmation that Engineering has completed task xyz”) or on tasks to be executed by other Information Services groups. The planning phase is also critical to get an estimate of resource requirements and availability. Careful attention to planning will enable the project manager to forecast time, cost, and to minimize time spent on re-forecasting dates when changes come up. Inputs to the Plan phase: • The Project POD • The Project CER • The customer requirements • The final scope definition • Information on available resources • The MS Project template Using the POD, the requirements, and the final scope definition, the Project Manager creates the WBS for the project. The WBS allows the Project Manager to review the template and make necessary modifications. Projects that closely resemble previous efforts may not require a full WBS development effort, but going through the process reduces the risk of unanticipated work. Once the template is customized with all the necessary tasks and dependencies, the correct generic resources are added to any new tasks. Work and duration estimates should be reviewed and updated for all tasks, as the template may not reflect the specifics for the current project. Completing these steps sets the plan up for identifying, and applying to the plan, the specific resources available to support the project. Goals of the Plan phase: • Assemble a fully defined project team. • Develop a realistic plan that provides for the customer’s requirements. • Document any necessary adjustments to the proposed timing and budget from the POD and

CER. Once work on the plan is complete, the plan can be approved. Only after being approved is the baseline saved on the plan. This now becomes the basis for change control for the project, as well as the tool for tracking progress and cost.

d. Control/Execute In the Control/Execute phase the project team executes the tasks described in the project plan and the Project Manager uses the plan, and other tools, to keep the team on time, within budget, and developing the product to the customer’s requirements. In other words, the Project Manager is controlling the project. Inputs to the Control/Execute phase: • Approved project plan • Reporting cycle



• Templates for other controlling activities: issues management, risk management, communications management, scope management, and quality management

This phase of the Project Management lifecycle corresponds to the Design, Build & Test, and Implement phases of the Project process. During this time, the project product takes shape. The team members focus primarily on creating the deliverables defined in the WBS, but also provide information to the project plan about the work they do. The plan helps the team members know what they should be working on at a given point in time, and the team members record the time spent on tasks in the plan. Team members reporting time in the project plan forms the foundation of the project reporting cycle. From team time reports, the Project Manager can determine how the project is tracking to schedule, and gather most of the information on project costs. The plan is also the primary tool used to track resource needs and identify resource concerns. The reporting cycle is the process by which the Project Manager keeps project sponsors informed of the project status. In addition to schedule, cost, and resource status, sponsors are kept informed about project issues, risks, and requests for changes to project scope. Generally this additional information also originates with the project team during communications with the Project Manager. The team communicates to the Project Manager how things are going with their activities, and the Project Manager captures their concerns as issues, risks, or an impact on scope, depending on the nature of the concern.

Goals of the Control/Execute process: • Produce the project product to the customer’s requirements. • Track the project to both schedule and budget. • Track and manage project issues, risks, scope and quality. • Establish team communications that support the previous three goals. • Provide regular status reports to project sponsors. The Control/Execute phase often covers the most time of all of the lifecycle phases, and generally consumes the majority of the budget. Control activities often begin ramping up before this phase begins, and generally ramp down during the next phase, Transition. The majority of control activities, however, occur in conjunction with Execute activities. The Control/Execute phase ends when the project successfully reaches the Go Live milestone.

e. Transition One of the defining features of a project is that it is finite; it has a start and an end. A clear end to a project serves several purposes, and a well defined transition into post-project phase of the product’s lifecycle helps assure the purposes are achieved. • Without a well-defined transition to an end, the project may spend an unnecessary amount of

time drifting between project and operational management. Resources that should be released to other projects get tied up in the unending tasks that crop up around any new product.

• The Transition phase should include activities that capture lessons learned from the experiences of the project team. These lessons are then archived, along with the other project information, so that they are available to support future projects.

• Any gaps between the final product and the customer’s requirements that were identified before Go Live and accepted by the customer, as well as any new requirements documented during the project but not incorporated into the project, should be collected as requirements for future projects.

Inputs to the Transition phase: • Lessons learned documented throughout the project



• The project plan, including all status information through the Go Live milestone • All project documentation supporting issues, risk, scope, and quality management • Any action items that came out of final customer reviews Several meetings make up a key part of the Transition phase. In some cases, these meetings can be combined. The meetings may also include more attendees than mentioned here. One meeting includes the Project Manager and the project sponsors. This is a final status meeting. The meeting covers the final performance numbers on the project, lessons learned, and any open items (actions or issues). Another meeting includes the Project Manager and representation from the group that is receiving the project product (the customer, the Operations Manager, or the manager for the project that is receiving the product). The goal of this meeting is to discuss and hand off any open items, as well as any information needed to use or maintain the product. Finally, there is a meeting with the Project Manager and the project team. This meeting should celebrate completion of the project, and recognize the contributions of the team members. This meeting is often overlooked in the overall project process, but can play a key role in maintaining employee enthusiasm for supporting projects. Goals of the Transition phase: • Close out the project plan. • Summarize the final project status. • Capture and publish lessons learned. • Recognize the accomplishments of the team. The transition phase is complete when the manager of the group receiving the project product signs off that all required material and information has been transferred to her/his control. A formal sign-off document can facilitate closure.

3. Detailed procedures

A. General planning guidelines 1. Templates

They are available in MSP2K2. Project Managers select “File -> New” and choose the appropriate template. The templates contain standard repeatable sets of milestones organized by standard phases. Project Managers should retain the standard milestones and phases from the template for their plan and add specific tasks related to their project. Templates may come equipped with custom fields that are necessary to proper grouping in Web Access views. It is important that each task be “tagged” with the appropriate value of a custom field. The default view of templates displays the fields that need to be filled in.

2. Task Descriptions

Task descriptions should be action statements. They should have verbs and nouns. They should produce a tangible piece of work. An example of what not to include is: “Analyze”, or “Execute”. Because the task coding capability in MSP2K2 allows data to be formatted in any number of ways, one cannot expect the task position within the plan to provide a contextual clue as to what the task description means. A filter on all Analyze activities could produce 30 lines that are all identical, “Analyze”, yet refer to different activities. The task descriptions should be as specific as possible: “Execute OQ protocol for autoclave” is a good task description.



3. Milestones Milestones are zero-duration tasks. They should be used only to mark the beginning or the end of a series of tasks or phases, or to mark an external dependency (e.g. “get engineering signoff on construction start”). 4. Costs

Cost gets calculated by assigning a rate/hour to each human resource or a cost to material resources 5. Effort vs. duration

Work (or effort) is measured in hours and represents the amount of work needed to accomplish a task if the resource had nothing else to do. Duration is the amount of time elapsed between when the task starts and when it ends. For example, testing a process may require 10 hours of work (or effort) but will take a duration of 2 weeks to complete. Duration is what will be used for scheduling, and work will be assigned to each resource. Confusion between WORK and DURATION often causes inconsistencies in team planning exercises.

By default MSP2K2 makes all tasks effort driven. This means that if one of either duration, work, or units (% of allocation of a resource) assigned to a resource change, the other 2 get adjusted to reflect the change:

• If the assigned task type is Fixed Units, then assigning additional resources will shorten the duration of the task.

• If the assigned task type is Fixed Duration, then assigning additional resources will decrease the individual unit values for resources.

• If the assigned task type is Fixed Work, then assigning additional resources will shorten the duration of the task.

By default MSP2K2 uses “Fixed Units”. It will keep the duration of the task the first time a set of resources are assigned to it. After that, if resources are added to a task, its duration will be shortened, unless the plan owner adjusts the units (% allocation) of the resource. 6. Resources

The plan should be down to a level of detail whereby named or generic resources can be accurately assigned to the specific activities. The weekly management, and the update cycle of the plans will include resource loading and reassigning the resource usage to ensure that no single resource has more than 40 hours allotted in any given week. A resource naming convention should be used as follows Last name First name (e.g. Gore Albert, Bush George). An enterprise resource pool will be created and stored on the database, and plans should utilize enterprise resources by building the project team through selection of resources from the Enterprise Resource Pool (Tools->Build Team from Enterprise…). Note: it is important to assign resources before saving the baseline, as it will affect the calculation of some of the metrics used, such as CPI (Cost Performance index) and SPI (Schedule Performance Index). 7. Interdependencies

If there are dependencies to tasks that are not held within the portfolio of projects, these should be identified as milestones (“get engineering signoff to start xyz”), as described in the milestone section. All tasks should have predecessors (unless they are a start task), and successors whereby the logic within the plan can be calculated. Only by having the correct logic



within the plan, can the plan be scheduled and used to identify the risk areas and the areas where more resources/effort are required to meet the date requirements. In MSP2K2, predecessors and successors can be linked with four types of task dependencies:

Task Dependency Description Finish-to-start (FS) Task (B) cannot start until task (A) finishes. Start-to-start (SS) Task (B) cannot start until task (A) starts. They can be done in parallel. Finish-to-finish (FF)

Task (B) cannot finish until task (A) finishes. They can also be done in parallel.

Start-to-finish (SF) Task (B) cannot finish until task (A) starts. This dependency type can be used for just-in-time scheduling up to a milestone or the project finish date to minimize the risk of a task finishing late if its dependent tasks slip. If a related task needs to finish before the milestone or project finish date, but it doesn’t matter exactly when and you don’t want a late finish to affect the just-in-time task, you can create an SF dependency between the task you want scheduled just-in-time (the predecessor) and its related task (the successor). Then if you update progress on the successor task, it won’t affect the scheduled dates of the predecessor task.

8. Enterprise Project fields --

Enterprise Project fields are tags used at the Project level for sorting, grouping and reporting purposes and are used extensively in Web Access reporting. One of the features of Web Access is its ability to show project plans grouped in a portfolio. The Web Access administrator can define a Project Center view by selecting projects to be displayed and the attributes (at the project level, not the task level) to be displayed for each project. The following picture shows the portfolio view that is available once project plans have been published (see next section for publishing plans to Web Access):



To ensure that Web Access displays project plans in a portfolio view, the following enterprise fields have to be filled in the “Project -> Project Information” window in MSP2K2: Field Description Required? Sponsoring Department

Organizational entity that has requested the work to be performed in the project.

Y

Performing Department

Organizational entity that has responsibility for completing the work represented by the project.

Y

Program A program is a logical grouping of projects, created as separate projects so as to more effectively deliver on a complex initiative.

N

Priority Priority is used to keep track of the priority of the project in regard s to the overall objectives of the organization.

N

CER Number Capital Expenditure Request number

N



ISSR Number Information Systems Service Request number.

Y

CIP Number Capital CBS Number Capital Budget Personnel/Resources Stoplight use to indicate if

resource issues exist (St. Johns or Vendor) Green - Satisfactory Yellow - Issues Red - Critical Concerns

Y

Funding/Budget Stoplight use to indicate if project is on schedule with regards the project budget Green – On budget Yellow - Concerns Red - Critical Concerns

Y

Vendor Delivery Stoplight use to indicate if vendor is on schedule to meet their project deliverables – Green – On schedule Yellow - Concerns Red - Critical Concerns

Y

Project Schedule Stoplight use to indicate if project is on schedule to meet its deliverables – Green – On schedule Yellow - Concerns Red - Critical Concerns

Y

Once the plans are published in Web Access, this will be an easy way to group projects because these fields have to be entered only once at the project level in Project Professional.

9. Enterprise Task fields

In the definition of the Enterprise, the enterprise Task fields available are: Field Description Required?

These custom fields are tags used at the task level for sorting, grouping and reporting purposes.

10. Grouping Using custom fields or enterprise codes, the tasks can then be grouped in MSP2K2. For this use “project -> group by ->” and choose a pre-defined group. These groupings make very good views for reporting purposes.



11. Use Notes! Each task has a “Notes” field attached to it. Liberal use should be made of the notes to assign details or status to a task (e.g. “get confirmation on completion” or “depends on meeting with vendor”). 12. Formatting • No abbreviations or slashes (slashes create problems in Web Access), unless the

plan owner will never share his plan with anyone. • Can use different font size or color to indicate WBS hierarchy • Size the columns with auto fit for dates, durations, etc… along with a date format that

is short but yet gives enough details. The task name column can be made shorter and the line size adjusted to fit long task names. Column titles can be shortened to keep the column narrow (e.g. “%” instead of “Percent Complete” or “Pred.” instead of “Predecessors”)

• Always print the notes

B. Groups in Web Access • Administrator: there is only one Web Access administrator, whose duty is to create user

accounts, create views, create new groups and categories if necessary, specify which plans can bee seen for each category.

• Executive: They have their own category in Web Access. An Executive is the person who owns a portfolio of projects and is ultimately responsible for ensuring that projects conform to the strategy of the organization. The executive reviews project reports in Web Access and makes decisions that impact the direction and execution of projects.

• Resource Managers: Resource managers are set up by the administrator to see assignments and availability of resources within their reporting structure. The resource manager reviews utilization and assignment reports in Web Access and makes decisions that determine the assignment of resources to projects.

• Project Managers: They have their own category in Web Access. The Project Manager is the person who owns the project plan in MSP2K2 and is ultimately responsible for updating it. The project manager publishes and re-publishes (when changes are made) the project plan to Web Access, and approves the work posted against each task by the resources. Project managers are set up by the administrator to see assignments of resources they’ve assigned work to.

• Team Member: This is the group that applies to resources assigned to the tasks in the project plan. They are responsible for posting the work accomplished (hours per day) against every task on a daily basis (or a weekly basis for long projects) in Web Access. They inform the project manager of foreseeable delays or constraints. Those can be reported in the status reports in Web Access or the project managers can use the notes fields of the appropriate tasks in MSP2K2.

C. Enterprise Resource pool 1. Creating the enterprise resource pool:

The creation of the enterprise resource pool is done by the resource pool administrator. The resource pool is a single repository for all enterprise resources used with a Microsoft Project Server. Resource records and summary resource assignments are stored in the enterprise database. The enterprise resources use the base calendars and enterprise resource fields defined in the Enterprise Global. Project opens enterprise resources when the user opens an enterprise project or when the user checks out one or more resources. When you open an enterprise project, only those resources that are assigned in the opened project are listed in the resource sheet. Resource sharing is turned off; if more resources are needed then you need to checkout the resources to add them to your project (the Build Team facility can be



used for this). On Save, the resource information in your enterprise project is updated with the most current data and summary resource assignments from the enterprise resources. Resources that become inactive should not be removed from the resource pool but set as inactive and will be filtered out of the view.

2. Managing the Enterprise Resource Pool: The maintenance of the enterprise resource pool is to be done by the resource pool administrator. Periodic updates of Resources, addition of resources, addition of Generic resources and the inactivation of existing resources will be required in order to maintain the Enterprise Resource Pool in a current state.

Notification of Non Working Time: Sick days and vacations will have a direct impact

on project plans, since there is the potential that work has been previously scheduled for the effected days and now must be rescheduled. Additionally, current the planning process should be aware that those dates are not available for a particular resource. To ensure that resource calendars are up to date, the Resource Pool Manager will manage a process to receive notifications of planned (vacations, training, etc.) and unplanned (sick days, emergencies, etc.) non working time and to update the Enterprise Resource calendar with this information.

Resource PoolAdmin (RPA)

receives notificationof Non Working

Time

Resource callsOPS to notify of

illness

RPA UpdateResource 's calendar

in EnterpriseResource Pool

Calendar Update process

Resource createsout of officenotice in MS

Outlook OPS creates outof office notice in

MS Outlookforresource

Planned

Unplanned

Planned – Currently, resources create out of office notices using MS Outlook to block the days in their calendar that they will be out of the office. A mail address will be created for the Resource Pool Administrators and the resource will include this mail address as an invitee to the out of office notification. The Resource Pool Administrator will review all notifications received and access and update the resources calendar at the Enterprise level to reflect the planned non working days.

Unplanned – Unplanned non-working time, such as sick days, will result in Operations receiving notice from the resource of the non working time. Operations will then create an out of office notice for the effected resource and will include the Resource Pool Administrator as an invitee to the out of office notification. The Resource Pool Administrator will review all notifications received and access and update the resources calendar at the Enterprise level to reflect the unplanned non working days.



Updating of Enterprise Fields:

Over time, the initial enterprise information used to describe a resource will change. This information could includes the resource’s location, skills description, organization to which they report or email address. Keeping this information up to date is required in order to more effectively use the functionality provided by the application. Requests for updates to the enterprise information should be made to each resource group on a periodic basis (quarterly). The Resource Pool Administrator will manage this process and ensure that all changes are received and updated to the enterprise resource pool. Resource Managers will be ultimately responsible for ensuring the accuracy of the resource information. Using Web Access, the Resource Manager will access the Resource Center page and if necessary filter for the resources that they control.

Selecting a resource and clicking the ‘Edit Resource Details’ button will allow the Resource Manager to update the information on the resource



Adding New Resources to the Pool: Requests for adding new resource (both Named

and Generic resources) will be required to be sent to the Resource Pool Administrator. The Resource Pool Administrator will ensure that all required enterprise field information if provided in order for the resource to be added to the Pool. Requests that do not contain the required field information will be returned to the requestor.

Enterprise information:

Field Name Required?Name Y Initials Y Email address Y NT Domain/Login Y Job Code Y Job Title Y Location Y Department Number Y RBS Code Y Skill 1 Y Skill 1 Level Y Skill 2 N Skill 2 Level N

Inactivating Pool Resources: As resources become no longer involved in project activities, requests will be made of the Resource Pool Administrator to inactivate resources. The Resource Pool Administrator will ensure that the inactivation of the resource is authorized and that the timing of the inactivation will not interfere with the updating of any project plans that the inactivated resource may be a member of. As adding new resources will increment the number of licenses tracked by the application, inactivating resources will decrement the number of licenses tracked by the application.

Generic Resources: Generic resources are a new type of resource added to Microsoft Project. Generic resources support skill-based resource assignment and replacement by allowing you to define and save frequently used skill/code profiles (specific values for one or more enterprise resource fields). They are handled much like work resources except that since they are not actual resources you can not create a Microsoft Project Server account or send them assignments via Microsoft Project Server. Generic



resources can be stored in the Enterprise Resource Global or locally. If stored in the Enterprise Resource Global then you need permissions (set in Microsoft Project Server) in order to Open or Save the pool as well as permissions to add, edit or delete generic resources. A new field, Generic, has been added to indicate when a resource is generic; the values are Yes and No. In the Resource Information dialog box on the General tab, you can also choose to make a resource generic.

D. Planning process The initiation and planning

Open templatefrom Project

Server.

Define tasks ormodify existing

tasks

Review majormilestones and

deliverables

Input internaldependencies(to other plans)

Set predecessorsfor all tasks

Save the plan in thedatabase: "File ->Save As", enterproject name, enterenterprise fields andclick "OK"

=

Build projectteam and

assignresources to

each task

Tag all taskswith appropriate

Enterprisecodes

Save Plan with a"Draft' status

1) Use pre-defined templates from the Project Server database when possible: they contain re-usable groups of phases and milestones that will serve for standardizing project initiation.

2) Define manageable pieces of work (usually tasks about 5 days long) Set predecessors relationships for each task. Only by having the correct logic within the plan, can the plan be scheduled and used to identify the risk areas and the areas where more resources/effort are required to meet the date requirements.

3) Utilize major milestones as defined in the Project Template(s). Add additional milestones and deliverables as required by your project.

4) Identify dependencies on external departments (e.g. “get confirmation that Engineering is done with task xyz”) and define them as milestones (zero-duration tasks).

5) For dependencies on tasks appearing in other plans, set predecessor/successor relationship between plans.

6) Build project team and assign resources to each task (not to summary tasks, this creates problems for resource usage calculations). It is important to use resources from the Enterprise Resource Pool. The initial project team can be composed of Generic and



named resources. Initial assignment of tasks to Generic resources will allow for a detailed planning of the work. Substitution of named resource for the assigned Generic resource will occur after resource commitments have been made.

7) Tag all tasks with the appropriate code value (see “Enterprise Task fields” in the planning guidelines above)

8) Save plan as a ‘Draft’ status to the Project Server database.

E. Initial Publishing of a plan to Web Access After a project is initiated and planned, the project plan is prepared and developed to a point where it is an accurate reflection of the work to be performed to accomplish the objectives of the project. At this stage, the team as been assembled and assigned to tasks and work is ready to commence. The plan is now ready to be baselined and published to Web Access. Publishing will allow the project to be included in the defined Views in Web Access so that management can report on the state and progress of the project.

Check that Enterprise fieldsare correct

Colaboration tab, enter url ofWeb Access, leave unchecked

options to publish on everysave

Select the tasks you want toassign and send updates for

("Collaborate -> Publish -> Newand Changed Assignments ",

choose "selected tasks")

Make sure that the plan isupdated with actual dates as

of today

Verify that plan resources arepool resources (Contact the

Admin. if resources need to beadded to the resource pool)

Review project against projectchecklist and notify

Administrator

Publish the plan toWeb Access

Administratorreviews project

against checklist andpublishes plan

Save the plan(in the database)

Unbaselined task arebaselined

Review plan with Sponsoror management committeeto validate scope, timeline

and resources

1) Make sure that the plan is updated with actual dates. The project should be current and accurately reflect the agreed upon scope, timeline and resource commitments.

2) Define Review the plan with the project sponsor and or management committee to obtain approval for scope, timeline and resource commitments as captured in the plan.

3) Ensure that the Project and Task Enterprise codes are correctly captured. This is required to ensure accurate reporting in Web Access.

4) Ensure that that url for Web Access and all collaboration options are correctly identified in the Collaboration Options.

5) Verify that the plan uses enterprise pool resources are required. Local resources may be used but only for resources (such as vendors or contractors) that are not to be entered into the Enterprise Resource Pool. The Resource Pool Administrator should be contacted if resources identified in the plan need to be added to the resource pool.



6) Review project against the project checklist to ensure that all enterprise standards are met prior to the plan being published. Notify the Application Administrator that the plan is ready for their review.

7) Notify team members of their assigned tasks and or updates to previously assigned tasks. Assignments can be made for all project tasks or only selected tasks ("Collaborate -> Publish -> New and Changed Assignments ", choose "selected tasks").

8) Baseline the project plan. If selected tasks have previously been baselined, then select all unbaselined tasks and baseline those tasks.

9) Save the plan to the Project Server database. 10) The Application Administrator will review the project plan prior to its initial publishing into

Web Access in order to ensure that the plan complies with the standards governing the project management system. The following checklist will be employed to assess the readiness of the plan for publishing.

Measure Criteria Admin

Review Tasks are able to standalone & are named with active verbs

Yes No

If Web Access training is required, ensure it is planned or scheduled

General Req Yes

Defined phases exist and correspond to the enterprise standard phases

Yes Yes

Tasks grouped into logical, related steps (WBS )

Yes No

All Tasks have predecessor/successor relationships

100% No

Standard Milestones represented in Plan 100% Yes Plan allows for project management activities.

Yes No

Plan version is updated to ‘Published’ Yes Yes All work tasks have assigned resources (named or generic)

Yes Yes

Baseline has been saved for comparison. Yes Yes Plan uses resources from the enterprise resource pool.

Yes Yes

Resource workload does not exceed resource availability.

Yes No

Enterprise codes and values are complete and current

100% Yes

Review collaboration options to ensure proper setup

Yes Yes

Scope document exists Yes No Project Charter document exists Yes No

Plans not conforming to administratively reviewed enterprise standards will be returned to the Project Manager (who owns the project plan) for further development. The Application Administrator will work with the Project Manager to assist in bringing the plan into compliance.



Plans conforming to the enterprise standards will be published to the Web Access server by the Administrator. Subsequent publishing will be the responsibility of the Project Manager.

Notes: • Publishing a plan doesn’t ensure that it will be visible in the Web Access portfolio

view. It will only be visible if the project manager assigns work to any resource by “Collaborate -> Publish -> New and Changed Assignments”, or if the Administrator allows users to view any published plan.

• The ability to view a project in a Project Center or Project View is determined by your assigned permissions and security. If a plan is published but you can’t see it in the Project Center view, contact the Web Access administrator who will determine the cause.

• After each subsequent updates from the reporting cycle, the plan should be re-published in Web Access (“Collaborate -> Publish -> Project”), and teams should be given updated assignments by (“Collaborate -> Publish -> New and Changed Assignments”).

F. Reporting Cycle

1. Overview A defined reporting cycle is essential for maintaining the accuracy of the information represented in the project plan. In an environment where there is transparency of information to multiple groups, project plans must be maintained on a regular basis so that the reflect their current state.



Resource updatestasks in Web

Access

Send Notifications ofChanges

(Collaborate->Publish->New and Changed

Assignments )

PM reasssigneswork (if plan has

changed)

PM approvestasks/Plan is

updated

Project published toWeb Access(Collaborate-

>Publish->ProjectPlans)

Progress Viewsprinted by PM

Generate StatusReports

Requests forTime Updates

sent by PM

• Entering time via timesheets in Web Access: As the project progresses, resources assigned to tasks update their actual work on Web Access daily (or weekly for long projects) in the form of hours of work per day in a timesheet view. The more often work is updated, the more “real time” the status can be.

• Updating the plan via timesheets in Web Access: Project Managers review the resources updates before they get updated into the MSP2K2 plan. This is done via Web Access.

• Updating the plan directly into MSP2K2: The Project Manager should update the project plan directly for all the tasks that are not assigned to the team of resources. The project manager should also directly update tasks assigned to resources outside of Information Services, such as contractors or other departments. Only the tasks assigned to resources will be sent to Web Access to be via timesheets, all other tasks should be updated in MSP2K2 directly by the project manager.

• Notifications of Changes: As the plan is updated, changes are made to the plan directly by the updates provided by resources and by the project manager through edits to their plan. These changes will potentially impact resources assigned to the project by creating new task assignments or changes to existing assignments

• Publishing: Once the plan is updated (time and task updates), the Project Manager will re-publish the plan to Web Access. This is required in order to update the Web Access Views with the current project information. This action allows the Project Manager to determine when changes to the plan are complete and therefore available for viewing by management.

• Views: Once the plan is updated and published to Web Access, different views in Web Access can be accessed for reporting purposes: different summaries of actual vs. baseline, resource usage per project, portfolio views and other.

• Reports: Project managers should set up regular status report requests in Web Access, along with headings for subjects to discuss. The resources fill the status reports; they can also choose whether or not to automatically include the description of tasks due in that cycle as a basis for discussion. Issues and delays are addressed there in a written form. Status from each resource is then collated per project by Web Access for the project manager (see appendix for sample reports)



2. Updating work in Project Plan

Request Progress Information At the start of each reporting cycle, the project manager can send a notification to each project resource requesting a task update. This optional step is accessed by selecting Collaborate-> Request Progress Information from the menu.

• Resources are sent an email message as this is a special request, but you can modify the message using the “Edit message text” button.

• Resources are marked on the project plan as having an Update pending. As task updates are received and processed by the project manager, this indicator is removed, allowing the project manager to quickly determine which resources have not sent in their task updates for the reporting period.

• This command also allows you to select the time period for which you are requesting

Here’s the “Request Project Information” dialog:

Time Entry in Web Access: Regular progress should be entered into Web Access by those assigned to the tasks in the project plan. The resources update their work in the “Timesheet” view of Web Access. The work is updated in hours of work per day. The resource then sends the task updates to the project manager from Web Access per the frequency (daily or weekly) as established by the project manager at the start of the project.



Entering Time in the MSP2K2 plan directly Most tasks in the plan will be sent to Web Access to be updated by the resources via timesheets. Some tasks may not be sent to Web Access for various reasons and should be updated in MSP2K2 directly by the project manager. For example, the project manager should directly update all tasks assigned to contractors or other departments that do not have a timesheet in Web Access. The plan owner can update the plan with actual dates and progress by doing “tools -> tracking -> update tasks”. A window appears where the plan owner can enter actual start actual finish, remaining duration etc…

The plan owner can update the plan with actual hours and dates through direct entry using the Task Usage View or the Resource Usage View. Right clicking on the right pane will allow the project owner to display Actual Work as well as Work cells.



Important: If the project manager makes changes to the plan in MSP2K2 (e.g. duration change, baseline is saved, actual dates are recorded, etc…) the plan manager should remember to publish the changes to Web Access (see details in “Publishing a plan to Web Access” above) and possibly re-assign work to the resources if the changes affect their assignment.

3. Time Approval and Plan Update

Time Review: 1. The project manager will receive an email notification from the team member

informing them that they have submitted a task update. 2. The project manager will log on to Web Access to review the updates submitted per a

review cycle determined by the project manager required in order to meet the reporting requirements of their project.

3. In reviewing the task updates, the project manager will: a. Approve the updates to the task (which automatically updates the plan in

MSP2K2). A record of the rejection is maintained in the project manager’s transaction history.

b. Rejects the update and ask for more information before applying the changes. By rejecting a task, a notification of the rejection is sent to the resource directing them to review their time entries and to resubmit their time. A record of the rejection is maintained in the project manager’s transaction history.



4. Changes to the Plan

New and Changed Assignments: After changes are made in the project plan by the project manager, task assignments may change for the resources. Changes can take the form of delays to start dates, durations, new resources assigned, new tasks inserted into the plan and or changes to work estimates. To provide updates to resources for which task assignments have changed, the project manager is required to send notifications informing their resources of these changes. This is accomplished by the project manager do “Collaborate -> Publish -> New and Changed Assignments” in Project Professional.

Here is the Publish New and Changed Assignments dialog:



• “Publish new and changed assignment for”: dropdown list includes: Entire project, Current view (as in a filtered or collapsed view), and Selected items. The ‘Selected items’ refers to those tasks you have select prior to getting to the dialog box.

• You can choose to group by Resource or Task. • “Notify all affected resources via email” if selected sends an email notification to

resources, even if they have deselected this option in Microsoft Project Server. • Edit message text allows you to review and modify the email message sent to your

resources. • The Start and Finish dates are for the assignment and not the task; this is an

improvement over Microsoft Project 2000.

Re-Publishing the Project Plan At the completion of the updating changes to the plan, the project plan must be re-published to Web Access in order for changes to be reflected in the Web Access Views. This command posts the project to Microsoft Project Server, You can choose between posting just summary info for the project plan or the full project plan. This menu item brings up the following dialog:

Republish Assignments… - This command replaces “Resend all messages” and includes two new options. Here is the dialog:



• “Overwrite any actual work entered by resources” if checked, this sends assignments to Microsoft Project Server and overwrites the original assignment. If not checked, the assignment information is sent to Microsoft Project Server but leaves any actuals that are already recorded. (Note: Checking “Overwrite any actual work entered by resources” should only be used in situations requiring the re-building of the project in Web Access and where the project plan has been updated to include all current activity. Using this function should be coordinated with the Application Administrator.)

• “Become the manager for these assignments” allows you to take over as manger for selected tasks. This option is discussed in more detail in the Multiple Project Manager Support section of this document.

5. Progress and Status Reports and Views

Progress Views and Reports • Web Access status reports: in Web Access each project manager and

executive manager can set up a cyclical status report, with customizable headings (e.g. “this week’s accomplishments”, “next week’s deliverables”, “reports approved this week”). The reports for each resource are collated into a single report for the project manager. Reports are archived in Web Access. The resources can choose to insert the tasks due during the cycle. Those status reports are “verbal/written” reports where the resources give their perspective on the project status. Web Access or MSP2K2 does not measure data such as on time or on budget when generating these reports.

• MSP2K2 reports: MSP2K2 features many standard reports on progress, cost, assignments, tasks, etc… Each report can be customized using the report wizard. To choose a report got to “view -> reports”.

• TS tracking view: in MSP2K2, once the plan has been baselined, columns baseline start, start, baseline finish, finish, and the calculated fields (On time, CPI, SPI) offer a good tracking view. Using the “TS tracking” view in MSP2K2 will display the following bars: baseline bar, actual bar, critical path. Such reports can be copied and pasted into Word by using “file -> copy picture” in MSP2K2.



• Monthly Status View: a Web Access View has been created to show the information captured in the Monthly Status Report.

• Resource usage: this pre-defined view in MSP2K2 will show over-allocated resources in the resource pool.

Weekly Status and meeting schedule The project team (project managers, team members, others) should meet on a weekly basis to initiate and discuss projects and report issues and status. The project manager will review the outstanding issues and risks associated with the project and will receive updates from each team member assigned to their resolution. Team members will report on the progress of their assigned tasks. Weekly, the project manager will present: • A general status of the project (e.g. on time, %complete) • A general status of assigned tasks by each team member • A listing of projects issues and risks

G. Issues tracking Tracking issues should be done at the task level, either directly in MSP2K2 using notes, or in Web Access using STS (SharePoint Team Services) and status reports. If issues are tracked in the task notes, it is easy to print just the notes and have a record of the issues. If issues are tracked using Web Access, issues can be linked directly to a project task and assigned to specific resources for resolution. Issues lists can be generated as Excel spreadsheets directly from STS.





The project managers will bring up the project issues at the weekly project team meeting in order to get status on each issue’s resolution and to assign new issue to resources.

H. Project Closure



Create projectsummary report in

MSP2K

Closure meetingComplete Project

Initiation Formwith closure data

Document lessonslearned

Mark project ascomplete inMSP2K and

Project Central

Closure process

1) Once the project is close to completion the project manager should gather the stakeholders and main resources and discuss the project formally, using a project summary report from MSP2K2 (view -> reports -> overview -> project summary). This report summarizes date, work, and cost information.

2) The project closure form (second tab of the Project Initiation Form) should be filled with information related to recommendations for future similar projects, and a log of significant issues. It should be saved in the shared directory.

3) Lessons learned meetings should be conducted by the whole project team monthly to

discuss the projects closed that month. Lessons learned headings include (other than cost and schedule data from the MSP2K2 report): “what could be accomplished better”, “how could the management of the project be improved”, “recommendation for future similar projects”.

4) The project should be flagged as completed in MSP2K2 (file -> properties -> “keyword” field)

5) Cancelled projects should follow the project closure procedure and be flagged in MSP2K2 (file -> properties -> “keyword” field)

6) Postponed projects should also be flagged



Workflow summary

Closure

Create projectsummary report in

MSP2K

Closure meeting

Document lessonslearned

Complete ProjectInitiation Form with

closure data

Mark project ascomplete in

MSP2K(Keyword field)

Create plan fromtemplate, save in

database

Fill codes in fields

Publish toProject Central

Define milestones,dependencies

Assign resources

Save baseline

InitiationCustomer request

Project Initiation Form

1. General info

2. Benefits & criticality

3. Resource availability

4. Critical deliverables

5. Signoff

Prioritize Assign team

Place project in portfolio

Monitoring

Check plans areupdated

Receive status reportsfrom team in Project

Central

Report progressweekly

Planning

Execution

PM executes workaccording to plan

Resources updatework in timesheetvia Project central

PM updates plandirectly in MSP2K


Business

Project Management Handbook