M95494-MR21-001_TDM_RFI_DRAFT PWS 10142020.pdf

M95494-MR21-001_TDM_RFI_DRAFT PWS

UNCLASSIFIED

TECHNICAL DATA MANAGEMENT (TDM)-CATALYST 1

DRAFT PERFORMANCE WORK STATEMENT (PWS) 2

October 14, 2020 3

1 Background 5

The Deputy Commandant of the Marine Corps for Logistics and Installations (DC I&L) is 6 pursuing overall transformation of the Logistics Information Technology (IT) portfolio. The 7 intent is twofold: 1) adopt dynamic, scalable solutions that will retire antiquated, rigid IT and 8 introduce adaptive, portable IT-supported capabilities and 2) leverage streamlined IT acquisition 9 processes to demonstrate how to reduce time-to-fielding. This strategy addresses elemental 10 dependencies first to pave the way for rapid reengineering and re-platforming of logistics core 11 enablers. 12

A TDM-CATALYST porotype was previously developed and fielded. TDM-CATALYST is 13 now entering continuous pipeline development providing for operational support and release 14 management. The Government anticipates future capabilities will be added as a result of this 15 work. 16

2 Scope 17

The scope of this work is for the Contractor to deliver requested capabilities through Agile teams 18 utilizing the SAFe-like method. The maintenance of all capability teams must be met in order to 19 fulfill the objectives of this contract and may be refined adaptively over the course of the effort 20 to continuously meet specified user needs. User needs will be prioritized based on business value 21 and technical dependencies in TDM-CATALYST by the Government. 22

3 Program Approach 23

The TDM-CATALYST team uses a Scaled Agile Framework (SAFe)-like Software 24 Development Lifecycle approach where the Contractor and Government product and 25 development teams are part of an agile-at-scale environment. The Government anticipates 26 utilizing multiple development teams to support this effort. The teams are organized to support 27 release management at the program level and the development of capability at the project level 28 through Agile Development Teams. Refer to the Notional SAFe Organizational Structure 29 (Attachment 1) for additional information. 30

The Government lead at the Program Level is the Product Management team lead. The Product 31 Management team lead is the senior capability engineer, responsible for technical aspects of the 32 TDM-CATALYST capability, and coordinates and approves capability releases. The Contractor 33 provides the release management team to support the Product Management team lead. 34

UNCLASSIFIED

The Government lead at the development team level is the Product Owner (PO). The PO is the 1 member of an Agile team who serves as the Customer proxy responsible for working with 2 Product Management and other stakeholders, including other POs, to define and prioritize stories 3 in the team backlog, approve sprint development, and evaluates completed work based on end of 4 sprint demonstrations and acceptance testing. 5

The Product Management team, Release Management team, and the individual POs report 6 progress on defined objectives, deliverables, and quality to the Contract Officer Representative 7 (COR) for contract management purposes. The COR is a Business Owner on the Program Level 8 who works with and for the Contract Officer to resolve discrepancies or make modifications to 9 the contract. 10

TDM-CATALYST utilizes JIRA and Confluence for program and Product Management. The 11 Defense Intelligence Information Enterprise (DI2E) hosts these tools. The Government will 12 provide access. 13

4 Technical Landscape 14

TDM-CATALYST is a cloud-based solution hosted by the Marine Corps Business Support 15 Services (MCBOSS) Amazon Web Services Government Cloud environment. The MCBOSS 16 environment team provides the Secure Cloud Computing Architecture as required by the most 17 current Defense Information Systems Agency Cloud Computing Security Requirements Guide 18 (CC SRG) as a service for tenant applications, systems, and workloads. The TDM-CATALYST 19 team works with the MCBOSS team to coordinate program requirements, but the TDM-20 CATALYST team is not responsible for the underlying cloud infrastructure. 21

