<Project Name>

Project Closure Report

Project Closure Report Template Instructions

(Please remove this section before completion of template)

The Project Manager(s) will complete the processes for closing the project budget and complete a closure report. Vendor invoices, salary information, POs, Banner Reports, are items updated in closing the Project Budget. The Project Manager(s) will update project documentation and access security and generate the Project Closure Report to include final comments and lessons learned on the project.

Be sure to maintain version control as the study is modified and/or edited.

All instructions within the template are italicized within the document.

Any examples are in a red font.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant.

The Project Manager(s) will complete the Project Closure Memo and Report and receive approval from the Steering Committee.

Be sure to unlock table of contents by selecting TOC then Ctrl-Shift-F11 to enable TOC updating in Word docx.

Closing Phase	Large	Medium	Small	Requirements	Approvals
Project Closure Report	R	R	O	This deliverable is required for large and medium scale projects and optional for small scale projects unless requested by the sponsor, steering committee or IT management.	The Project Manager(s) will complete the Project Closure Memo and Report and receive approval from the Steering Committee.

Table of Contents

1.	PROJECT CLOSURE REPORT PURPOSE	2

2.	Version Control	3

3.	PROJECT CLOSURE REPORT GOALS	4

4.	PROJECT CLOSURE REPORT SUMMARY	4

4.1	Project Background Overview	4

4.2	Project Highlights and Best Practices	4

4.3	Project Closure Synopsis	4

5.	PROJECT METRICS PERFORMANCE	4

5.1	Goals and Objectives Performance	4

5.2	Budget Performance	5

5.3	Metrics Performance Summary	5

5.4	Budget Performance Report	6

6.	PROJECT CLOSURE TASKS	7

6.1	Resource Management	7

6.2	Risk Management	7

6.3	Quality Management	7

6.4	Communication Management	8

6.5	Customer Expectation Management	8

6.6	Asset Management	8

6.7	Lessons Learned	8

6.8	Post Project Tasks	9

6.9	Project Closure Recommendations	9

7.	Approval	10

PROJECT CLOSURE REPORT PURPOSE

The Project Closure Report is the final document produced for the project and is used by sponsor, steering committee and senior management to assess the success of the project, identify best practices for future projects, resolve all open issues, and formally close the project.

The information entered into the tables under the Project Closure Tasks sections are copied in the PMO Department Project Closures spreadsheet attachment in the Project and Portfolio Management System.

Version Control

Version	Date	Person	Change
1.0	Initial Document Creation

PROJECT CLOSURE REPORT GOALS

This Project Closure Report is created to accomplish the following goals:

Validate the milestones and success of the project

Confirm outstanding issues, risks, and recommendations

Outline tasks and activities required to close the project

Identify project highlights and best practices for future projects

PROJECT CLOSURE REPORT SUMMARY

Project Background Overview

Project Highlights and Best Practices

Project Closure Synopsis

PROJECT METRICS PERFORMANCE

Goals and Objectives Performance

Project Name	Section	Category	Recommendation	Description

Budget Performance

Project Name	Section	Category	Recommendation	Description

Metrics Performance Summary

Project Name	Section	Category	Recommendation	Description

Budget Performance Report

(For assistance in completing this report please email ist-pmohelp@umdnj.edu)

[project name] Budget Performance Report
PM:
Project dates:
Project Budget
Budgeted Cost (Non-Capitalized)
$000.00
Budgeted Cost (Capitalized)
$000.00
Budget Cost (Total)
$000.00
Estimate (Non-Cap)	Estimate (Cap)	Total Estimate
Hours Estimate (Total)	Total T&E Estimated Cost (Capitalized)	Total T&E: Estimated Cost (Total)
.00	$000.00	$000.00
Hours Estimate Cost (Total)
$000.00
Total T&E Estimated Cost (Non-Cap)
$000.00
Actual (Non-Cap)	Actual (Cap)	Total Actual
Actual Budgeted Salary Expense (Total)	Total T&E Actual Cost (Capitalized)	Total T&E Actual Cost (Total)
$0.00	$0.00	$0.00
Total T&E Actual Cost (Non-Cap)
$20,734.13
TPC (Non-Cap)	TPC (Cap)	TPC
Actual Hours	TPC T&E (Capitalized)	TPC T&E (Total)
00	$0.00	$0.00
Hours Actual Cost (Total)
$0.00
TPC T&E (Non-Cap)
$0.00

