Scribd
Upload
18 views

MITDP Closeout Guide v1.0

Project Closure

Uploaded by

RajVatsayana
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
18 views

MITDP Closeout Guide v1.0

Project Closure

Uploaded by

RajVatsayana
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

<PROJECT NAME>

MITDP CLOSEOUT TEMPLATE


Version: <V#>
Date: <XX/XX/XXXX>

Prepared by:

Project Manager
Approved by:

Project Sponsor
Approved by:

Agency CIO
Approved by:

Executive Sponsor
Table of Contents

1 PROJECT INFORMATION 4
1.1 Project Information 4
2 PROJECT SUMMARY 4
2.1 Overall System Satisfaction 4
2.2 Current Cost-Benefit Justification 5
2.3 Needed Changes or Enhancements 5
3 OUTPUTS 5
3.1 Usefulness 6
4 SECURITY 6
4.1 Data Protection 6
4.2 Disaster Recovery 6
4.3 Audit Trails 7
4.4 Allowed Access 7
5 MAINTENANCE ACTIVITIES 7
5.1 Activity Summary 7
5.2 Maintenance Review 7
5.3 System Maintenance 8
Revision History

Date Version Description Author

XX/XX/XXXX 0.0 Baseline <First Name,


Last Name>

Template Overview and Instructions:

The MITDP Closeout template is used to assess the effectiveness of the system after it has been in
production for a period of at least six months and ensures all final project information is documented.

The objectives are to determine if the system does what it is designed to do:

● Has the project met all goals and objectives as defined by the project stakeholders?
● Does it support the end user as required in an effective and efficient manner?
● Is the system in a stable operations and maintenance environment?

The review should assess how successful the system is in terms of functionality, performance, and cost
versus benefit, as well as assess the effectiveness of the life-cycle development activities that produced
the system. The review results can be used to strengthen both the system and operations and
maintenance procedures. The report should be provided to both the DoIT EPMO and the agency
stakeholders, which will inform all parties of the system state.

A representative from the functional development group or other member of the major user organization
participates in the review. The system proponent ensures that all documentation and all personnel
needed to participate in the review are accessible. The reviewer and an assigned team collect the
information needed for the MITDP Closeout Review by interviewing end users and their managers,
system administrators and other project personnel.
1 PROJECT INFORMATION

1.1 Project Information


Provide project description and identifying information associated with the project, including the
applicable project control code, project title and acronym (if applicable). Also provide final project
financials and health status information.

Project Information
Project Sponsor
Project Manager
Project Name/Acronym
Agency
Project Objectives Met (Yes/No)

Project Data Planned Actual


Total Appropriation
Total Cost/Spend
Start Date
End Date

Project Health R/Y/G Comments


Overall
Scope
Schedule
Cost
Quality
Resource
Risk

2 PROJECT SUMMARY
Provide a summary of the overall adequacy, acceptance, and completion of the project. Have all
established deliverables been made? Is there confirmation of project completion? Has a review of
all contracts and documents been done? Release/transfer of resources, lessons learned, and
archive of project documentation completed?

2.1 Overall System Satisfaction


State the program strategic goals and which of these goals the project successfully supported as
stated in the project charter. Please include any additional goals and reference the following items:
● The level of user satisfaction
● The strengths of the system, including specific areas of success
● Any irregularities of significant impact
● Frequently used features
● Overall usability, including user interface and response times
● Suggested improvements

2.2 Current Cost-Benefit Justification


Assess if the system is paying for itself. Base the assessment on the anticipated benefits and costs
projected during the planning phase and revised during the subsequent implementation phase of
the systems development life cycle. This section is intended merely to review the costs and
benefits and to provide details of costs and benefits in other sections. Comments should address:

● The extent of the benefits and if they are reported to be less or greater than those
projected in the development analysis and functional requirements report.
● If any difference is permanent or will change over time.
● Is the system cost-justifiable, why, or why not?
● Did the system deliver the anticipated value and how or how not?
● How sustainable is this new system\application?
● Is there an anticipated application lifespan?

2.3 Needed Changes or Enhancements


Gauge the magnitude of effort needed to change or improve the system. Describe the nature and
priority of the suggested changes. Comments should address the following:

● The suggested changes and associated scope of the changes.


● The cost of the changes.
● The resource requirements to affect the changes.

2.4 Lessons Learned