The TDM-CATALYST solution utilizes the Appian low-code automation platform supported by 22 Mark Logic NoSQL database. These technologies are provided by MCBOSS as Platform-as-a-23 Service offerings. The TDM CATLYST team is responsible for the application and database 24 configurations developed on these platforms but not the patching, upgrading, and other 25 maintenance activities of the platforms themselves. 26

MCBOSS also provides a DevSecOps tool chain as a service which the TDM-CATALYST team 27 utilizes for a Continuous Integration/Continuous Deployment pipeline. TDM-CATALYST 28 utilizes three separate environments for development, stage/test, and production. 29

The Contractor shall be proficient in the languages and tools identified in the Technology 30 Landscape (Architecture) document (Attachment 2). As technology evolves, so must the 31 technical expertise and the tools used by the team. Attachment 2 provides the primary tools (not 32 all-inclusive) that are provided by the Government and are used to support TDM-CATALYST 33 capabilities. The description of each application further identifies the tools used to allow the 34 Contractor to identify the skillsets required. 35

UNCLASSIFIED

5 Performance Objectives 1

5.1 Program and Project Management 2

5.1.1 The Contractor shall provide the program and project management and contract 3 administration necessary to support all tasks/sub-tasks described in this PWS. 4

5.1.2 This task shall be required during the entire period of performance. 5

5.2 Communication and Coordination 6

5.2.1 Applications/activities outside of the TDM-CATALYST program are within the 7 scope of the contract if those applications/activities influence tasks related to TDM-8 CATALYST. An example would be an infrastructure modification implemented by 9 the hosting environment (MCBOSS) in which applications hosted on the 10 infrastructure (i.e. TDM-CATALYST) are impacted but responsibility for the 11 infrastructure resides outside of this PWS. In this case, the Contractor would be 12 responsible for the communication, coordination and tracking activities associated 13 with these changes. 14

5.2.2 The Contractor shall interface with both internal and external teams (Government and 15 other Contractor) to effectively manage, track, and report on TDM-CATALYST. The 16 Contractor shall work with the Government project management team to effectively 17 track and manage all activities. The Contractor staff shall utilize best practices as 18 documented in the 2017 Scrum Guide. 19

5.2.3 The RMT shall support unscheduled data requests related to program. Examples of 20 data requests include IT inventory requests, cybersecurity requests, vulnerability 21 reports, and Plan of Action and Milestones. Though the work to complete these 22 activities may be associated with other tasks, it is the responsibility of the project 23 management function to actively monitor, record, and report on these requests until 24 completion. 25

5.2.4 The Contractor shall ensure the agile delivery teams include a Scrum Master for each 26 Agile Development Team and a Release Train Engineer/Agile Coach (RTE) for each 27 Release Management Team. A Scrum Master or the RTE may serve in one or more 28 roles besides that of the Scrum Master/RTE (e.g., as a project or Program Manager). 29

5.3 Metrics 30

The Contractor shall propose performance metrics that provide visibility into the health of TDM-31 CATALYST on a continuous basis. Metrics shall be automated using the tools provided by the 32 Government or the hosting environment unless otherwise approved by the Government. The 33

UNCLASSIFIED

Government will also require metrics measuring the efficiency of the Agile processes. The 1 Contractor shall: 2

a. Present metrics in a dashboard or dashboard like manner. 3

b. Provide metrics to cover both the health of the program and the performance of 4 the SAFe-like Agile development teams and the Release Management team. 5

c. Keep the proposed metrics to the minimum required to provide effective program 6 management and may change over time as required. 7

d. Develop at a minimum the following metrics/reports for each team: 8

i. Release burnup 9

ii. Sprint burndown 10

iii. Planned vs accepted story points 11

iv. Escaped defects 12

v. Velocity. 13

5.4 Meeting Support 14

5.4.1 At the request of the Government, the Contractor shall provide support for all 15 meetings related to tasks within this PWS. This support excludes the team-specific 16 Agile/Scrum meetings which will be facilitated and run at the team level. The 17 Contractor shall be responsible for the following activities: 18