PROJECT CLOSURE TASKS

Resource Management

Project Name	Section	Category	Recommendation	Description

Risk Management

Project Name	Section	Category	Recommendation	Description

Quality Management

Project Name	Section	Category	Recommendation	Description

Communication Management

Project Name	Section	Category	Recommendation	Description

Customer Expectation Management

Project Name	Section	Category	Recommendation	Description

Asset Management

Project Name	Section	Category	Recommendation	Description

Lessons Learned

Project Name	Section	Category	Recommendation	Description

Post Project Tasks

Project Name	Section	Category	Recommendation	Description

Project Closure Recommendations

Approval

The individuals below agree that they have reviewed and approved the plan outlined in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

EXAMPLE

Luminis 4 Upgrade

Project Closure Report

TABLE OF CONTENTS

1.	PROJECT CLOSURE REPORT PURPOSE	1

2.	Version Control	2

3.	PROJECT CLOSURE REPORT GOALS	2

4.	PROJECT CLOSURE REPORT SUMMARY	2

4.1	Project Background Overview	2

4.2	Project Highlights and Best Practices	2

4.3	Project Closure Synopsis	2

5.	PROJECT METRICS PERFORMANCE	2

5.1	Goals and Objectives Performance	2

5.2	Budget Performance	2

5.3	Metrics Performance Summary	2

5.4	Budget Performance Report	2

6.	PROJECT CLOSURE TASKS	2

6.1	Resource Management	2

6.2	Risk Management	2

6.3	Quality Management	2

6.4	Communication Management	2

6.5	Customer Expectation Management	2

6.6	Asset Management	2

6.7	Lessons Learned	2

6.8	Post Project Tasks	2

6.9	Project Closure Recommendations	2

7.	Approval	2

1.	PROJECT CLOSURE REPORT PURPOSE	2

2.	Version Control	2

3.	PROJECT CLOSURE REPORT GOALS	2

4.	PROJECT CLOSURE REPORT SUMMARY	2

4.1	Project Background Overview	2

4.2	Project Highlights and Best Practices	2

4.3	Project Closure Synopsis	2

5.	PROJECT METRICS PERFORMANCE	2

5.1	Goals and Objectives Performance	2

5.2	Budget Performance	2

5.3	Budget Performance Report	2

5.4	Metrics Performance Summary	2

6.	PROJECT CLOSURE SUMMARY	2

6.1	Resource Management	2

6.2	Risk Management	2

6.3	Quality Management	2

6.4	Communication Management	2

6.5	Customer Expectation Management	2

6.6	Asset Management	2

6.7	Lessons Learned	2

6.8	Post Project Tasks	2

6.9	Project Closure Recommendations	2

7.	PROJECT CLOSURE SUMMARY	2

PROJECT CLOSURE REPORT PURPOSE

The Project Closure Report is the final document produced for the project and is used by the project Sponsor and senior management to assess the success of the project, identify best practices for future projects, resolve all open issues, and formally close the project.

Version Control

Version	Date	Person	Change
1.0	June 22, 2009	Adam Levinson	Initial Document Creation
2.0	June 25, 2009	Adam Levinson	Revisions made
3.0	June 29, 2009	Adam Levinson	Revisions made
4.0	July 1, 2009	Adam Levinson	Revisions made

PROJECT CLOSURE REPORT GOALS

