Project Postmortem & Completion Template – Tronmaster.com

Objectives

The project post-mortem is the installation of the new system in a production environment. It completes the current project efforts, and, in the event of a multi-project application, provides the transition to the next project.

The objectives of the project post-mortem are to:

• Implement the system
• Evaluate the operational effectiveness of the installed system
• Determine User satisfaction with the delivered system
• Determine whether the delivered system meets the original objectives
• Analyze systems development efforts
• Identify potential trends for future project improvement

Scope of the Phase

The primary focus of the phase is the installation of the new system in accordance with the acceptance portion of the Testing and Acceptance Plan. In addition, a Post Implementation Review of the completed project is conducted typically after two or three months of system operation. This will ensure that the review reflects the "true" system.

The Post Implementation Review consists primarily of review and evaluation. System operations effectiveness is determined by interviewing Users, observing operations and reviewing systems results. System evaluation is conducted by measuring system results against projected requirements, costs, schedule and resource utilization.

The Post Implementation Review efforts necessarily encompass each of the areas associated with the new system: User or administrative operations, systems development and maintenance, as well as the production Data Center facility.

The review must be conducted in an independent fashion to accurately assess the impact of the system and requires the participation of IS and Auditing.

The IS Department reviews and evaluates how the project performed against plan for schedule, cost and human resources utilization. Auditing conducts an in-depth review of the organizational areas associated with the new system and the cost effectiveness of the new system.

If auditing representatives cannot complete their review, alternative responsibilities must be identified and assigned. In this situation, areas and representatives with minimal project contact that can provide a credible third party evaluation should be selected.

Activities to be Performed

The project post-mortem includes:

• Implement the system
• Evaluate the systems development process
• Assess operational effectiveness
• Review Cost Benefit Analysis
• Prepare the Post Implementation Review Report
• Review current project plan effectiveness

3.8.1 Implement the System.

A Pilot Operation is a limited implementation of a new system. It is only necessary for large complex systems as a prelude to full operational use of the system. Once User IS and Operations approval have been obtained, a Pilot Operation or a new system can be initiated. (See Management Reporting).

The objectives are to:

• Verify that the system operates according to specifications and achieves the User's objectives
• Verify that the system can run in an operational environment
• Demonstrate that system controls and audit trails are workable
• Shakedown the User Manual
• Demonstrate that all aspects of the system requiring User interface such as data entry and report requests operate correctly

The implementation of the system marks a transition from limited User involvement in the Systems Test to User responsibility for the system.

The Systems Test has verified that the system can perform all of its designed functions under test conditions. The implementation demonstrates that the system can meet User requirements and operate within the constraints of hardware and software when subjected to live data and normal volumes.

The technical staff members of the project should assist the User in preparing for implementation. However, the User staff must take the lead in controlling the flow of data into and out of the system.

Errors encountered during implementation are recorded in the test log initiated in the Systems Test by the Systems Test Coordinator, which will be used to evaluate the quality and reliability of the system.

As this activity is concluded, system deletion procedures must be initiated. The project team must identify the resources that will be displaced once the new system becomes fully operational:

• Identify each library type (i.e., production, test); the member names and the approximate scratch dates.
• Identify each terminal type, location and approximate release data.
• Identify each program name, type (i.e., source, load) and approximate delete date.
• Identify any tape drives, TP lines, printers, TP lines, printers, TP monitor table entries, data base and proprietary software used as part of the old system and the approximate date not required.
• Identify each type of documentation (i.e., operations, system, User) and the approximate destroy date. Include, as appropriate, run books, procedures and forms
• Identify each data file (i.e., tape, DASD, etc.) not required for legal or historical purposes and the approximate scratch date. Note number of generations as appropriate
• Identify each PROC or JCL run deck and the approximate elimination date
• Describe, as appropriate, additional needs to support the fully operational system or to assist in dismantling the replaced system. For example: Uncataloguing of tape files; freezing master files for legal reasons; deleting generation indexes; deleting operational programs or backing them up on tape

3.8.2 Evaluate Systems Development Process.

