Attachment J6 - Library PMLC and SDLC.pdf

4/5/22, 4:04 PM LCD 5-310.1 – Project Management Life Cycle (PMLC) | LC Rules and Regulations https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-1/ 1/7

LCD 5-310.1

Project Management Life Cycle (PMLC)

1. Purpose

2. Roles and Responsibilities

3. PMLC Overview

4. Additional Required Guidance Notes

1. Purpose

This directive provides guidance on Project Management Life Cycle (PMLC) to effectively manage and deliver IT projects at the Library. Refer to LCR 5-310 for definitions of terms used in this directive.

2. Roles and Responsibilities

IT Investment Owner: Identifies the need for the project and confirms the scope and resources required for the project are covered by the investment.

IT Project Management Office (IT PMO): IT Project Management Office is authorized by LCR 5-310 to issue the mandatory requirements of the PMLC. To this end, the IT PMO maintains the PMLC Directives and additional PMLC guidance and ensures that the PMLC process is followed by monitoring and/or managing all IT projects Library-wide.

IT Project Management Officer: Reviews and approves PMLC deliverables, collects and analyses project status reports, and serves as a broker to resolve escalated project issues.

OCIO Tower Owners: OCIO manager(s) whose technical resources, including personnel and non-personnel resources, are utilized to enable the project.

Project Change Control Board (PCCB): Approves project including original project scope, schedule and resources and any baseline changes to the project during execution. Project CCB Members generally include the CIO, Deputy CIO, Project Management Officer, OCIO Tower Owners, IT Investment Owner, Project Sponsor, and Project Owner.

Project Cost Estimation Lead: Creates initial project baseline/high level estimation (scope, schedule, and cost). Represents the Project Manager, where appropriate.

Project Management Team (PM Team): The PM Team consists of two or more individuals whose joint responsibility is to conduct all project management activities, including scheduling, communications management, issue management, cost estimation, risk management, and change management. The PM team includes the primary Project Manager along with a separate Scheduler, Risk Manager, Risk Management Team and/or Project Cost Estimation Lead as needed.

Project Manager: Responsible for planning and overseeing all phases of a project and ensuring all process steps and deliverables are completed as planned. The Project Manager is empowered to provide https://staff.loc.gov/sites/rules-and-regulations/regulation/lcr-5-310/ https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-1/ 2/7 direction and manage the work of the project team. The Project Manager follows the PMLC process and deliverables to help ensure successful completion of the project.

Project Owner: Approves the scope and requirements for the project on behalf of the service unit. The Project Owner typically works closely with the Project Manager during the course of the project and makes day-to-day project decisions.

Project Sponsor: The final decision-maker on the project who secures the resources required for the project (may also be the Investment Owner).

Project Team: The Project Team includes the Project Manager and other technical participants such as architects, engineers, developers, and testers, as well as non-technical participants including business representatives and subject matter experts, all of whom work together to deliver the intended results of the project. Project team members also review and provide input to PMLC deliverables based on their respective subject matter expertise, and contributions to the project.

Risk Management Team: Project team members assigned to periodically evaluate, monitor and mitigate risks for the project. They work under the direction of the Risk Manager.

Risk Manager: Responsible for the project’s Risk Management Plan, its effective implementation throughout the project, trends and metric analysis, and training project personnel on risk management.

The Risk Manager is also responsible for creating and maintaining the Risk Register (or Log), unless this task is delegated to a team member.

Stakeholders: Individuals or groups outside of the Project Team or PCCB who have a general interest in the project, including users/customers, Enterprise Architecture/Architecture Review Board, Web Governance Board, IT Steering Committee, Executive Committee, and the Librarian of Congress.

3. PMLC Overview

Project Management is the application of knowledge, skills, tools and techniques to project activities to ensure projects are executed effectively and efficiently. The Library accomplishes this through the Project Management Life Cycle (PMLC) which is based on the Project Management Institute (PMI) Project Management Book of Knowledge (PMBOK) and Federal government guidance. The PMLC is intended to utilize industry best practices across all IT projects and thereby improve project results.

All Library IT projects must follow the PMLC, and Project Managers are expected to use the PMLC as a guide in managing their projects. Following the PMLC helps to ensure that projects are planned and executed effectively which in turn helps to ensure on time delivery of the desired project outcomes.