This Project Closure Report is intended to accomplish the following goals:

Validate the milestones and successes of the project

Confirm outstanding issues, risks, and recommendations

Outline tasks and activities required to close the project

Identify project highlights and best practices for future projects

PROJECT CLOSURE REPORT SUMMARY

Project Background Overview

The main objective of the project was to: Install and configure a portal implementation of the Luminis 4 application to include all the current functionalities in our my.UMDNJ portal running Luminis 3.3.3.

Project Highlights and Best Practices

Acquisition of the new hardware environment had begun prior to the project being initiated. This caused a slight cost overrun as the data center and servers were not properly spec’d for the new environment and required some additional purchases.

Installation of the new hardware environment, once all components were received, was completed in a timely manner and did not cause any delays.

With great support from the project Steering Committee, the project was able to enter and exit the Initiation Phase in under a month.

The Implementation Team was able to conclude the Planning Phase of the project in less than three months time. Participation from the resources on the Implementation Team was excellent.

Allowing preliminary/investigative work to occur in parallel to the Planning Phase achieved the desired result of shortening the overall duration of the project by approximately one month.

Implementation Team utilization of the Innotas system – while acknowledging room for improvement - was adequate for this endeavor.

The Change Control process was effective in organizing, prioritizing and executing the changes requested during this project.

Adherence to the PMO Project Methodology was excellent. Though this is led by the Project Manager, true success cannot be achieved without outstanding participation from the Steering Committee and Implementation Team.

Aided by the Communication Plan, project communication amongst the teams (Steering Committee and Implementation Team) was ideal.

Communication to various affected support groups, stakeholders and the University at-large could have been executed better.

Due to the diligence displayed during planning combined with the Implementation Team’s stalwart effort for enacting corrective action during execution, the project never had a slippage of target dates for any High-Level Achievement milestones.

Originally the project team was to be supplemented by a new Programmer Analyst FTE. However, due to circumstances outside of the project, this FTE was never added to the project team. Yet, all project milestones were achieved on time, on budget and in scope.

The project Go-Live target date was achieved.

The project was completed prior to the Banner 8 Upgrade project.

Project Closure Synopsis

The Luminis 4 Project is complete. All functionality that existed in the Luminis 3.3.3 platform was migrated to the new system and is operational. Daily, weekly, and monthly maintenance/support is now being performed as operational tasks.

PMO PM Methodology

This project conformed to the PMO Project Methodology. Although some purchasing activities were initiated prior to PMO PM involvement, this did not derail the project or any of the phase processes. All deliverables of the PMO Project Methodology were completed.

The following steps will be followed for closure of this project:

Prepare & Conduct Lessons Learned Survey

Create Project Closure Report

Update INNOTAS with all available project documentation

Gain Steering Committee approval for project closure

Mark Project Status as “Closed” in INNOTAS

Communicate to stakeholders that the project is closed

Project budget closure

PROJECT METRICS PERFORMANCE

Goals and Objectives Performance

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Goals and Objective Performance	New Luminis 4 hardware environment was acquired and installed correctly in the datacenter (HLA 1 & 2).
Luminis 4 Upgrade	Goals and Objective Performance	A development environment for Luminis 4 has been properly configured (HLA 4 & 6).
Luminis 4 Upgrade	Goals and Objective Performance	A production environment of the Luminis 4 application – my.UMDNJ.edu – was installed and configured correctly (HLA 7).
Luminis 4 Upgrade	Goals and Objective Performance	The upgraded portal, my.UMDNJ.edu, is fully operational and accessible to all user populations (HLA 7).
Luminis 4 Upgrade	Goals and Objective Performance	The project was completed prior to the Banner 8 Upgrade project (constraint).
Luminis 4 Upgrade	Goals and Objective Performance	Migration of Luminis 3 data to the production Luminis 4 environment has been completed (HLA 3 & 5).

*HLA numbers are referenced from the Project Charter