Document lessons learned to gain knowledge of what were the positive and negative outcomes
from executing the project. Determine what information will increase effectiveness and efficiency
moving forward. Below are sample questions that can be used:

● Were requirements captured clear and effective?


● Did the communication process provide a clear understanding of what would take place?
● Was there a detailed analysis of the legacy system rather than relying on documentation?
● Was the development methodology followed?
● Did the methodology provide valuable and actionable information during the process?
● Was there a process defined and followed for defect resolution?
● Were needs and support established with the operations and maintenance/dev/op teams?
● What about the project could/should have been done differently?
● What was executed well?

3 OUTPUTS
Please evaluate the adequacy and usefulness of the outputs from the new system. Care must be
taken to ensure that all reports are evaluated and that they cite the original intended output and
variances from the new system.

3.1 Usefulness
Provide information on how useful the new system and/or its output is to the end users. Provide
responses in the following areas:

● Do the users feel the system is easy to use?


● Usage prediction: How much do users expect to use the system?
● Perceived value: Is there a sense that the system adds value to operation?
● Is the system considered essential?
● Is the system considered important and highly desirable?
● Is the system incomplete - does not provide all the necessary information?
● Is the system considered unnecessary?

3.2 Timeliness
Determine if output production performance meets user needs. Comments should address the
frequency with which output arrives on time, early, and late; and the amount of follow-up needed to
obtain the output. Previous results - if available - should substantiate new system improvements in
delivering output to meet user’s needs.

3.3 Data Quality


Assess the need to provide for effective use of shared data to enhance performance and system
interoperability. Comments should address data accuracy and data reliability.
Comments should address data accuracy and data reliability. For example:
● Test results
● Confirm database conversion accuracy.

4 SECURITY
Please detail the adequacy of system security of data and programs and meet the standards in the DoIT
security policy. In addition to access security, procedures for backup, recovery, and restart should be
reviewed. Please also provide any information as it relates to security assessments performed.

4.1 Data Protection


Determine if the security, backup, recovery, and restart capabilities adequately safeguard data,
including master, transaction, and source. Online systems naturally require special techniques
(such as transaction logging). Comments should address the following:

● The adequacy of the security, backup, recovery, and restart procedures


● The suggested changes
● The effort required to make the changes

4.2 Disaster Recovery


Determine if appropriate files, programs, and procedures are established to enable recovery from a
disaster resulting in the loss of data. Comments should address the following:

● The adequacy and currency of off-site storage procedures


● The extent that procedures cover the following:
o Master data
o Transaction data
o Source programs
o Object programs
o The results of any adequacy-of-recovery test

4.3 Audit Trails


Review the ability to trace transactions or history. Comments should address the following:

● The thoroughness of the audit trails


● The level of improvements necessary if any
● The requirements of audit trails as outlined in the trusted criteria - if any

4.4 Allowed Access


Evaluate the adherence to restriction of access to data. State desired privacy criteria for the system
then evaluate how the criteria have been followed up to this point. Comments should address:

● Established privacy criteria


● Recommended privacy criteria
● Adherence to and violations of privacy
● The cost of providing this level of privacy
● The potential effect on individuals if the privacy criteria are not followed.

4.5 Security Compliance


Review compliance and alignment with the DoIT Security Policy and supporting State security
requirements. Provide test results of penetration/server scans or other testing performed.

5 MAINTENANCE ACTIVITIES
The purpose of this section is to ensure responsibility for maintenance is assigned and to evaluate
maintenance activity involving the system.
5.1 Activity Summary
Provide a summary of maintenance activity to date and planned cadence. Provide type, number of
actions, and scope changes required. Estimate a projected maintenance workload based on the
findings of the review. Discuss the adequacy of maintenance efforts or if major
enhancement/revision is required.

5.2 Maintenance Review


Review completed and pending changes to the system. Provide conclusions regarding the benefits
of completing recommended changes. Provide conclusions about the amount of maintenance
required based on activity that has occurred to date.

5.3 System Maintenance


Identification of the structure in which an agency or department that will be supporting operations
and maintenance activities for this new system. Provide documentation or agreement(s) in place to
conduct system maintenance and how these activities will be performed, managed, and funded.
Discuss the system maintenance based on the design, types of changes required, documentation,
and knowledge about the system (both user and technical personnel).

You might also like