Because the PMLC has broad applicability, other more specific methodologies may also be applied to some projects to ensure additional necessary processes and deliverables are produced based on the specific project type. For example, systems development projects should also follow the System Development Life Cycle (SDLC), LCR 5-310.2.

3.1. PMLC Phases. The PMLC consists of four sequential phases as shown in Figure 1 and described below.

Figure 1: Project Management Life Cycle

Each of these phases is described in sections 3.1.1 – 3.1.4 below.

https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-2/ https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-1/ 3/7

3.1.1. Initiation. The purpose of the Initiation Phase is to schedule and formally initiate projects.

This includes verifying linkage to an approved IT investment, refining and documenting project objectives and project cost estimates, identifying and securing required resources, determining project start and end dates, and obtaining approval to proceed. The Initiation phase is complete when a project is approved by the PCCB. See https://staff.loc.gov/resources/display/PMO/Initiation for detailed procedures and templates needed to conduct the Initiation phase.

3.1.2. Planning. Once the Initiation phase is complete, the Project Manager concentrates on planning the project at a lower level of detail. During this phase, the Project Manager assembles the project team, refines project objectives, and plans and communicates the project management approach. The Planning phase is complete when initial planning deliverables have been completed by the Project Manager; however, initial project plans are expected to be updated throughout the project life cycle. See https://staff.loc.gov/resources/display/PMO/Planning for detailed procedures and templates needed to conduct the Planning phase.

3.1.3. Execution and Control. During the Execution and Control phase, the Project Manager coordinates the activities of Project Team to execute the project as planned. The PM identifies potential problems in a timely manner and takes the appropriate corrective actions when necessary. Other methodologies which govern how the project is executed such as the SDLC are typically employed during this phase. The Execution and Control phase ends when the project scope has been met. See https://staff.loc.gov/resources/display/PMO/Execution+and+Control for detailed procedures and templates needed to conduct the Execution and Control phase.

3.1.4. Closeout. The purpose of the Closeout phase is to formally close the project. During this phase, the Project Manager coordinates acceptance of project deliverables, finalizes documentation, works with the Project Team and PCCB to assess project processes and results, and releases project resources. See https://staff.loc.gov/resources/display/PMO/Closeout for detailed procedures and templates needed to conduct the Closeout phase./li>

3.2. PMLC Project Classification. To ensure projects employ an appropriate level of Project Management rigor, the required deliverables for each phase of a project is based on the Project Classification. Project Classification considers the levels of project risk and complexity to determine whether a project is Large, Medium, or Small as described below:

Small Project: Projects with low risk and complexity requiring basic Project Management rigor and the minimally required deliverables only.

Medium Project: Project with medium level of risk and complexity requiring some deliverables beyond minimally required deliverables such as a detailed Project Management Plan.

Large Project: Project with high level of risk or complexity requiring maximum Project Management rigor and several deliverables beyond minimally required deliverables such as a detailed Project Management Plan with Change, Communications, and Risk Management components, and Cost Estimate.

The Project Manager must use the PMO Project Classification Worksheet during the PMLC Initiation phase to determine the project classification. The specific PMLC deliverables that are required based on the project classification are described in Table 1.

https://staff.loc.gov/resources/display/PMO/Initiation https://staff.loc.gov/resources/display/PMO/Planning https://staff.loc.gov/resources/display/PMO/Execution+and+Control https://staff.loc.gov/resources/display/PMO/Closeout https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-1/ 4/7

3.3. PMLC Required Deliverables. Table 1 below shows the deliverables that must be produced during the life cycle of a project, when each deliverable is required, and the applicable roles for each deliverable.

Whether or not a deliverable is required is based on how the project is classified–Large, Medium or Small (see section C3 below). The RACI model [Footnote 1] is used to show which roles are Responsible, Accountable, Consulted, or Informed for each deliverable.

Table 1: PMLC Deliverables and Roles Phase Deliverable(s) Purpose When

Required

RACI

PM /

PM

Team

PCCB OCIO

Tower Owners

Project Team

Stakeholders

Initiation Project Charter Obtain and document approval to initiate project – formally authorizes the existence of a project and provides the PM with the authority to apply organizational resources to project activities

Large, Medium and Small projects