Budget Performance

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Budget Performance	The project budget was carefully and regularly monitored by the project manager. The final cost of the project budget is $90,000, with $15,527 remaining in surplus ($14,265 for salary, $1,261 for non-salary). These numbers include all budget adjustments made throughout the Initiation, Planning and Execution phases. However, it should be noted that the ‘redundant storage array controller’ purchased for this project was not charged against the project budget, but rather the Banner 8 Hardware Upgrade budget. This expense was $8599.49.

Budget Performance Report

Luminis 4 Budget Performance Report
PM: Adam Levinson
Project dates: 10.6.08 - 6.8.09
Project Budget
Budgeted Cost (Non-Capitalized)
$35,000.00
Budgeted Cost (Capitalized)
$55,000.00
Budget Cost (Total)
$90,000.00
Estimate (Non-Cap)	Estimate (Cap)	Total Estimate
Hours Estimate (Total)	Total T&E Estimated Cost (Capitalized)	Total T&E: Estimated Cost (Total)
1,652.00	$55,000.00	$125,580.00
Hours Estimate Cost (Total)
$70,580.00
Total T&E Estimated Cost (Non-Cap)
$70,580.00
Actual (Non-Cap)	Actual (Cap)	Total Actual
Actual Budgeted Salary Expense (Total)	Total T&E Actual Cost (Capitalized)	Total T&E Actual Cost (Total)
$20,734.13	$53,738.74	$74,472.87
Total T&E Actual Cost (Non-Cap)
$20,734.13
TPC (Non-Cap)	TPC (Cap)	TPC
Actual Hours	TPC T&E (Capitalized)	TPC T&E (Total)
1,570.25	$53,738.74	$120,099.85
Hours Actual Cost (Total)
$66,361.11
TPC T&E (Non-Cap)
$66,361.11

Metrics Performance Summary

This project tracked schedule, cost and scope using the PMO methodology and underwent several change management requests and approvals:

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Metrics Performance Summary	Scope Variance– through the Change Management process, the Steering Committee reduced the scope of the project by altering the amount of data and code cleanup work that was to occur in the Luminis 3 environment. The project completed within the baseline scope
Luminis 4 Upgrade	Metrics Performance Summary	Schedule Variance – the targeted completion date was adjusted slightly after the schedule was initially approved. These changes were approved by the Steering Committee via the Change Management process. However, as it relates to the project schedule baseline, there were no variances to targeted completion dates during Execution. Go-Live deadline was achieved. The project completed within the baseline schedule.
Luminis 4 Upgrade	Metrics Performance Summary	Cost Variances – the project completed within the baseline budget. However, if the ‘redundant array controller expense’ could not have been re-classed, the project would have suffered a cost overrun.

PROJECT CLOSURE SUMMARY

Resource Management

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Resource Management	Steering Committee participation and support was ideal for a project of this scale. Implementation Team participation was excellent. For most meetings we had 100% attendance and there was a true team atmosphere among the group. Work responsibilities were easily determined and the task duration estimation exercises were taken seriously and completed accurately.

Risk Management

A risk matrix was maintained for this project and Innotas was used to manage all risks and issues, including communication with management and team members.

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Risk Management	Test/Staging Server - the current Luminis 4 environment does not include a test/staging server. During the project, there were not enough available resources (people and hardware) to properly setup the test/staging environment. This risk was accepted by the project Steering Committee. The recommendation for mitigating this risk is to allocate resources from the Luminis 4 support team to properly setup, installation and configure a test/staging environment for Luminis 4.

Quality Management

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Quality Management	The baseline Luminis 4 application was tested and documented by the Implementation Team. Additional patches, UMD modifications, and external systems integration were also tested and documented by the Implementation Team. A User Acceptance Test Plan was developed to guide user acceptance testing. The UAT test team consisted of ‘end-users’ (not members of the project team), from all university populations. The UAT test cases were created by the Implementation Team. The UAT test phase was allocated three days for completion.