a. Creating, modifying, and distributing the agenda and presentation materials for a 19 meeting at least 24 hours prior to the meeting; 20

b. Scheduling, facilitation, and coordination of meetings upon request; 21

c. Creating, tracking, and distributing meeting minutes/action item(s); 22

d. Providing meeting minutes within two (2) business days after the meeting; 23

e. and Tracking and managing all action items to closure. 24

UNCLASSIFIED

5.4.2 The Contractor Program Manager may be required to meet at least weekly with the 1 COR during the first month of the performance period. Meetings will be as often as 2 necessary thereafter as determined by the COR. However, if the Contractor PM 3 requests, a meeting will be held whenever a Contract Discrepancy Report is issued. 4 The written minutes of all performance evaluation meetings will be prepared by the 5 Government and shall be signed by the Program Manager and COR, and provided to 6 the Contracting Officer. Should the Contractor non-concur with the minutes the 7 Contractor shall so state any areas of non-concurrence in writing to the Contracting 8 Officer within seven workdays of receipt of the signed minutes. The minutes will be 9 included in the contract file. 10

5.5 Reliability, Availability, Operations, and Sustainment 11

5.5.1 The Contractor shall be accountable for maintaining the uptime and performance of 12 TDM- CATALYST in accordance with MCBOSS SLA by: 13

a. Providing troubleshooting and solutions and for escalated issues that involve 14 TDM-CATALYST technical components and the affected users. 15

b. Develop and/or using troubleshooting, monitoring, and reporting tools to analyze 16 the root cause of serious and impactful technical issues. 17

c. Working closely with Customer care, MCBOSS escalation teams, the Product 18 Management team, and the systems engineering/architecture team to seek 19 solutions for customers and drive tasks toward completion. 20

d. Driving and improving the whole lifecycle of operational readiness – from 21 inception and design through release, operation, and refinement 22

e. Developing tools, operational improvements, and automated solutions that enable 23 self-service configuration changes, speed deployments, and improve monitoring 24

f. Assisting the SAFE-like Agile Development team(s) to ensure accurate 25 monitoring and metrics are built in before deployment to production 26

g. Coordinating with MCBOSS team (hosting environment) to manage periodic 27 environmental changes that impact the TDM-CATALYST technology landscape 28

UNCLASSIFIED

5.6 Obsolescence Management 1

5.6.1 The Contractor shall ensure all Cybersecurity regulations and policies are adhered to 2 and only supported software are used and to support TDM-CATALYST portfolio 3

5.6.2 The Contractor shall ensure that all software items are always maintained with 4 commercial software assurance. 5

5.6.3 The Contractor shall deliver an annual software upgrade plan that identifies End of 6 Life/End of Support timelines for each software item and maps out any future 7 software options that could improve the cost and performance of the portfolio. The 8 software upgrade plan shall cover a 5 year period from the date it is delivered to the 9 Government. 10

5.7 Agile Development Teams (ADTs) 11

ADTs will be utilized to complete system backlog items (stories). A story represents any unit of 12 measurable work that provides value to the Program Office and will serve as a deliverable. ADTs 13 shall work on any system backlog where the stories require the use of the Technical Landscape 14 defined in Attachment 2 or an evolution of that Technical Landscape. The Government will 15 require, at a minimum, two (2) eight member ADTs for the duration of the period of performance 16 but may exercise optional ADTs as required. No optional team will be required for less than 6-17 months. 18

5.7.1 ADTs shall ensure complete transparency and are responsible for logging all 19 activities in the DI2E JIRA and Confluence toolset and shall be kept current within 1-20 business day. 21

5.7.2 ADTs shall adhere to Scrum best practices and perform all Scrum Events and 22 Artifacts in accordance with the 2017 Scrum Guide. 23

5.7.3 The ADTs shall update the Product Roadmap at the end of each sprint or as directed 24 to show significant deviations that affect future sprint cycles. 25

