Technology Solution Life Cycle (TSLC) Policy
Policy Owner: Manager, Business Relationship Management
Note: An owner must be a PCES-level manager.
This policy provides formally documented management expectations and intentions.
The purpose of this document is to provide the policy for the Technology Solution Life Cycle (TSLC). The TSLC is the Corporate Technology project methodology to be used to develop and implement technology solutions. The TSLC is a key component used by IT Governance to measure compliance to IT policies, processes, standards, and controls.
This document also outlines the elements of the Tollgate process for TSLC. The Tollgate process includes a series of Stakeholder coordination meetings that require Stakeholder consensus and approval to proceed to the next TSLC phase. Stakeholders for a given technology solution may choose to use the Tollgate process to increase visibility into the scope and progress of the release. Solutions that follow the Tollgate process will complete all TSLC requirements and, in addition, must hold a total of five meetings at various points in the TSLC process. These meetings are the Business Needs Statement (BNS), Baseline (Requirements), Design, Release, and Closeout Tollgates.
This policy applies to all:
Postal Service employees and contracted personnel involved in TSLC activities.
Postal Service technology solutions that require a production change to software code, data, or job or batch schedule processing. These include, but are not limited to:
All technology solutions and their components (hardware/infrastructure, software, database management services, and/or network) as authorized in the approved Requirements
All services (including network, server, and mainframe) to be deployed in the Postal Service Technical Environment
All maintenance releases for services and technology solutions to be operable in the Postal Service Technical Environment; maintenance releases include hardware, software, network, and database management system (DBMS) upgrades
Implementation and/or configuration of Commercial-Off-the-Shelf (COTS) software
Major software version upgrades regardless of App code impact (e.g., Windows 2003 to 2008, Linux 10 to 11, Oracle 11g to 12c, or OREB R11 to R12)
- Other types of technology solutions may be required to follow the TSLC depending on the nature and scope of the change.
All Postal Service technology solutions that require change to production software code, data, or job or batch schedule processing must be developed and implemented with adherence to the TSLC Agile methodology as described in the TSLC Agile Processes. Waterfall methodology, as described in the TSLC Waterfall Processes, may be used only when documented approval is received from both the Manager, Solutions Development and Support, and the Manager, Business Relationship Management. The documented approval must be uploaded to the TSLC Artifacts Library for the project and stored in the Business Needs Statement folder.
All TSLC Events
A project folder must be created in the TSLC Artifacts Library for each TSLC
project implementation. The TSLC project ID generated when the TSLC project is
created must be entered in all changes submitted in support of a TSLC project.
All final TSLC artifacts must be uploaded to the TSLC Artifacts Library prior
to implementing changes to production and/or as stated in specific TSLC
The following policy statements apply to the Change Control Board (CCB) process:
Stakeholders must be listed as Voting Members of the CCB.
Each Stakeholder and all Designees must be identified by name and title within the CCB document. Designees are stand-in representatives for Voting Members.
The Voting Members of the CCB are responsible for performing the Change Control process. This includes the following:
Approving artifacts as described in the CCB Document
Approving all changes (addition, subtraction, or modification) that affect scope, cost, or timeline
Ensuring all related documentation is updated to reflect the change
- “Consensus” means that each Stakeholder has reviewed the functional
impact to his/her area and that there is general agreement that it meets
- Any changes to requirements that affect scope, cost, or timeline made after the initial requirements approval and all the way through release must be approved by all Voting Members of the CCB.
The Tollgate process should be elected when the project involves critical,
multi-stakeholder releases across the organization (i.e., scheduled releases for
PostalOne! or PTS/PTR).
Any Vice President (VP) Stakeholder can elect for a release to follow the
Tollgate process in addition to the TSLC process.
The following policy statements apply to all releases that follow the Tollgate process:
Business Relationship Management Program Manager (BRM PM) responsibilities. The BRM PM must:
Notify the IT SOX CMO that the release has been identified as Tollgate within 10 business days of the first Tollgate meeting.
Create a TSLC project folder. When a TSLC project folder is created for a Tollgate project, the “Tollgate” indicator must be selected so the Tollgate folders for the project are created.
Use the Tollgate tasks in the project plan template.
Track the project in Technology Management Office System (TMOS).
Propose the initial Stakeholders for the CCB.
Ensure that all required and Baseline artifacts are appropriately created and uploaded to the TSLC Artifacts Library in the designated project folder throughout the release. Tollgate artifacts must be stored according to TSLC processes in each of the corresponding Tollgate folders. All required artifacts (inputs and outputs) for a given Tollgate must be uploaded within 10 business days of the corresponding Tollgate meeting.
Note: See the Exception above.
Voting Stakeholder Participation. VP participation in the release is mandatory, including approval in and attendance at Tollgate meetings as described in the following statements and table below.
Each impacted organization must have a VP Stakeholder.
All VP Stakeholders and their Designees must be documented in the CCB Document as voting Stakeholders.
A VP may appoint only a PCES Manager from his/her organization as his/her Designee for all Tollgates that indicate Mandatory attendance as shown in the table below.
All voting Stakeholders or their PCES Designee must attend each Tollgate meeting for the Tollgate to be completed.
Tollgates must be approved by VP Stakeholders as shown in the table below.
All Tollgate approvals are by consensus. If consensus approval is not provided at any of the Tollgate meetings (except the “Implementation” Tollgate), work can move to the next phase while the BRM management escalates the issue to VP Stakeholders in a timely manner to gain consensus approval.
The following Tollgate meetings take place when the release has been identified as one that will follow the Tollgate process.
The Stakeholders are involved in the sprints and approve the sprints.
Stakeholder sprint approvals are uploaded as evidence that changes (additions and/or subtractions) were agreed to by all Stakeholders.
|Tollgate Meeting||Agile Phase||Waterfall Phase||Purpose||Tollgate Approval|
|BNS.||Initiate and Plan.||Initiate and Plan.||Gather and approve all high-level requirements for the release and determine all of the necessary Stakeholders to be included in the Draft CCB for the release.||VP.|
|Baseline.||Sprint 0.||Requirements.||Establish and obtain consensus approval for the baseline of requirements planned to be implemented in the release.||VP.|
|Finalize Release.||Sprint 1-n*.||Analysis and Design.||Review and obtain consensus approval of requirements based on completion of this phase.||VP/PCES Designee.|
|Implementation.||CAT.||CAT.||Review SIT (in case of a failure) and CAT results and final Requirement Traceability Matrices (RTMs) to provide Stakeholder consensus approval to promote the release to production.||VP.|
|Release.||Release.||Determine the overall success of the release, review post-production test results and lessons learned, and assign corrective actions as necessary.||VP/PCES Designee.|
*For Agile “Finalize Release” Tollgate: A formal Tollgate meeting does not need to take place if:
If there is not consensus approval by all Stakeholders, then the formal Tollgate meeting must be held.
All requirements listed and referenced in the Develop and Maintain Secure PCI In-Scope Systems and Applications and in the TSLC processes must be met.
- Develop and Maintain Secure PCI In-Scope Systems and Applications
- SIT – CAT Exemption and Post-Production Review Process
- Secure System Review Process
- System Retirement Process
- Handbook AS-805 Information Security [PDF] [HTML]
- Handbook AS-805A, Information Resource Certification and Accreditation Process [PDF] [HTML]
- Payment Card Industry Data Security Standard (PCI DSS)
Access supporting documentation from ITWEB (Internal):
- TSLC Processes [Agile] [Waterfall]
- TSLC Templates [Agile] [Waterfall]
- Application Development Standards
Access Supporting Documentation from USPS.com (external):
- TSLC Processes
- For access to the following documents, contact the US Postal Service. See
Publication 5, Let's Do Business for further information
about local US Postal Service contacts.
- TSLC Templates
- Application Development Standards
Description of Change
TSLC Deliverables for Priority Urgent implementations now required within 2 business days.
Added System Retirement Process link.
Updated Process Owner to Manager, Solutions Development and Support, to reflect current organization.
Added “and/or as stated in specific TSLC processes” to upload prior to implementing changes to production statement; removed reference to templates as template use is not mandatory.
Updated to include Agile methodology.
|6.0||FY12/Q3||This document was made Section 508 compliant and was converted to HTML.|
|7.0||05.10.2013||Updated for Tollgates, PCI, and general compliance;
ownership of TSLC processes transferred from Manager, Solutions
Development and Support, to Manager, Business Relationship
Updated to clarify that the Requirements must be approved, not the Requirements Traceability Matrix document.
Added “Expedited CRs” to “Critical Incidents” as scenarios where TSLC artifacts may be uploaded up to two business days after implementation into production.
|7.2.1||06.15.2015||The annual review for functional accuracy and current PCI DSS requirements has been completed: No changes. CR 81805|
|7.2.2||06.26.2015||Non-substantive update: Update CR for annual review. Remove link and version of PCI DSS.|
|7.2.3||03.14.2016||Annual Review: No changes. The annual review for functional accuracy and current PCI requirements has been completed. CR 154951|
Scope section: Added major software version upgrades.