The review conducted by the IS Department primarily addresses:

• Project plan vs. actual
• Deliverable product quality
• Adherence to organizational standards
• Estimating guidelines analysis

From an IS perspective, review the Application Proposal, Functional Specifications, Systems Specifications and Project Plan to determine:

• Original project scope and objectives
• Expected development effort and schedule
• Anticipated costs and savings
• Expected benefits
• Control definitions and requirements
• Manual and automated system procedures to be documented
• Training requirements
• Documented modifications concerning the above items

When this has been accomplished, ensure that each project documentation deliverable was actually produced, reviewed, modified as required and has been distributed as specified in the original Project Plan.

Determine that the program code was developed according to standards. This is typically accomplished on a sampling basis if an automated tool is not available. Samples of code for inspection should be selected on an individual basis since personal coding patterns tend to be consistent.

In each case, note any variations from standards and whether each variation was authorized and approved.

3.8.3 Assess Operational Effectiveness.

After the new system has been accepted as operational, Auditing evaluates its operational effectiveness. The Audit function provides an independent review of each area's efforts in the systems development and implementation.

The Audit review addresses:

• Administrative Operations
• Automated Operations
• Systems Development and Maintenance

In discussions with the User, evaluate the administrative operation based upon the installed system, procedures and training to determine:

• Has the system delivered what was expected?
• Have all performance and service criteria been met such as response time, error levels, etc.?
• Is the User Manual adequate? Does it match the installed system?
• Was the training program adequate?
• Are the procedures in the User documentation followed?
• Are controls over the source, input, processing and machine-prepared outputs effective
• Does the workflow allow timely processing of data?
• Are reports distributed and received properly?
• Are the reports used for the purpose designed?

Review the automated operation with Operations personnel to assess:

• Is the operation documentation complete and does it adhere to standards?
• Are processing schedules followed?
• Are input and output "windows" consistently met?
• Has there been any system restart experience? Has the recovery period been within that required? Were back-up procedures adequate?
• Were processing volumes, file statistics and other system load forecasts reasonably accurate?
• Can control procedures be followed? Are they?
• Have there been any “incident/trouble” reports experiences? How many, what type and with what results?

Analyze systems development and maintenance with assigned maintenance personnel to identify:

• What have been the type(s) of maintenance requests received? How many?
• Has there been any "deferred development"? That is, functions originally to be developed and later deferred for maintenance? To what extent?
• Are the system documentation products complete, accurate and according to plan?
• Is the systems documentation useable for maintenance? Are problems easily resolved through its use?
• Are the internal design controls effective?
• Is the 'test bed' including test data, files and results adequate? Has it been maintained?
• Are the programs coded according to standards?
• Is the program code maintainable?

3.8.4 Review Cost Benefit Analysis.

After the new system has stabilized and the actual benefits can be recognized and quantified, the Cost Benefit Analysis should be reviewed.

Interviews with IS and User personnel should be supplemented through direct observation and the review of appropriate system documents.

The product of this effort should be an updated Cost Benefit Analysis where:

• Estimated development costs are replaced by actual costs
• Projected operational costs are replaced by actual costs
• Approximated time estimates are replaced by actual savings
• Expected savings are replaced by actual savings
• Anticipated benefits are replaced by realized benefits

An updated payback calculation based upon this information should produce a revised payback period as well as revenue projections relative to the original Cost Benefit Analysis (see Feasibility).

Care should be exercised throughout this process to:

• Identify and account for amendments made to the original Cost Benefit Analysis
• Reflect the impact of inflation on the stated amounts
• Identify the source(s) of the information gathered and projected

3.8.5 Prepare Post Implementation Review Report.

The Post Implementation Review Report should be carefully prepared and assembled to reflect an independent assessment and third party viewpoint.

The causes of any deficiencies found form the basis for recommendations to achieve original system expectations. Generic conclusions, developed from any area of the review, must be identified for management evaluation. Specific recommendations are prioritized and scheduled into a Plan of Action supported by associated resource requirements and cost factors.

The intent and overall tone of the report should be constructive and aimed at identifying improvements in the systems development process.