5.7.4 In collaboration with the Government Product Owner (PO), the team shall develop 26 stories and propose solutions with the requisite information to complete all work. The 27 Contractor shall adhere to the following story requirements: 28

a. No story can be started by a team until approved by the PO and contain 29 acceptance criteria and a definition of done. 30

b. Story approval occurs at the sprint planning event and shall be documented in 31

JIRA. 32

UNCLASSIFIED

c. Story acceptance occurs at the sprint review event and shall be documented in 1 JIRA and Confluence. At the sprint review the delivered user stories shall be 2 compared against the definition of done and acceptance criteria defined at sprint 3 planning to determine the quality of the deliverable (story). The story must meet 4 all requirement defined in the sprint definition of done and story acceptance 5 criteria to be accepted. 6

d. All teams shall coordinate all activities required to complete each story as defined 7 in Acceptance Criteria and Definition of Done. 8

5.7.5 An ADT will focus primarily on user stories that provide a specific feature or enabler 9 but, may be redirected to provide reprioritized functional features as required by the 10 Government. 11

5.7.6 Each ADT shall consist of eight (8) dedicated members and meet the following 12 requirements: 13

a. All members shall provide a minimum of two (2) core skillsets; (e.g. one team 14 member could be both a developer and a tester.) There is no maximum number of 15 skillsets that a team member may possess 16

b. All teams shall include one (1) Senior Software Developer, one (1) Senior 17 NoSQL Database Engineer, and one (1) Mid-level Business Analyst. 18

c. The Business Analyst shall perform formal modeling of business processes using 19 Business Process Modeling Notation (BPMN) and to produce products and 20 metrics demonstrating value in-process improvements. 21

d. All teams shall have the necessary skillsets to provide the full range of 22 System/Software Development Lifecycle activities to include requirements, 23 analysis, design, development, test, security, and deployment at all times 24

5.8 Release Management Team (RMT) 25

5.8.1 The RMT will assist the Program Office in achieving SAFe Agile objectives. This 26 task shall be supported for the entire period of performance. The RMTs shall: 27

a. Use the “develop on cadence; release on demand” principles identified in the 28 SAFe model. 29

b. Provide technical advice to support the Government Product Management and 30 systems engineering/architecture teams in determining what functionality and 31 enablers to include in a release, what user community to release to, and when the 32 release should occur. 33

UNCLASSIFIED

c. Adopt the following types and frequency of releases: 1

i. Emergency. A release to address security issues and incidents affecting access 2 or critical performance of the application; Frequency – as needed and 3 expedited to resolve the incident 4

ii. Iterative. A release that provides continuous improvement of deployed 5 capability; new features that enhance current capability; or routine 6 maintenance of current configurations; Frequency – Medium (~ every 2 (two) 7 to 4 (four) sprint iterations) as supported by Agile Release Train planning and 8 release governance requirements. 9

iii. Major. A release (or releases) that adds a significant capability or major 10 infrastructural change. These releases require either long lead times or 11 significant planning and development. Frequency – Low (few times a year) 12 and usually occur over multiple sprint iterations by a dedicated Agile 13 Development Team or Teams. 14

d. Provide test driven design and coordinate automated scripts as a part of the 15 continuous development pipeline as supported by the MCBOSS provided 16 DevSecOps toolchain. Work with MCBOSS in order to improve the automated 17 testing process and procedures. 18

e. Support the development of the organization’s release governance as required by 19 the Product Development team. 20

f. Communicate release status and schedule to internal and external stakeholders. 21

g. Publish a graphic that depicts incremental and major releases. 22

h. Provide solutions that meet all relevant solution quality and compliance 23 requirements 24

i. Actively participate in Inspect and Adapt functions improving the release process, 25 value stream productivity, and solution quality. 26

j. Coordinate all final release activities. 27

k. Support the Government in configuration management. 28

5.8.2 Training Support 29

The Contractor shall provide training, training materials, and training support as required by 30 the Government. Training support must meet the following requirements: 31