R A C I I

Project Classification

Classify project size for the purpose of determining the level of project management rigor and PM deliverables to be produced

Large, Medium and Small projects

R I C – –

Cost Estimating Spreadsheet

Determine specific project costs categorized by types of IT expenditures

Large projects

R I C – –

Cost Estimating Document

Describes the process and assumptions

Large projects

R I C – –

Planning Project Schedule

Serves as the primary planning

Large, Medium

R I C C I https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-1/ 5/7 calendar and schedule baseline for the project. It includes both PM and technical tasks and subtasks needed to complete the project and Small projects

Project Management Plan

Defines how the project is to be executed, monitored, and controlled including assumptions, constraints, dependencies, stakeholders, milestones, and development methodology (e.g., agile or waterfall) if applicable

Medium and Large projects

R I C I –

Execution and Control

Status Report Provides a project update format to be submitted to the Library’s IT Project Management Office

Large, Medium and Small projects

R C I C I

Risk Register Provides a record of risks, with assessment of impact and probability, mitigation strategy, contingency plan, and resolution for each risk

Large, Medium and Small projects

R I – C –

Issue Log Provides a record of

Large projects

R I – C –

6/7 issues and resolutions throughout the project life cycle

Change Request

Used to formally document and track project change requests

Large projects

R A – I –

Closeout Closeout Report Serves as a final report to management on the status and results of the project and formally releases project resources.

Large, Medium and Small projects

R C I C –

Lessons Learned

Captures the results of the project team’s lessons learned discussion to be submitted to the Library’s PMO for reference by other project teams

Medium and Large projects

R C I C I

4. Additional Required Guidance

As a supplement to these Directives, the PMO provides additional required guidance needed to apply the PMLC, including process workflow diagrams, step-by-step procedures and associated templates for each PMLC phase and deliverable.

4/5/22, 4:05 PM LCD 5-310.2 – Systems Development Life Cycle (SDLC) | LC Rules and Regulations https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-2/ 1/5

LCD 5-310.2

Systems Development Life Cycle (SDLC)

1. Purpose

2. Roles and Responsibilities

3. SDLC Overview

4. Additional Guidance Notes

1. Purpose

This directive provides guidance on the Systems Development Life Cycle (SDLC) to effectively gather and analyze IT system requirements, and design, develop, test, and implement a new or enhanced Information Technology (IT) system into the production environment. The SDLC also describes the steps necessary to maintain the IT system and retire it once the IT system is to be decommissioned.

The process outlined in this directive lists the minimum set of activities that need to be performed for IT systems development across the Library, regardless of the development methodology and IT system size/complexity. Additional SDLC guidance specific to development methodology (Waterfall, Agile, or Hybrid) should be followed as appropriate for the IT system development.

Refer to LCR 5-310 for definitions of terms used in this directive.

2. Roles and Responsibilities

2.1. Technical Team. The technical team works together to develop, enhance and maintain an IT system and is expected to produce or provide input to all SDLC deliverables. The technical team consists of (but is not limited to) the following roles: User Experience Designer, Business Analyst, Technical Lead, Solutions Architect, Systems Engineer, Network Engineer, Data Modelers/Database Administrators, Quality Assurance/Testing Lead, Developers and Testers (Accessibility, Usability, Performance, and/or Quality).