Communication Management

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Communication Management	The Implementation Team met weekly throughout the Planning Phase. The frequency of these meetings lessened to bi-weekly once the project entered Execution. Email and Innotas was the preferred method for information distribution that took place outside of meetings. Communications to the University were drafted by the PM with the aid of team members (Steering Committee and Implementation Team). The project sponsor reviewed and approved all Enterprise-wide communications before distribution.

Customer Expectation Management

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Customer Expectation Management	Three email communications were distributed to the University notifying them of the pending upgrade. The first email was sent out approximately one month prior to Go-Live. The subsequent email communications were distributed the week before Go-Live, reminding users of the upgrade and notifying them of the application downtime. In addition, notices were posted on various UMD application web pages, alerting users to the upgrade and downtime as well as providing information on alternate access methods. A final communication was distributed to the University after Go-Live was complete. This notice was also posted on the login page for my.UMDNJ.edu.

Asset Management

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Asset Management	SGHE and CST installed/racked one new Sun Fire v490 server in the Newark data center.

Lessons Learned

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Lessons Learned	Project Management-Administrative	Recommendation: calculate the statistics of who provided approval confirmation and include this as part of the lessons learned report, thereby indentifying the individuals who consistently did not participate.	Gaining approval confirmations from the Steering Committee on documents distributed via email allowed for additional convenience. However, this caused for many ‘implicit approvals’, where individuals did not respond with a confirmation.
Luminis 4 Upgrade	Lessons Learned	Project Management-Administrative	Innotas usage among the Implementation Team was adequate, but could be improved. Most team members had to be reminded to input status updates and log time for tasks. With the system being new to the University, this was expected but should be noted.
Luminis 4 Upgrade	Lessons Learned	Technical	Recommendation: allow enough time and resources (people, hardware, money) to properly setup a test/staging environment as part of future projects. This recommendation assumes that this approach is cost-effective for a given project. In addition, the work necessary to setup a testing/staging server should be completed as a post-project task and is identified as such below.	Testing/Staging Server - the lack of a test/staging server (documented risk), had an adverse impact on the project and was the source of many Go-Live problems. Without an identical, live, fully-functional Luminis 4 staging environment, it was impossible to adequately test the full spectrum of functionality offered through the portal. This led to Go-Live issues, specifically the breakdown of the Password Synchronization Utility (PSU).
Luminis 4 Upgrade	Lessons Learned	Technical	Recommendation: all configuration and/or code changes to any module, modification, or service offered in the portal should be distributed on a regular basis to the inventoried portal application developers.	CAS - the location of the Central Authentication System (CAS) service changed in the new Luminis 4 environment. This change was noted internally by the Luminis support team, but was never brought to the attention of the PM and other stakeholders and/or application developers. This change required application developers to update their code to point to the new location. Confounding the problem was that the UAT test case for CAS was developed with the anticipated code changes in mind. However, this allowed for a faulty test case that received all passing marks.
Luminis 4 Upgrade	Lessons Learned	Technical	Recommendation: document and keep current all server/application connections to the my.UMDNJ.edu portal. This document should be continuously cross referenced with change management notifications.	Servers/Applications-to-Portal Connections Architecture Document –servers and applications that communicate with the portal is not documented or is incomplete. This caused for some confusion when the DNS cutover occurred as many undocumented communication links broke. This was particularly evident with the ColdFusion servers, which all had to have their instances restarted before the applications they are serving in the portal would function again. Similarly, many security certificates became invalid and did not function properly due to the new IP address of the Luminis 4 server. These types of problems could have been avoided – or at the very least mitigated - if the server/application-to-portal connection architecture was properly documented.
Luminis 4 Upgrade	Lessons Learned	Technical	Recommendation: all configuration and/or code changes to any module, modification, or service offered in the portal should be distributed on a regular basis to the inventoried portal application developers. Also, please see above mentioned recommendation for a Server-to-Portal Connection Architecture Document.	LDAP Password Change – the LDAP password was changed for the Luminis 4 environment. This change was mentioned at Implementation Team meetings, but was never stressed as a potential problem. Because applications developers were unaware of this change, many applications broke on Go-Live. The required fix was simple (updating the LDAP password in their applications), but the problem could have been avoided entirely through better planning.
Luminis 4 Upgrade	Lessons Learned	General	Recommendation: for future projects, treat downtime as a priority and set metrics around the acceptable level of downtime. Similarly, planning for alternate access needs to receive greater focus from the project team.	Downtime/Alternate Access – downtime for this project was extensive. Mitigation of this problem was achieved by providing users with alternate access methods to critical portal applications. However, the impact of the downtime could have been heavily reduced if a parallel adoption approach was available.
Luminis 4 Upgrade	Lessons Learned	General	Recommendation: actively manage this list and treat these individuals as stakeholders, including them on communications regarding Luminis initiatives, projects, upgrades, etc.	Developer Inventory – an inventory of application developers does currently exist and is managed by the Luminis Support Team. However, the developers on this list were not identified as project stakeholders. Because of this, many of these developers did not know about the implications of the Luminis 4 Project as it relates to their applications. This caused problems on Go-Live (see CAS lesson learned).
Luminis 4 Upgrade	Lessons Learned	General	Recommendation: all support resources need to be treated as stakeholders for future projects with explicit representation on the project teams. This will create another communication channel that should help prevent the confusion that the support resources experienced for this project.	Command Center/Go-Live Support – support for Go-Live was coordinated in advance with multiple communications and meetings taking place. The support strategy was to offload the majority of the call volume to Presidium Support (vendor). However, once it was identified that the PSU and some CAS-based applications were not functional on Go-Live, Presidium Support was overwhelmed by call volume resulting in extended wait times for end-users (20 minutes or more). Being a third-party support resource, communication broke down on Go-Live and Presidium was not kept abreast of the critical problems the application was experiencing, further compounding the problem (re: they were unable fix the problems for the customers as the tools needed, namely the PSU, were not functional). Similarly the UMD Service Center began to receive an increased volume of calls, due to Presidium being unable to address the issues initially. Although there was better communication between the project teams and the Service Center, the problems remained the same and many issues went unresolved for several hours as the project team worked to correct the defects. Fortunately all critical defects were corrected in a timely manner, but the volume of calls for both Presidium and the Service Center were well above 1000% of the mean for the first 36 hours of Go-Live.

Post Project Tasks

Project Name	Section	Category	Recommendation	Description
Luminis 4 Upgrade	Post Project Tasks	Assist CST desktop support with identifying and correcting any desktops with my.UMDNJ.edu hard-coded into their HOST files. (BST, CST)
Luminis 4 Upgrade	Post Project Tasks	Adjust the Role names in Luminis 4 to better reflect their application role. When the roles were migrated, they were assigned generic Role names. (SGHE, BST, CST)
Luminis 4 Upgrade	Post Project Tasks	Reallocate and redeploy the hardware resources that make up the legacy Luminis 3 environment. (SGHE, BST, CST)

Project Closure Recommendations

Gain project closure approval from the Sponsor and Steering Committee, including agreement that the project has fulfilled all of the requirements identified in the Project Charter.

Gain project closure approval from the PMO Director indicating that all outstanding closure tasks have been appropriately addressed.

PROJECT CLOSURE SUMMARY

The individuals below agree that they have reviewed and approved the plan outlined in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date
Project Manager	Adam Levinson
Sponsor	Joe Konopka
SC Member	Bill Lansbury
SC Member	Brandon Singer
SC Member	Lori Falk
Co-PM	Yaw-Shing Wang
SC Member	Marilyn Bodow,