UNCLASSIFIED

a. Deliver training or training support that provides the minimum acceptable level of 1 proficiency or capability required for a system user to accomplish mission 2 objectives. 3

b. Prior to release of a function or enhancement, to any of the applications within the 4 TDM-CATALYST portfolio the Contractor shall determine the impact to the user 5 and impact to the current training material. In cases that an impact to the user is 6 expected the Contractor will develop training products to support the 7 enhancement. 8

c. The Contractor shall develop a training plan for any major release being develop 9 and deployed to the TDM-Catalyst portfolio. The training plan should include: the 10 identification of the user population, the processes that will be changed by the 11 new capability, determine the best methods to train the new capability to include 12 new equipment training and sustainment training, and how the training will be 13 executed to support the new capability’s release. This plan shall be provided to 14 the Government for approval before execution 15

5.8.3 Release Train Engineer 16

The RMT shall have a Release Train Engineer (RTE) who assists the Government Systems 17 Engineering/Architect team and Product Management team in planning, developing and 18 executing ARTs (releases) on the Continuous Delivery Pipeline (CDP). 19

a. The RTE will be responsible for coaching the ADT on the framework; attending 20 Agile ceremonies; supporting the Scrum Master(s) as needed; reporting on Agile 21 process performance; and working with the program leadership to improve SAFe-22 like Agile adoption and performance. 23

b. The RTE shall meet the following minimum experience and skill requirements: 24

i. A minimum of five years’ experience with demonstrated success in this role at 25 multiple organizations; 26

ii. Demonstrated ability to achieve the culture change needed when successfully 27 transitioning to SAFe-like Agile teams; 28

iii. Breadth and depth of experience in the tools and techniques of the SAFe Agile 29 Framework, including a proven track record of continuous improvement in 30 knowledge and implementation of Agile methods; 31

UNCLASSIFIED

iv. Experience guiding program managers using Agile in a large program that 1 includes multiple Agile teams, releases, and projects that operate in parallel 2 (e.g., Scrum of Scrums); 3

v. Knowledge and understanding of how to implement architecture in an Agile 4 environment, how to combine the use of component and feature teams, and 5 how to coordinate multiple teams when managing Agile software 6 development for large-scale enterprise development; 7

vi. And understanding of the constraints and demonstrated ability to apply means 8 and methods to overcome these constraints when implementing Agile in a 9 federal contracting environment. 10

5.8.4 DevSecOps Engineer 11

The RMT shall have a DevSecOps Engineer who is accountable for overseeing the CDP of 12 the working product and meet the following requirements: 13

a. The DevSecOps Engineer shall have demonstrated experience in two of the 14 following areas: software development, configuration control, testing, security, 15 automation, containerization, orchestration, cloud services, or open source 16 technologies, as well as, hands-on experience working with the DevSecOps tools 17 and technologies identified in the Technology Landscape (Architecture) document 18 (Attachment 2). 19

b. The DevSecOps Engineer shall perform the following responsibilities in 20 accordance with the SAFe-like model: 21

i. Assist the Agile Development Teams, Systems Engineering and Architecture 22 Team, and Testing teams in order to implement the set of tools and processes 23 established in the MCBOSS environment for the CDP; 24

ii. Assist the Information Systems Security team to ensure that all tools are 25 compliant with security requirements; 26

iii. Assist the Information Systems Security team to streamline the tools and 27 technical process for Authority to Operate; 28

iv. Assist the Testing Lead in automating testing when requested; 29

v. And Assist the Product Management team to ensure that the CI/CD processes 30 align with all approved operational requirements. 31

UNCLASSIFIED

6 Attachments 1

Attachment 1: Notional SAFe Organizational Structure 2 Attachment 2: Technology Landscape (Architecture) 3

UNCLASSIFIED

Attachment 1: Notional SAFe Organizational Structure 1

UNCLASSIFIED

Attachment 2: Technology Landscape (Architecture) 1

6 Attachments