2.2. IT Project Management Office (PMO). The IT PMO defines the Project Management Lifecycle (PMLC) process. The PMLC is required for IT development efforts which are classified as a project due to the size and complexity of the work involved (see https://staff.loc.gov/wikis/display/PMO/Project+Classification+and+Deliverables for more information). The PMLC is intended to be followed in tandem with the SDLC. The PMLC describes the processes and deliverables to be produced at the Project Management level while the SDLC describes the technical processes and deliverables necessary to develop and maintain the IT system.

2.3. IT Design and Development Office (ITD&D). ITD&D is responsible for defining and maintaining the SDLC processes and activities that are required for IT system design and development. ITD&D also ensures that specific SDLC methodologies (i.e., Waterfall SDLC, Agile SDLC and Hybrid) are https://staff.loc.gov/sites/rules-and-regulations/regulation/lcr-5-310/ https://staff.loc.gov/wikis/display/PMO/Project+Classification+and+Deliverables https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-2/ 2/5 being followed and align with the overall SDLC process. See section 3.2, SDLC Development Methodologies, below.

3. SDLC Overview

The SDLC is composed of clearly defined and distinct work activities, which are used by technical teams to plan for, design, build, test, maintain, and deliver IT systems. The SDLC aims to produce high-quality IT systems that meet or exceed customer expectations, based on customer requirements, by delivering IT systems within scheduled time frames, cost estimates, and project scope.

3.1. SDLC Activities. The SDLC consists of seven mandatory activities as defined below, in which multiple roles can be engaged. The specific approach and deliverables of these activities differ depending on which SDLC methodology is being used (see section 3.2). Refer to the detailed methodology documentation when determining required activities and deliverables.

Requirements and Analysis: The purpose of the Requirements and Analysis is to gather, define, and analyze business, user, functional, IT security and accessibility requirements and initiate detailed IT system design planning.

Design: The purpose of the Design activity is to transform detailed requirements into IT system design specifications.

Development: During the Development phase, the technical team converts the design into a functional IT system.

Testing: The purpose of Testing is to validate whether the developed IT system meets the system requirements, IT security and technical standards, is compatible with the production environment, and is ready to be deployed.

Implementation: During the Implementation phase, the IT system is deployed to the production environment for operational use.

Operations and Maintenance: When an IT system is deployed to the production environment, it is then in an Operations and Maintenance (O&M) state. While in O&M, the O&M team performs operations and maintenance of the IT system in the production environment.

Note, IT systems in a Continuous Integration/Continuous Delivery model do not have a dedicated O&M Phase.

Disposition: The purpose of the Disposition phase is to perform end-of-system activities and dispose the IT system.

3.2. SDLC Development Methodologies. When applying the SDLC, the technical team must follow the Agile, Waterfall or Hybrid methodologies. These methodologies have been established as three alternative approaches to fulfilling the mandatory requirements of the SDLC.

The agile suitability scorecard will be used to determine whether Waterfall, Agile or a Hybrid approach is best suited based on the specific conditions of the effort. The methodologies are:

Agile SDLC: The Agile SDLC methodology is an iterative and incremental development approach in which requirements and solutions evolve through iterations and continuous feedback. As a result, SDLC activities are conducted iteratively and often in parallel. Agile development is most appropriate when requirements are evolving, the customer is highly engaged, and multiple minimally viable versions of the product can be released throughout development.

Waterfall SDLC: The Waterfall SDLC methodology is a sequential development approach in which development flows steadily downwards (like a Waterfall) through several phases. This means that any activity in the SDLC begins only after the previous activity in the life cycle is completed. For example, the development of the IT system can only be performed after the https://staff.loc.gov/wikis/download/attachments/17993618/Agile_Suitability_Scorecard.xlsx?api=v2 https://staff.loc.gov/wikis/display/PDSFPMO/Agile+SDLC https://staff.loc.gov/wikis/display/PDSFPMO/Waterfall+SDLC https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-2/ 3/5 system design has been fully completed. Waterfall development is typically appropriate when developing new IT systems with well-defined requirements.

Hybrid SDLC: The hybrid approach combines the Waterfall and Agile SDLC methodologies based on the types of activities entailed in the effort as follows:

Activities that have fixed requirements which must generally be done in discrete, sequential steps that follow a Waterfall approach;

Activities that entail evolving requirements that are better suited to an iterative approach that follow the Agile SDLC.

A common example of a Hybrid approach is to conduct initial infrastructure installation activities using Waterfall, then conduct iterative software development activities using the Agile methodology. However, the Hybrid approach varies depending on which aspects of the effort are determined to be Waterfall versus Agile. Therefore, no single Hybrid methodology is prescribed. When applying the Hybrid approach as part of a project, the Project Management Plan must describe which project activities will be conducted using the Waterfall methodology and which activities will be conducted using the Agile methodology.

3.3. Minimally Required Deliverables. Table 1 below describes the deliverables that must be produced for Library IT systems during each required SDLC activity. These deliverables are required regardless of the specific SDLC development methodology being applied. After the deliverables are initially created (usually when implementing a new system), they must be maintained throughout the life cycle of the IT system. That is, if an IT system is changed, the corresponding deliverables must also be revised accordingly to prevent the documents from becoming outdated or inaccurate.

Creating and maintaining these minimally-required SDLC deliverables ensures that system integrity is maintained throughout the SDLC activities detailed in Section 3.1 and that the IT system remains properly documented through its lifecycle. Deliverables required to support the IT Security Assessment & Authorization process are also noted in Table 1.

Table 1: Minimally Required SDLC Deliverables Activity Deliverable(s) Purpose

Requirements & Analysis

Product Road-map A high level plan for major features, in a timeline

ADA/508 Checklist Provides a checklist of ADA/508 compliance considerations

System Requirements / Backlog

Documents the output of the Requirements Gathering / Analysis activity and serves as the foundation for IT system design and development activities

Design

System Design Document*

Describes the detailed system design specifications

IT Contingency Plan*

Establishes procedures to recover the IT system following a disruption

Systems Administration Manual*

Explains how an application administrator (or other users on behalf of the Information System Business Owner (ISBO)) will control IT system accounts and privileges

Configuration Management Plan*

Describes the configuration management process for the system

Development Working system code

Source and configuration files checked into source repository https://staff.loc.gov/wikis/download/attachments/17993618/Project_Management_Plan_Template.doc?api=v2 https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-2/ 4/5

Testing Test Results & Analysis Report

Provides a summary of the results of tests performed

Implementation

OCIO Service Desk Survival Guide

Provides contact information for the primary contact and project/system owner along with special instructions

Build and deploy scripts

Automated scripts that build and deploy the IT system

Operations & Maintenance

Change Request Form

Used to document changes to the production IT system

Disposition

Disposition Memo Describes the ISBO’s intent to terminate the IT system

Disposition Stakeholder List

Captures stakeholder role(s) and name(s)

Systems Architecture Diagram and Disposition Requirements

Captures System Architecture Design of the IT system to be disposed of and the disposition requirements

Notification Email notification sent to stakeholders before and after executing disposition tasks

Post-Termination Review Report

Details the findings of the Disposition Phase to identify where to find products and documentation that has been archived

*This deliverable is required for the IT Security Assessment & Authorization (A&A) process and not specifically a part of the SDLC requirements.

3.4. IT Security Documentation. All IT systems must follow the IT Security A&A process to identify and meet applicable IT security requirements. All required IT Security Documentation is listed in Table 2.

Table 2: IT Security Documentation Documents Notes

Network Diagram / Data Flow Diagram

Created and uploaded into Archer.

ISBO and ISSO Appointment Memos

Developed from template and uploaded into Archer.

FIPS 199

Developed and retained in Archer. There is no separate document.

Privacy Threshold Assessment/ Privacy Impact Analysis

Developed in Archer. Approved by ISBO and OGC in Archer.

System Security Plan (SSP) Developed in Archer. SSP can be generated from fields in Archer.

IT Contingency Plan (ITCP) / CP Test

Developed from template and uploaded into Archer.

Configuration Management Plan

(CMP)

Developed from template and uploaded into Archer.

Incident Response Plan (IRP) Developed from template. Included as part of the assessment artifacts.

https://staff.loc.gov/sites/security/assessment-and-authorization/ https://staff.loc.gov/sites/rules-and-regulations/regulation/lcd-5-310-2/ 5/5

Information System Continuous Monitoring (ISCM) Plan

Developed from template and uploaded into Archer.

Security Assessment Report (SAR) Developed in Archer. SAR can be generated from fields in Archer.

Plan of Action and Milestones

(POAM)

Developed in Archer. POAMs can be generated from fields in Archer.

ATO Memos Developed from template and uploaded into Archer.

The following are part of the PMO’s SDLC process – Concept of Operations

Requirements Documents

System Administration Manual

(SAM)

Design Document

Developed from template and uploaded into Archer or included as part of the assessment artifacts

4. Additional Guidance

As a supplement to this directive, ITD&D provides additional guidance on whether to follow the Agile, Waterfall or Hybrid methodology. This guidance is based on characteristics of the development effort including: stability of requirements, characteristics of the stakeholders of the effort such as customer availability, and characteristics of the technical team composition (full time vs part time). In general, SDLC efforts are expected to default to Agile SDLC, unless Waterfall is determined to be more suitable based on the specific characteristics of the effort.