Each of the individual component audits prepared earlier in the project post-mortem should be reviewed for trends, common themes, findings and conclusions such as:

• System requirements vs. achievements
• Benefits anticipated vs. realized
• Costs estimated vs. actual
• Productivity gains vs. planned
• Adequacy of documentation and procedures
• Departures from approved plan and procedures

As applicable, recommendations should be prepared, based upon project experience that highlight or offer:

• Trends in estimating to improve the estimating process

This would identify potential modifications to the workday and elapsed time considerations by project phase, as well as identify unusual planning roadblocks encountered.

• Suggested modifications to defined documentation deliverables
• Possible improvements to the project planning, process, controls and procedures
• Additional staff training requirements

3.8.6 Review Current Project Plan Effectiveness.

Depending upon the overall time frame in which the phase is completed, this activity may occasionally be conducted in advance of the Post Implementation Review in order to provide early input for subsequent projects.

The primary focus of this activity is to summarize actual project expenditures through the Implementation Phase. As part of this effort, identify any unforeseen obstacles that may have occurred throughout the project. Account for discrepancies between the estimated and actual project costs and schedule.

As appropriate, after completion of the current project plan, review the next project plan to determine whether any revisions are necessary.

Products of the project post-mortem

1. Post Implementation Review Report(s)

DESCRIPTION

Each of the three areas of emphasis is incorporated into an overall report.

The Systems Development evaluation describes how the project performed against plan for schedule, cost and personnel utilization. Project performance measures are developed as part of this effort.

The Operational Effectiveness of the system includes the adequacy of documentation and procedures.

The Cost Benefit Analysis summarizes actual vs. original/revised estimates and describes realized benefits vs. those anticipated at project inception.

PURPOSE

• To conduct an independent and definitive evaluation of the installed system.
• To provide a clear direction to assure User satisfaction with the system.

CONTENT

The Post Implementation Review Report(s) may vary in structure and detail depending upon scope of the review, size and complexity of the system and the extent of recommendations.

• Management Summary
• Introduction
• Objectives and Scope
• Methods of Evaluation
• Brief Description of System
• Findings and Conclusions
• System Performance
• Operational Costs and Considerations
• Areas of Improvement
• Recommendations
• Modifications
• Process Improvements
• Action Plan
• Tasks/Resources
• Schedule
• Costs
• Components Audit
• Systems Development Process
• Operational Effectiveness
• Cost Benefit Analysis

2. Final Project Plan (as appropriate)

DESCRIPTION

Actual workdays and elapsed time expended for the entire project are finalized and recorded. Original plan estimates are not modified.

PURPOSE

• To evaluate the impact on the overall project budget and target completion dates.
• To indicate modifications, as necessary, to other dependent project efforts. To provide input to improve the project planning process.

CONTENTS

See Management Reporting.

Review Mechanisms and Checkpoints

Ongoing reviews are conducted throughout this phase. The various participating group members attend them with the Systems Manager, whenever appropriate. The Systems Manager refers to problems requiring specialized expertise or management support to the appropriate group.

In addition, the following products must be reviewed in a presentation to management:

• Post Implementation Review Report
• Final Project Plan (as appropriate)

Interdepartmental Interfaces

• User Department(s)
• Steering Committee
• Auditing

1. User Department(s)

Upon successful completion of the Acceptance Testing, the User Manager will be required to provide written approval of the operational status of the system. (See Management Reporting).

The User Manager will participate in the post implementation evaluation of the system. This evaluation will, in part, determine if the system has met its objectives and the extent to which the User departments are satisfied with its performance.

If the Application Proposal called for a multi-project solution, then the User Manager will at this time request funds for the next project.

2. Steering Committee

If the Steering Committee decides to fund the next project of the Application Proposal, the Steering Committee will communicate the decision to the User Manager.

3. Auditing

The auditing specialist assigned to the project will participate in review meetings conducted throughout the phase. In particular, the auditor will conduct the Post Implementation Review and prepare the associated report.

THANK YOU!
Contact us today @

[email protected]

Tronmaster, LLC