metropolitan washington airports authority … · istandard operating procedure, information...

METROPOLITAN WASHINGTON AIRPORTS

AUTHORITY

SUPPLIER DIVERSITY MANAGEMENT SYSTEM

(SDMS)

STATEMENT OF WORK

CONTRACT NUMBER: 1-16-C013

OCTOBER 2015

ii

Contents

1. Purpose and Background ...................................................................... 1-11.1 BACKGROUND ..................................................................................................... 1-11.2 SCOPE OVERVIEW ............................................................................................... 1-21.3 AIRPORTS AUTHORITY REFERENCE MATERIALS AND STANDARDS ............................ 1-4

2. Management and Operations ................................................................ 2-12.1 SUPPORT ORGANIZATIONS ................................................................................... 2-12.2 OPERATIONAL ENVIRONMENT ............................................................................... 2-22.3 TRANSACTIONS ................................................................................................... 2-52.4 USER COMMUNITY ............................................................................................... 2-7

3. System Architecture .............................................................................. 3-13.1 CURRENT SYSTEM ARCHITECTURE ....................................................................... 3-13.2 TARGET ARCHITECTURE ....................................................................................... 3-3

4. Detailed Scope ...................................................................................... 4-14.1 SCOPE SUMMARY ................................................................................................ 4-14.2 DETAILED SCOPE TASKS ...................................................................................... 4-1

4.2.1 SDMS Task 1—Program Management Services ...................................... 4-14.2.2 SDMS Task 2—Requirements Management Services ............................. 4-34.2.3 SDMS Task 3—SaaS Solution Configuration Services ............................ 4-44.2.4 SDMS Task 4—Business Process Redesign Services ............................. 4-54.2.5 SDMS Task 5—Contractor Hosting Services ........................................... 4-64.2.6 SDMS Task 6—Data Cleansing, Migration, Validation, and

Management Services ............................................................................ 4-64.2.7 SDMS Task 7—Interface Development Services ..................................... 4-84.2.8 SDMS Task 8—Testing Services ............................................................. 4-94.2.9 SDMS Task 9—Training Services .......................................................... 4-114.2.10 SDMS Task 10—Full Implementation and Cutover (Go-Live)

Services ................................................................................................ 4-134.2.11 SDMS Task 11—O&M Services ........................................................... 4-154.2.12 Supplemental Services ......................................................................... 4-16

iii

4.2.13 Deliverables Summary .......................................................................... 4-18

5. Performance Standards and SLAs ........................................................ 5-15.1 SLAS ................................................................................................................. 5-1

5.1.1 System Reliability ..................................................................................... 5-15.1.2 Incident Response Time ........................................................................... 5-35.1.3 Incident Resolution Time .......................................................................... 5-45.1.4 Hosting Security ....................................................................................... 5-55.1.5 Disaster Recovery and COOP .................................................................. 5-65.1.6 Elastic Scaling .......................................................................................... 5-75.1.7 Deliverable Quality ................................................................................... 5-7

5.2 SLA MANAGEMENT.............................................................................................. 5-95.2.1 Terms for Nonperformance ....................................................................... 5-95.2.2 Terms of Changes to SLAs ..................................................................... 5-10

Appendix A –Detailed Requirements ....................................................... A-1Appendix B –System Interfaces ............................................................... B-1Appendix C –Target State Process Flows ............................................... C-1Appendix D –Capability Model ................................................................. D-1Appendix E –Initial Service Level Agreements (checklist) ....................... E-1Appendix F –Supplier Diversity Reports ................................................... F-1

FiguresFigure 3-1. Current State Legacy System ............................................................... 3-1

TablesTable 2-1. Goal and Reporting Requirement .......................................................... 2-6Table 2-2. Estimated User Breakdown by User Type ............................................. 2-9Table 4-1. SDMS Detailed Task Summary ............................................................. 4-1Table 4-2. SDMS Contract Deliverables ............................................................... 4-18Table 5-1. Incident Response Time Requirements ................................................. 5-3Table 5-2. Incident Resolution Time Requirements. ............................................... 5-4Table 5-3. SDMS SLA Summary ............................................................................ 5-8

1-1

1. Purpose and Background

This statement of work (SOW) identifies the Metropolitan Washington Airports Authority’s(Airports Authority’s) requirements for the acquisition of a new Supplier Diversity Management System (SDMS) delivered as a software-as-a-service (SaaS) cloud computing solution. The new SDMS will replace the legacy Equal Opportunity Program (EOP) systems.

1.1 BACKGROUND

The Airports Authority is responsible for the management, operation, and capital improvement of two airports in the Washington metropolitan area, Reagan National (DCA) and Washington Dulles International (IAD) Airports. These airports provide domestic and international air service to over 40 million passengers for the mid-Atlantic region. The Airports Authority also manages Virginia’s Dulles Toll Road, extending from Interstate 495 to Dulles Airport, and the project to extend the Washington Metropolitan Area Transit Authority’s Metrorail Silver Line to IAD and Loudoun County. The Airports Authority is led by a 17-member board of directors appointed by the governors of Virginia and Maryland, the mayor of Washington, DC, and the president of the United States.

The Airports Authority has a viable and aggressive supplier diversity program managed by its Department of Supplier Diversity (DSD), formerly known as the Equal Opportunity Programs Department. Its mission is to promote regional economic development and contracting opportu-nities through the maximum utilization of small, local, disadvantaged, minority and women-owned businesses. The aim is to expand and advance the current pool of diverse suppliers through outreach, education, and engagement and to provide contracting opportunities for Local Disadvantaged Business Enterprises (LDBEs), Disadvantaged Business Enterprises (DBEs), Mi-nority Business Enterprises (MBEs), Women Business Enterprises (WBEs), and Airport Conces-sions Disadvantaged Business Enterprises (ACDBEs) for the acquisition of goods and services by the Airports Authority.

To more effectively support its supplier diversity mission, the Airports Authority plans to replace its legacy EOP systems and manual processes and acquire an automated, user-friendly, fully in-tegrated, commercial off-the-shelf (COTS), SaaS cloud-based SDMS. The selected solution will enable the Airports Authority to more effectively manage the supplier diversity program and in-tegrate it with contracting and procurement functions:

Increasing program management efficiency

Expediting the supplier diversity certification process

Improving the monitoring of individual contract supplier diversity goals

Improving efficiency and transparency of the supplier diversity goal-setting process

Purpose and Background

1-2

Improving outreach to the supplier community

Implementing robust reporting and analytics for improved tracking and reporting of sup-plier diversity program performance

Improving stakeholder access to key supplier diversity information for effective decision making.

1.2 SCOPE OVERVIEW

The legacy EOP system consists of two siloed systems:

1. EOP I, an add-on to the Airports Authority’s Oracle Enterprise Resource Planning (ERP) Procurement module

2. EOP II, the supplier diversity certification management database.

It also features manual processes that do not adequately support the management requirements of the supplier diversity program. The system lacks integration, is labor intensive (requiring paper-based processes), promotes duplication of effort, and does not offer or provide robust reporting for tracking and decision making to effectively support supplier diversity functions.

The Airports Authority seeks to replace the legacy EOP systems with a single, fully integrated COTS SaaS supplier diversity solution with three core capabilities and functionality:

1. Certification

2. Compliance and goal setting

3. Outreach.

The new SDMS shall be easily accessible to Airports Authority users and suppliers and shall have scalable functionality, real-time data access, user-friendly interfaces, automated transac-tions, streamlined processes, and robust analytics and reporting capabilities.

It shall also feature multiple access levels with security features that can be used to define and limit access and data visibility to specific, Airports Authority–defined user groups. The new SDMS will eliminate the use of siloed legacy systems, paper-based and manual processes, and duplication of effort while significantly reducing processing time.

The system shall include enhanced core supplier diversity features:

A paperless DBE/ACDBE and LDBE certification application process for new and re-newing/continuing suppliers

Improved monitoring and tracking of certification application processing


1-3

Validation and better visibility of supplier certification status and automated communica-tion with suppliers via e-mail regarding certification issues

Improved compliance with DBE/ACDBE laws and regulations

Improved compliance monitoring and automated communication with suppliers viae-mail regarding compliance issues

Greater ability to set and monitor goals on individual contracts

Submission of supplier utilization reports online with automated tracking of contract goals and participation

Enhanced outreach and engagement of LDBEs and minority and women-owned busi-nesses

Enhanced outreach efforts to target firms using North American Industry Classification System (NAICS) and National Institute of Governmental Purchasing (NIGP) codes

Automatic verification of supplier payments (invoices)

Increased security for sensitive supplier data

Elimination of paper-based reporting.

To facilitate the process and time to fully implement the SDMS COTS solution, the Airports Au-thority anticipates that customization of software code will not be needed to meet Airports Au-thority requirements. The Airports Authority is willing to change internal processes, instead, to align with the SDMS solution.

The Contractor shall deliver a complete SDMS solution to meet Airports Authority requirements via a SaaS delivery model, all services necessary to implement the SaaS solution, and the opera-tions and maintenance (O&M) support services necessary to host and operate the solution in a secure cloud computing environment. The Contractor shall furnish the SDMS solution and pro-vide all services to develop, test, train users on, implement, and support the SDMS solution over the contract period of performance, including all system documentation and deliverables.

The Contractor shall provide the following support services:

SDMS initial implementation (investment). Program management services until the system is determined by the SDMS Contracting Officer’s Technical representative (COTR) to be fully operational; requirements management services; SaaS solution con-figuration services; business process redesign (BPR) services; Contractor hosting ser-vices; data cleansing, migration, validation, and data management services; interface development services; testing services; training services; and full implementation and cutover (go-live) services.


1-4

SDMS O&M (sustainment). Recurring O&M services, including SaaS solution manage-ment, solution hosting and network management, security and service-level agreement (SLA) support, records and data management, change management, and customer sup-port (help desk).

Supplemental services. Services related to the O&M and improvement of the SDMS after the system becomes operational as determined by the SDMS COTR.

1.3 AIRPORTS AUTHORITY REFERENCE MATERIALSAND STANDARDS

Airports Authority policies associated with supplier diversity, cloud computing, information technology (IT), and contracting are well-established and supported. The Contractor shall refer to the following reference materials when meeting the requirements of this SOW (if this SOW and the cited references conflict, this SOW takes precedence):

Code of Federal Regulations (CFR) Title 49, Subtitle A, Part 23 and Part 26 (49 CFR Parts 23 and 26), Participation by Disadvantaged Business Enterprises in Department of Transportation (DOT) Financial Assistance Programs

13 CFR Part 121, Small Business Size Regulations

Annual Federal Aviation Administration (FAA) Reauthorization Bill (current Transporta-tion Equity Act for the 21st Century [TEA-21])

MWAA Contracting Manual, 4th Edition, Revision 2, June 1, 2015

Federal Information Security and Management Act (FISMA)

Federal Risk and Authorization Management Program (FedRAMP)

National Institute of Standards and Technology (NIST) Cloud References

Statement on Standards for Attestation Engagements 16 (SSAE 16)

Standard Operating Procedure, Information Security Standard Requirements for SaaS(7/17/15), SEC-DOC-SS001.01

Airports Authority Department of Supplier Diversity website, http://www.mwaa.com/business/department-supplier-diversity-dsd .

2-1

2. Management and Operations

2.1 SUPPORT ORGANIZATIONS

Four Airports Authority organizations are the primary administrators of the SDMS solution:

Department of Supplier Diversity (MA-410). This group is the project sponsor for this procurement, and overall oversight and support of the new SDMS application will reside in this office. It is responsible for implementing and managing the three core supplier di-versity functions—certification, compliance and goal setting, and supplier outreach. The goal of this group is to maximize opportunities for small, disadvantaged MBEs and WBEs in competing for Airports Authority–sponsored contracts. It is responsible for three small business programs: the Airports Authority’s LDBE Program for contracts that do not include federal funds, the DBE Program for contracts funded in part or in whole with DOT funds, and the ACDBE Program for airport concession opportunities.

Procurement and Contracting Department (MA-29). This group is responsible for pro-curement and contracting actions for the Airports Authority and is committed to a com-petitive procurement process. As an advocate of the supplier diversity programs, it recognizes the importance of maximizing procurement opportunities for small and disad-vantaged businesses and ensures its contracting actions adhere to published Airports Au-thority policies, sound contracting methods, and the highest standards of integrity and ethical conduct. As part of this commitment, it supports DSD staff members during goal setting and pre-award activities and ensures LDBE and DBE contracts and participation requirements are met before contract award. It furnishes contract award data for DSD tracking, assists with post-award compliance reviews to ensure goals are met, and helps resolve compliance issues.

Office of Finance (MA-20). The Accounts Payable Department within the Office of Fi-nance is responsible for processing electronic and paper invoices/bills received from sup-pliers and interfaces with the DSD to provide current contract data. Functions of the Accounts Payable Department include coding bills/invoices, matching invoices to an au-thorizing purchase order, comparing them for accuracy with the receiving report, approv-ing for payment, contacting vendors when necessary concerning incorrect bills/invoices and arranging for corrections or credits as appropriate, applying available credits and dis-counts to payments, reviewing and processing expense administration payments, adding new vendors to the ERP master vendor file (noting applicable credits and cash or net dis-counts), and approving payment and entering it into the appropriate general ledger or ac-counts payable sub-ledger.

Office of Technology (MA-600). This group develops, operates, and maintains automated information systems, infrastructure, telecommunications, and wireless and radio systems to support Airports Authority operations. It manages the operating systems, application software, hardware, and data centers used to host the legacy system. It also provides net-

Management and Operations

2-2

work support and maintenance for the servers that host the supplier diversity application software. This office and the Airports Authority’s chief information officer (CIO) are key proponents of the SDMS project.

Together, these departments will work with the SDMS Contractor and other Airports Authority stakeholders to ensure an optimal SDMS solution is implemented on schedule, performance standards are met, and support is provided over the life of the contract.

2.2 OPERATIONAL ENVIRONMENT

The Airports Authority’s DSD implements and administers the supplier diversity program through three small business programs. The programs consist of the DOT-mandated DBE pro-gram for DOT funded/assisted contracts, the ACDBE program for airport non-car rental and car rental concession opportunities, and the Airports Authority–created LDBE program for non-DOT/federally funded/assisted contracts. In addition, the DSD also seeks to maximize participa-tion by MBE and WBE firms through the DBE and LDBE programs.

The DSD executes three core functions to manage the small business programs, each of which shall be supported by the SDMS: certification, compliance and goal setting, and outreach:

Certification. DSD, along with the Virginia Department of Small Business and Supplier Diversity (VSBSD), certifies eligible disadvantaged businesses seeking to participate in DOT-funded projects in the state of Virginia. Certifications from either DSD or VSBSD are accepted for any eligible project in Virginia. ACDBE and DBE requirements and cer-tifications are governed by DOT regulations in 49 CFR Part 23, as amended, for airport concessions, and 49 CFR Part 26 for participation by DBEs in DOT funded/assisted pro-jects. DSD is responsible for reviewing certification applications, visiting sites as re-quired, making certification decisions (approval, denial, decertification, and appeals determinations), conducting annual reviews and submitting reports to DOT and the Air-ports Authority’s Board of Directors. It also manages a directory of certified LDBE and DBE/ACDBE firms.

Certification activities are as follows:

Manage the certification review function, working with DOT, VSBSD, and Virginia Department of Transportation (VDOT) in determining the structure and operation of DBE certifying agency functions.

Facilitate and assist businesses applying to the Airports Authority for LDBE and DBE/ACDBE certification.

Process certification applications, including intake, processing, preliminary review, and certification and annual reviews (recertification) of applications for LDBE and DBE certification and maintain certification files in the certification directory data-base. Also, review, assign, and approve NAICS and NIGP classification codes for certified firms.


2-3

Review certification applications and make certification determinations for Airports Authority LDBE certification and federal DBE and ACDBE certification under DOT regulations for 49 CFR, Parts 23 and 26, and 13 CFR, Part 121.

Approve LDBE, DBE/ACDBE, MBE, and WBE certification applications and pro-duce annual review (recertification) letters or denial of certification letters.

Coordinate certification data reported on the Airports Authority’s DBE website and the VSBSD DBE website to consolidate information into one directory managed by VSBSD, assist with providing DBE certification applicants with seamless and user-friendly access, and ensure ongoing compliance with federal DBE regulations.

Compliance and goal setting. DSD oversees pre-award and post-award activities to en-sure DBE and LDBE compliance. They conduct compliance reviews and monitor con-tracts for compliance with diversity goals and requirements, establish and manage diversity goals, and report goal achievement.

The Airports Authority establishes two types of goals to measure the performance of its small business programs: (1) overall goals by program type and (2) individual contract goals. DOT regulations require the Airports Authority to establish overall 3-year goals for the DBE and ACDBE programs and submit them to the applicable DOT agency for concurrence. The Airports Authority Board of Directors establishes the annual goals for the LDBE program. In support of the 3-year DBE/ACDBE and annual LDBE goals, the DSD evaluates all solicitations valued at $50,000 or more to establish individual contract goals. The goals are established contract by contract and may be achieved at the prime or sub-Contractor level for each contract. The annual aggregate total of the individual con-tract goals should equal or exceed the overall annual or 3-year program goals and re-quirements.

Compliance and goal setting activities are as follows:

Manage pre-award compliance activities to ensure that opportunities for LDBE and DBE participation on Airports Authority contracts are identified as early as possible in the requirements development process. LDBE and DBE requirements are com-municated to potential suppliers through contract solicitation terms and conditions.

Manage post-award compliance reviews to ensure LDBE and DBE firms selected for award comply with participation requirements.

Develop and implement supplier diversity strategic planning goals, establish met-rics for measuring the effectiveness of individual programs and strategies, develop and track key performance indicators (KPIs) for the supplier diversity program, and report findings.

Coordinate with the Airports Authority COTRs and the airport division initiating contract requirements to determine DBE numerical goals and LDBE requirements and appropriate voluntary MBE/WBE goals on all Airports Authority–sponsored contracts.


2-4

Assist Contracting Officers (COs) and COTRs with determining and designating the appropriate set-asides and percentage goals for LDBE and DBE participation in contracts.

Develop the Airports Authority’s DBE goals (set goals) and monitor their achieve-ment for DOT-funded contracts and the Airports Authority’s projected DBE con-cession goals for the FAA. Develop metrics and dashboards to measure performance against goals.

Collaborate with Airports Authority offices and departments regarding LDBE and DBE compliance activities to help ensure the Airports Authority complies with le-gal and programmatic compliance requirements.

Review and oversee the successful offeror’s compliance with LDBE and DBE re-quirements before award and conduct pre-award and post-award reviews of suppli-ers to ensure compliance with established LDBE and DBE requirements.

Review deliverables to ensure work was performed by LDBEs or DBEs and moni-tor expenditures (invoices) relating to MBEs and WBEs.

Manage and monitor supplier diversity requirements and ensure compliance by vis-iting Contractor facilities and construction sites as required.

Outreach. DSD is actively engaged in outreach activities as supplier diversity advocates encouraging and promoting Airports Authority business opportunities with eligible sup-pliers and assisting with attracting new suppliers to the Airports Authority supplier diver-sity programs. It manages supplier diversity outreach activities, actively engaging firms through networking and interacting with the suppliers to support supplier diversity goals.

DSD outreach activities are as follows:

Oversee the supplier diversity Outreach Program, serving as a liaison between sup-pliers and Airports Authority business opportunities.

Review requirements and proposed SOWs to determine LDBE and DBE set-aside and percentage goals for the planned contract action.

Assist and serve as advisors for Airports Authority COTRs and other stakeholders to promote participation of DSD suppliers in Airports Authority contracts.

Manage the DSD “Opportunity Notifications” to DSD suppliers regarding contract-ing opportunities in their identified industries.

Identify, promote, track, and report on in-reach (when small and disadvantaged businesses contact the Airports Authority for business opportunities independent of DSD outreach efforts) and outreach activities regarding Airports Authority contract-ing opportunities for goods and services and major contracts for the Airports Au-thority’s Capital Construction Program (CCP).


2-5

Host business seminars in collaboration with other Airports Authority stakeholders and experts to assist potential diversity firms with understanding business opportu-nities.

Attend minority business events, procurement fairs, and other outreach activities to provide information on the Airports Authority’s contracting programs to potential suppliers.

Develop and maintain internal and external outreach materials on the Airports Au-thority intranet and internet.

Develop supplier diversity policies and outreach initiatives that encourage MBE and WBE participation in Airports Authority contracting opportunities. Identify business opportunities and eliminate barriers and requirements that hinder the par-ticipation of LDBEs and DBEs from doing business with the Airports Authority.

Attend procurement pre-solicitation meetings explaining participation requirements to potential offerors and answer questions and prepare written responses for formal meeting records.

Explain DSD program requirements to successful offerors to ensure they meet ap-plicable solicitation terms and conditions before contract award (for example, the subcontractors are certified LDBEs or DBEs and have submitted proposals for the agreed-upon contract price).

Verify that suppliers in the Airports Authority DSD program have current certifica-tions and are eligible for receiving contract awards under the DSD program.

2.3 TRANSACTIONS

The typical transactions and milestones for the three core functions are as follows:

Certification. The Airports Authority is responsible for two certification programs, LDBE and DBE/ACDBE certifications.

1. LDBE Certification. The Airports Authority certifies local small businesses to participate in Airports Authority contracting opportunities that require LDBE par-ticipation. Applicants must be small businesses organized for profit, located with-in a 100-mile radius of Washington, DC’s, Zero Mile Marker, and not exceed the Airports Authority’s established small business size standard by industry type (NAICS code).

In 2014, 500 applications were received for certification or annual recertifica-tion.

In 2014, 462 LDBE firms were newly certified or received annual recertifica-tion.


2-6

2. DBE/ACDBE certification. The Virginia Unified Certification Program (VUCP) provides “one-stop shopping” certification services to small minority and women owned businesses seeking to participate in the DOT DBE and ACDBE Programs. The VUCP includes two certifying agencies; the Airports Authority and the VSBSD. Federal DBE or ACDBE certification by either agency is fully accepted throughout Virginia on DOT-funded contracts. There is no distinction between DBE and ACDBE certifications performed by the Airports Authority or DMBE, so businesses are not required to submit applications to both agencies.

In 2014, 300 applications were received for certification or annual recertifica-tion.

In 2014, 290 DBE/ACDBE firms were newly certified or received annual recertification.

Compliance and goal setting. DSD staff members oversee pre-award and post-award ac-tivities to ensure DBE and LDBE compliance. They also establish and manage diversity goals and report their achievement.

In 2014, 140 solicitations were reviewed to establish LDBE participation require-ments and pre-award contract compliance determinations.

In 2014, 76 LDBE participation requirements were placed on the 128 solicitations (47 assigned 100 percent LDBE participation).

In 2014, $33,152,098 was projected for LDBE participation (about 33 percent of the $100,009,012 combined year-to-date estimated value of non-federally funded so-licitations).

In 2014, 350 active contracts were monitored for DBE and LDBE compliance with contract requirements.

Nine overall goals are monitored annually (3-year and annual goals reported month-ly, semiannually, and annually). Table 2-1 lists the goals and the reporting require-ment.

Table 2-1. Goal and Reporting Requirement

Type Area covered Goal Goal period Reporting requirements

DBE FAA Airport Improvement Program Funded Projects for DCA and IAD

25% Triennial Goal(2014/2015/2016)

Monthly to DSD Office Semiannually to Board Annually to FAA

ACDBE Non-Car Rental Concessions DCA 30% Triennial Goal(2015/2016/2017)



2-7

Car Rental Concessions DCA 10% Triennial Goal (2015/2016/2017)


Non-Car Rental Concessions IAD 22% Triennial Goal (2015/2016/2017)


Car Rental Concessions IAD 10% Triennial Goal (2015/2016/2017)


DBE Federal Transportation Administration (FTA) Assistance for Rail Project, Phase 1*

13% Duration of the Project

Monthly to DSD Office Semiannually to Board Semiannually to FTA

FTA—Assistance for Rail Project – Phase 2*

25% Duration of the Project

Monthly to DSD Office Semiannually to Board Semiannually to FTA

LDBE Non-DOT Assisted Construction DCA, IAD, and Dulles Toll Road

25% Annual Monthly to DSD Office Semiannually to Board

Non-DOT Assisted Goods and Ser-vices DCA, IAD, and Dulles Toll Road

20% Annual Monthly to DSD Office Semiannually to Board

*Reported as total achievement for the duration of the project (project specific goal).

Outreach. DSD staff members participate in internal and external outreach events and ac-tivities throughout the year to promote Airports Authority business opportunities with di-versity suppliers:

In 2014, 10,000 total firms (including 2,000 certified firms) were on the outreach mailing list (including business cards and brochures received from small business firms).

In 2014, 2,000 total suppliers were in the diversity certification directories (LDBE, DBE/ACDBE). The Contractor shall transfer data for these firms into the new SDMS solution.

In 2014, DSD staff members participated in 20 external outreach events that were attended by 6,750 business representatives.

2.4 USER COMMUNITY

Participation in SDMS processes differ by user type. The system shall permit the definition of multiple user profiles and access levels, each with appropriate security controls that can be easily defined by the Airports Authority before implementation and can also be modified as required by the Airports Authority. This will establish the authorized access level for the defined user groups.

There will be four user groups, at a minimum, all of which will require access to the SDMS—either during normal business hours or 24 hours per day, every day, year-round—on-site at Air-ports Authority facilities and remotely via personal computers (PCs) and mobile devices (such as mobile phones and tablets):


2-8

System administrators. Although the Contractor is responsible for administering its SaaS software application, Office of Technology system administrators at the Technology Ser-vice Desk (Techworks) will oversee and monitor system operations for SDMS users. They will work with the Contractor to minimize system downtime and disruption of ser-vice and ensure steady system operations. They will require unlimited access to the sys-tem 24 hours per day, every day, year-round via their Airports Authority PCs onsite in their work areas as well as remote access.

In 2016, there will be an estimated 2 Techworks system administrators.

Power users. These DSD employees will interact with the system daily. They will over-see SDMS operations and require access to SDMS records and reports for their functional area. Because they will use more features of the system and access more system func-tionality, they may serve as customer service representatives for non-power users. They will also have authority to conduct robust analyses and create reports to aid managers with decision making. They require a fast, easy-to-use system to access SDMS records and reports and process routine transactions. Power users will typically use the system Monday through Friday, during normal business hours (7:00 a.m. to 7:00 p.m.) from PCs in their workstations onsite, with periodic access after business hours remotely through PCs and mobile devices.

In 2016, there will be an estimated 21 power users:

4 for certification

6 for compliance

11 for outreach.

Standard users (non-power users and non-system administrators). These Airports Au-thority (DSD and Contracting and Procurement) and VSBSD employees will access the system for routine tasks and to generate reports. They will typically use the system Mon-day through Friday, during normal business hours from 7:00 am to 7:00 pm, from PCs at their workstations onsite with periodic access after business hours with remote access us-ing PCs and mobile devices.

In 2016, there will be an estimated 977 standard users:

12 for certification

280 for compliance

280 for outreach

400 COs, COTRs, and procurement personnel (50 COs, 300 COTRs, and 50 pro-curement)

5 for VSBSD.


2-9

Supplier users. These users will have limited access to the SDMS to process new and re-certification actions, monitor the certification application intake process and status, re-view certification approval decisions, access links to appeal decisions, and review the certification directory for new and existing certifications. They will access the SDMS—24 hours per day, every day, year-round—remotely via PCs and mobile devices (such as mobile phones and tablets):

In 2016, there will be an estimated 4,000 supplier users:

1,000 for DBE

3,000 for LDBE.

Table 2-2 shows an annual breakdown of the estimated number of users by user type. This count does not consider the mix of full- and part-time personnel; it assumes all employees are full-time.

Table 2-2. Estimated User Breakdown by User Type

Type

Base year 12016

Base year 22017

(30% growth)

Base year 32018

(3% growth)

Option year 1 2019

(3% growth)

Option year 22020

(3% growth)

System administrators 2 2 2 2 2 Power users 21 27 28 29 30 Standard users 977 1,271 1,308 1,347 1,388

Subtotal 1,000 1,300 1,338 1,378 1,420 Suppliers 4,000 5,200 5,356 5,517 5,680

Total 5,000 6,500 6,694 6,895 7,100

The number of SDMS users (Airports Authority and VSBSD employees) is estimated to range from 1,000 in 2016 to 1,420 in 2020. Assuming a 30 percent increase in the number of users in 2017 for new construction contracts and a standard growth rate of 3 percent in 2018–20, the total number of users (Airports Authority, VSDBS, and suppliers) will range from 5,000 in 2016 to 7,100 in 2020.

3-1

3. System Architecture

3.1 CURRENT SYSTEM ARCHITECTURE

Figure 3-1 shows the Airports Authority’s legacy solution that supports supplier diversity func-tions. The overall system consists of applications, interfaces to external systems, external data feeds around the system’s supplier diversity functions, and manual processes. The system’s ca-pabilities are limited by its lack of integration and labor-intensive and paper-based processes.

Figure 3-1. Current State Legacy System

In day-to-day DSD system operations, DSD staff members “pull” flat data files and spreadsheet-based reports from various systems, analyze and review the data, and “push” the resulting reports to destination systems and Airports Authority and VSBSD staff members.

System Architecture

3-2

The legacy supplier diversity system includes the following systems and processes:

Oracle ERP

Procurement. Primary Airports Authority system of record for vendor and contract information. Procurement staff members enter prime contract award information in-to the procurement module, which then prepopulates the EOP system (see below) with the data.

EOP (EOP I). Add-on to the Airports Authority’s Oracle ERP procurement module for supplier diversity-specific information. Processes vendor invoices and tracks DBE and LDBE contracts for goods and services and construction. DSD staff members enter LDBE and DBE subcontractor data and manually input subcontrac-tor commitment and payment data as provided by Exhibits D and J.

VSBSD. DSD sends vendor information monthly via File Transfer Protocol (FTP) for all newly certified DBE or ACDBE vendors to the VSBSD DBE directory. DSD also queries the VSBSD directory to verify new vendor certifications performed by VSBSD.

Dulles Corridor Metrorail Project (DCMP). DCMP sends DBE Metrorail contract award data on Excel spreadsheets to DSD in support of DSD’s regularly scheduled reports to the Airports Authority’s Board of Directors. DSD also sends a Metrorail contract award spreadsheet to the Airports Authority’s Grants department, which enters the data into an online FTA reporting system used to track FTA-funded awards.

Custom Application (EOP II). EOP II processes DSD vendor certifications; tracks out-reach activities, and maintain the DBE/ACDBE/LDBE directory database. EOP II in-cludes currently unused modules for outreach, payment, planning, and other similar functions. EOP II information originates from supplier certification applications. DSD re-ceives supplier applications by e-mail or hard copy, manually processes certification ap-plications and renewals, and populates EOP II accordingly. DSD staff members also extract supplier certification information from EOP II monthly, post it on the Airports Authority public website, and send VSBSD a flat file via FTP.

MWAA Business Units. The Procurement office and business units send relevant solicita-tion package documents via e-mail or hard copy to DSD, which reviews them to deter-mine the individual contract LDBE/DBE participation requirement or goal. DSD develops a goal and justification, stores it internally, and sends a form via e-mail or hand delivers it back to Procurement and the business unit.

Compliance Reviews. DSD conducts compliance reviews for DBE, ACDBE, and LDBE achievement.

Pre-award compliance. Prime Contractors submit the Contract Participation Form (Exhibit D) with their proposals. Exhibit D lists DBE/LDBE subcontractors, dollar amounts of work they will perform, and the type of work to be performed. Procure-ment sends the Exhibit D with a memo by hard copy or e-mail to DSD, which verifies it and sends the memo back to Procurement via e-mail or hard copy.

System Architecture

3-3

Post award compliance. The DSD staff, in conjunction with COs and COTRs, moni-tors DBE/LDBE participation on the contract, tracking payments to prime and sub-contractors, prompt payments, DBE/LDBE participation in accordance with Exhibit E, and subcontract and performance of commercially useful functions.

Suppliers. Suppliers apply for DBE/ACDBE/LDBE certification through a paper- and e-mail-based process. (See Section 2 for the number of suppliers and transactions.)

Board of Director Inquiries. DSD responds to Airports Authority Board of Director in-quiries as necessary and may query one or more of the above systems to collect the data needed to respond to the inquiry.

Reports. DSD uses information from the sources listed above to compile and deliver var-ious reports—Airports Authority Board of Director reports, ACDBE concessions reports (IAD/DCA terminal), and FAA/FTA reports—in the form of Microsoft Word documents, Microsoft Excel documents, and portable document format (PDF) spreadsheets.

3.2 TARGET ARCHITECTURE

The Airports Authority seeks to acquire a new SDMS to replace the current legacy supplier di-versity system and manual processes with automated processes and workflows, reducing paper- and spreadsheet-based information exchanges. The new SDMS shall be a single, fully integrated SaaS COTS solution.

The new SDMS shall support all the core supplier diversity functions, meeting the scope of the Airports Authority’s functional and technical requirements and interfaces listed in Appendix A and B. The functional requirements are organized by core DSD functional area: certification, compliance and goal-setting, and outreach.

The new SDMS shall support the target state process flows (see Appendix C diagrams) for the three core functions and the current and target state (future state) high-level capabilities (Appen-dix D). The Contractor shall include all existing system functionality, including processing ap-plications from suppliers, issuing and managing certifications, and tracking DBE and LDBE contract awards, deliverables, and invoices.

The new SDMS environment shall include required system interfaces, but the Contractor shall reduce the number of integration points, when possible, developing a fully integrated system. The Contractor shall also include new system interfaces and additional interfaces developed on the basis of the Contractor’s SDMS solution.

The Contractor shall provide for the following functionality through the SaaS solution in the new SDMS solution as well as functionality captured in target state process flows (Appendix C) and capabilities (Appendix D):

Procurement. The procurement ERP system will automatically feed vendor contract in-formation to the SDMS. It will interface with Procurement in the solicitation phase (noti-fication of solicitation date), and then offerors/bidders will enter Exhibit D before award

System Architecture

3-4

and obtain DSD approval. At award, the ERP will automatically populate contract award data into the SDMS from Exhibit D and from data entered by Procurement.

VSBSD. The SDMS shall store and send automated monthly reports for all newly certi-fied DBE or ACDBE vendors to the VSBSD DBE directory. The SDMS shall also send ad hoc reports to the VSBSD. The SDMS shall allow for automated and ad hoc electronic queries to VSBSD to verify new vendor certifications and pending applications.

Dulles Corridor Metrorail Project. The SDMS shall enable DCMP staff members to en-ter DBE contract information (contracts awarded, awardee, dollar amounts, etc.) as need-ed. The SDMS shall also store and send automated monthly DCMP reports to DSD and the Airports Authority Grants department and provide for ad hoc DSD and Grants de-partment queries of DCMP diversity information.

Custom Application (EOP II). The SDMS shall replace all EOP II functions, including vendor certifications by NAICS and NIGP codes, outreach activities, the DBE/ACDBE/ LDBE directory, and a new federal certification required for construction contracts for small businesses.

MWAA Business Units. Business units will enter goal-setting requests into the SDMS. The SDMS will use an automated goal-setting activity and notification workflow to pro-cess information between the business units, COTRs, Procurement, and DSD staff. In ad-dition to goal-setting, the SDMS will also manage outreach activities (identification, recruitment, and notification of potential and existing DBE/ACDBE/SBE/LDBE/ MBE/WBE firms of contract opportunities). The SDMS will support inclusion of busi-ness unit staff members in SDMS outreach efforts and integrate outreach efforts with the procurement process.

Compliance Reviews. Contract information from the Exhibit D Contract Participation form from EOP I will be automatically populated in the SDMS and used for compliance review from DBE and LDBE suppliers. The SDMS shall use an automated compliance review workflow to process information between Procurement and DSD.

Suppliers. Potential DBE/ACDBE/SBE/LDBE/MBE/WBE suppliers will access the SDMS to create, save, update, and submit certification applications. Once certified, sup-pliers will access the system to submit recertification information. The SDMS shall also maintain a database of all DBE/ACDBE/SBE/LDBE/MBE/WBE suppliers and a separate database of all potential suppliers engaged through outreach activities.

Reports/Board Inquiries. DSD staff members will access various reports—Board of Di-rectors reports, ACDBE concessions reports (IAD/DCA terminal), and FAA/FTA re-ports—and create “canned” (preconfigured, created by the Contractor) and ad hoc reports in the SDMS as necessary for periodic reporting and in response to Board of Directors inquiries. (Appendix F lists SDMS reports.)

4-1

4. Detailed Scope

4.1 SCOPE SUMMARY

The Contractor shall deliver an SDMS that meets the entire scope of the Airports Authority’s requirements, initial implementation and recurring O&M activities (Table 4-1).

Table 4-1. SDMS Detailed Task Summary

TasksInitial

implementation O&M

Task 1. Program Management Services X Task 2. Requirements Management Services X Task 3. SaaS Solution Configuration Services X Task 4. Business Process Redesign Services X Task 5. Contractor Hosting Services X Task 6. Data Cleansing, Migration, Validation, and Management Services X Task 7. Interface Development Services X Task 8. Testing Services X Task 9. Training Services X Task 10. Full Implementation and Cutover (Go-Live) Services X Task 11. O&M Services 11.1 SaaS Solution Management 11.2 Solution Hosting and Network Management 11.3 Security and SLA Support 11.4 Records and Data Management 11.5 Change Management 11.6 Customer Support (Help Desk)

X

The Contractor shall perform all activities required to provide SaaS services, implement the SDMS solution, and support and maintain it for the full range of requirements over the contract period of performance.

4.2 DETAILED SCOPE TASKS

This subsection describes the major SDMS tasks and deliverables the Contractor shall provide to meet the Airports Authority’s requirements for SDMS Tasks 1 through 11.

4.2.1 SDMS Task 1—Program Management Services The Contractor shall provide program management services, starting at contract award, until the system is fully implemented. Program management functions shall include maintaining and

Detailed Scope

4-2

meeting schedule milestones, managing deliverables, managing risks, identifying and resolving problems, keeping Airports Authority management informed of progress and issues, change management and communications, and managing the Contractor’s staff.

The Contractor shall deliver the following:

4.2.1.1. Detailed project plan. The Contractor shall deliver a detailed plan that defines the ac-tivities, schedule, and responsibilities for completing and delivering the tasks for the end-to-end SDMS solution. The plan also shall include key milestones, deliverables, and any dependencies on the Airports Authority and define its role and responsibilities. The Contractor shall deliver one draft and one final project plan after the effective date of the contract.

The Contractor shall deliver one draft and one final detailed project plan. The draft de-tailed project plan shall be delivered 15 calendar days after the kickoff meeting (the SDMS COTR will schedule the kickoff meeting at least 15 calendar days after the ef-fective date of the contract). The Airports Authority will provide review comments to the Contractor within seven calendar days from receipt of the draft document. The Con-tractor shall have seven calendar days to submit the final document to the SDMS COTR for approval. The SDMS will approve the document within three calendar days.

The detailed project plan shall include the following:

A work breakdown structure (WBS) that shows the SDMS tasks required to com-plete the work and the dependencies of each SDMS task. The WBS should be de-tailed enough to support the accomplishment of SDMS work.

A program schedule that shows the completion dates for major milestones, tasks, and deliverables. The schedule shall include the following milestones at a mini-mum:

Sign-off of the requirements document (SDMS COTR approval)

Sign-off of the BPR (SDMS COTR approval)

Testing

Training

Full implementation (go-live) (SDMS COTR approval)

O&M.

A description of the organization structure and responsibilities, including the Con-tractor’s program staff that will implement and maintain the SDMS, and identifi-cation of key personnel, including the program manager, requirements lead, solutions architect, BPR lead, integration lead, and test lead. The Contractor shall describe the team members’ job functions and responsibilities, provide a team or-

Detailed Scope

4-3

ganizational chart, and describe other corporate groups or organizations that will support the SDMS team.

A high-level cutover plan and a schedule that describe the full implementation (go-live) process and potential risks and mitigation strategy.

A communication plan for keeping the Airports Authority informed as well as the Contractor’s strategy for communicating with Contractor employees on- and off-site.

A risk management plan that includes the risks the Contractor believes is inherent in the SDMS solution and a risk register. For each risk, the plan shall include at least a description of the risk, a risk severity rating (high, moderate, or low), likelihood of occurrence, definition of each level of severity and likelihood, and a descrip-tion of the impact and a mitigation strategy for the risk should it occur.

4.2.1.2. Status reporting. The Contractor shall provide weekly status reports that describe pro-gram progress, costs incurred, issues, and their current status. The report shall be struc-tured to align with the WBS in the detailed project plan. The report shall describe both the previous week’s activities and the planned activities, including anyrequired interfaces, meetings, or other Airports Authority commitments required. The weekly report shall be delivered every Monday after the kickoff meeting.

4.2.1.3. Progress meetings. The Contractor shall participate initially in weekly progress meet-ings held in person at the Airports Authority, DCA. The first weekly progress meeting shall be held the week after the kickoff meeting. The SDMS COTR will notify the Con-tractor when the frequency of the progress meetings can change from weekly to bi-weekly. The Contractor shall track program progress and resolve issues after the weekly status report has been delivered. The Contractor shall prepare and deliver pro-gress meeting minutes listing any action items and outstanding issues. Meeting minutes shall be delivered within 2 calendar days after each progress meeting.

The Contractor shall also attend daily, 10- to 15-minute team “sync-up” meetings with the SDMS COTR, at which core team members shall update each other on task status, progress, and issues. The first daily “sync-up” meeting shall be held the day after the kickoff meeting.

4.2.2 SDMS Task 2—Requirements Management Services The Contractor shall manage the requirements for the SDMS solution, including all functional and technical requirements. (Appendix A contains the full set of functional and technicalrequirements.)

The Contractor shall do the following:

Manage requirements through the SDMS software life-cycle, including

Detailed Scope

4-4

analyzing and documenting the initial requirements provided by the Airports Authority (Appendix A);

finalizing, tracing, and prioritizing the requirements and developing a requirements baseline;

obtaining approval from the SDMS COTR of the requirements baseline;

tracking changes to the requirements baseline; and

controlling change management activities.


4.2.2.1. Requirements management plan. The Contractor shall deliver a requirements man-agement plan that includes the activities, schedule, and responsibilities for managing the SDMS requirements (functional and technical). The plan shall include assumptions and constraints, requirements and definitions, requirements traceability, workflows and activities, change management, and the process for obtaining approval from the SDMS COTR.

The Contractor shall deliver one draft and one final of the requirements management plan to the SDMS COTR. The documents shall be delivered in accordance with (IAW) the approved final project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.2.2. Detailed requirements document and execution. The Contractor shall execute the ap-proved requirements management plan and deliver the requirements baseline, including functional and technical requirements, with clear traceability of requirements. The Con-tractor shall deliver updated requirements documents to the SDMS COTR monthly or when the requirements baseline changes.

The Contractor shall deliver one draft and one final of the detailed requirements docu-ment to the SDMS COTR. The Contractor shall deliver the document and execute the approved requirements plan IAW the approved final project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.3 SDMS Task 3—SaaS Solution Configuration Services The Contractor shall be responsible for providing and hosting a fully configured SDMS COTS SaaS cloud-based solution with no customization. The SaaS solution shall support configuration options that require no code changes. Such configurations may include creating user roles, creat-ing new data fields, or creating and modifying workflows. It shall also include using the new SDMS’s available application programming interfaces (APIs) to create interfaces to legacy sup-plier diversity systems identified in Section 3.

Detailed Scope

4-5

The Contractor shall deliver an optimized SDMS that ensures efficient and effective operations that align with the SDMS SLAs (Section 5). Configuration shall include delivery of the SaaS so-lution on the basis of an assessment and subsequent implementation of system settings needed to meet the Airports Authority SDMS requirements.

To optimize the configuration, reporting, and usability of the SDMS SaaS solution, the Contrac-tor shall complete the following tasks:

Analyze and track requirements and deliver required system requirements documenta-tion performed in Task 2 Requirements Management Services.

Analyze and develop business rules and processes completed in the Task 4 BPR.

Configure the system to meet requirements.

Configure the APIs to address interface requirements in Task 7 Interface Development Services.


4.2.3.1. Configuration management plan. The Contractor shall deliver a configuration man-agement plan that describes how it will configure the SaaS to meet Airports Authority requirements and manage and maintain the solution. The plan shall include establishing a system baseline that identifies areas requiring configuration, including APIs, and the schedule to complete the effort.

The Contractor shall deliver one draft and one final configuration management plan to the SDMS COTR. The documents shall be delivered IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or be-fore the SDMS solution goes live).

4.2.3.2. Configuration management plan execution and fully configured SDMS solution. The Contractor shall execute the approved configuration management plan and deliver a ful-ly configured SaaS solution approved by the SDMS COTR.

The Contractor shall execute the configuration management plan and fully configure the SDMS solution IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.4 SDMS Task 4—Business Process Redesign Services The Contractor shall provide BPR services based on the scope of the Contractors SaaS solution. The BPR shall include process design, process change management, and business improvement to enable the Airports Authority to effectively implement new processes while leveraging the full capabilities of the solution with no customization to software code. This support shall ensure best practices are implemented for establishing and managing new processes that meet Airports Au-thority policies and regulatory requirements under which the Airports Authority operates.

Detailed Scope

4-6


4.2.4.1. BPR plan. The plan shall include the tasks, schedule, responsibilities, and deliverables required to conduct a business process assessment and redesign the Airports Authority’s practices.

The Contractor shall deliver one draft and one final BPR plan to the SDMS COTR. The documents shall be delivered IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.4.2. BPR document and plan execution. This document shall include the new business pro-cesses and will need sign-off by the SDMS COTR. The Contractor shall lead activities in collaboration with the SDMS COTR to execute the BPR plan and socialize the new business process changes to SDMS users before full system implementation.

The Contractor shall deliver one draft and one final BPR document to the SDMS COTR and execute the BPR plan IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.5 SDMS Task 5—Contractor Hosting Services The Airports Authority is acquiring a SaaS SDMS solution with the understanding that infra-structure management is solely the responsibility of the Contractor. However, the Contractor is expected to maintain evidence that it is operating a secure infrastructure environment—including a secure data center and network, as well as established continuity of operations (COOP) and disaster recovery plans—and meet the security requirements identified in Appendix A.

4.2.6 SDMS Task 6—Data Cleansing, Migration, Validation, and Management Services

The Contractor shall perform data cleansing, migration, validation, and data management ser-vices over the life of the contract. The Airports Authority will retain the rights to all of its data and reports that reside in the SaaS solution. The Contractor shall manage the data for the entire contract period. The system shall retain certification data for the data life cycle and archive date older than 6 years.

The Contractor shall manage the data and establish a data baseline that identifies the source and target data types and business rules for data fields; extract the data from the legacy systems; and load them into the SDMS solution. The Contractor shall perform data validation and life-cycle management activities that ensure data quality, security, access, and extraction speed to give the Airports Authority the ability to manage the data across the enterprise from the Contractor’s hosted site. The Airports Authority Office of Technology and the DSD will work with the Con-tractor to accomplish the work.

Detailed Scope

4-7

The Contractor shall complete the following:

A data baseline, schedule, and impact assessment

Data cleansing

Data extraction and migration as follows:

Transfer data for approximately 2,000 suppliers in the diversity certification direc-tory (LDBE, DBE/ACDBE) into the new SDMS solution.

Exhibit J-L/DBE payment tracking (interface name) data from Oracle ERP/EOP I to the new SDMS. This interface is used to send contract number, prime company name, program type, contract award date, contract end date, description, original contract amount, current contract amount, and payments and search supplier names.

LDBE, ACDBE, DBE certification (interface name) data from EOP II to the new SDMS. This interface is used to enter all LDBE, ACDBE, and DBE firms into EOP. The system stores all records of firms/vendors that have applied for and were processed for certification (including certifications, denials, withdrawals, and de-certifications).

Data validation

Data retention (DSD 6-year data retention from the date of decertification, expiration, withdrawal, or denial decision) and retirement

Data security

Data recovery.


4.2.6.1. Data management plan. The Contractor shall deliver a plan that details the activities, schedule, and responsibilities for migrating the Airports Authority’s data into the SDMS solution and managing the data over the data life cycle for the entire contract pe-riod.

The Contractor shall deliver one draft and one final data management plan to the SDMS COTR. The documents shall be delivered IAW the approved final detailed pro-ject plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

The plan shall include the following:

The tasks for which the Airports Authority will be responsible, Contractor and Air-ports Authority roles and responsibilities, and how they will work together to ac-complish the task

Detailed Scope

4-8

The strategy for assessing the current data environment to establish a data baseline and the detailed approach for collecting, cleansing, and standardizing the data from multiple sources, including legacy systems and files (including Microsoft Excel spreadsheets and Word files)

The approach for extracting and transferring data from legacy systems and files, centralizing the data in the SaaS environment, and validating the data

How the Contractor will extract all the Airports Authority’s data from the new SDMS system in the event the Airports Authority migrates to a different system in the future (also included in the transition exit plan).

The data tools, testing method, and a quality management strategy

A schedule with milestones that details how the data migration activities will sup-port SaaS implementation activities

Recurring activities for managing the data during O&M (sustainment).

4.2.6.2. Data management plan execution and data migration into the SDMS solution. TheContractor shall execute the data management plan. The Contractor shall deliver the da-ta baseline and perform data cleansing and extraction and testing. After successful test-ing and obtaining approval from the SDMS COTR, the Contractor shall migrate the data into the SaaS environment.

The Contractor shall execute the data management plan and migrate the data into the SDMS solution IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.7 SDMS Task 7—Interface Development Services The Contractor shall develop system interfaces for Airports Authority systems (Appendix B) and integrate them into the SDMS solution. (Appendix B lists the current Airports Authority system interfaces that will support the SDMS solution.) The specific type of interface for each system may be an API or another type recommended by the Contractor and approved by the SDMS COTR.


4.2.7. 1. Interface plan. The Contractor shall deliver an interface plan that supports the transi-tion of functionality from legacy systems to the new solution and a schedule for com-pleting the system interfaces. The plan shall include the tasks for which the Airports Authority will be responsible, Contractor and Airports Authority roles and responsibili-ties, and how they will work together to accomplish the task. The plan shall also de-scribe how the Contractor will test the system interfaces to validate that each meets system requirements, document all test scenarios or use cases, and show how it will track test results through completion of any corrections if any test scenarios fail. The

Detailed Scope

4-9

plan should also address how the solution will be configured to interface with existing Airports Authority systems.

The Contractor shall deliver one draft and one final interface plan to the SDMS COTR. The documents shall be delivered IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.7.2. Interface plan execution, testing, and integration of validated and accepted interfac-es. The Contractor shall do the following:

Conduct test readiness reviews to ensure all interfaces are ready for testing. The Contractor shall test the system interfaces and prepare a detailed report upon test completion that documents the outcome of each test scenario or use case in a manner that enables the Airports Authority to validate results and perform quality analyses. The report shall also address test scenario failures and how they were addressed.

Integrate the interfaces into the SDMS solution upon successful completion of inter-face testing and receipt of SDMS COTR approval.

The Contractor shall execute, test and integrate the validated and accepted interfaces in-to the SDMS solution IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.8 SDMS Task 8—Testing Services The Contractor shall thoroughly test the SDMS to ensure it meets all requirements, integrates with the Airports Authority network environment and the Contractor’s hosted network, and inter-faces properly with required systems. The Airports Authority will provide the Contractor with live data to test the system at least 30 days before testing is scheduled to begin.

The Contractor shall complete a system design review to validate the system requirements and shall demonstrate it fully understands the latest approved SDMS requirements before testing the system. Once the Contractor has demonstrated this capability, testing can begin with approval from the SDMS COTR.

The Contractor shall complete the following to validate the SDMS as an end-to-end solution:

Conduct testing in a minimum of two phases—(1) Contractor unit testing, requirements traceability testing, data conversion testing, interface testing, and security access testing and (2) user acceptance testing (UAT).

Test each implementation phase end to end before going live.

Test the end-to-end solution, including business rules, work flows, data, functionality, in-tegration, interfaces, applications, network, security and privacy, infrastructure, compli-

Detailed Scope

4-10

ance, performance, accessibility, availability, reliability, stability, browser compatibility, usage, multi-tenancy, and disaster recovery and failover testing.

Test the reporting and robust analytics features of the SDMS.

Provide a production environment, test environment (sandbox), and development envi-ronment. The production environment will serve as the operational environment for end users. The test environment will be used to perform unit and requirements traceability testing as well as UAT.

Provide test resources and test scenarios.

Conduct Contractor unit, requirements traceability, data conversion, interface, and securi-ty access testing.

Provide test scripts for UAT.

Support Airports Authority UAT. However, the Airports Authority will define the criteria for UAT to independently validate that the system meets system requirements. UAT will focus on key aspects of the system, including user access, transactions, data, and the unique features of the SDMS as a result of configuration and integration. UAT will lever-age testing performed by the Contractor during phase 1 as much as possible. The Airports Authority will complete a UAT summary report documenting the findings of UAT and make a recommendation for a go-live decision.

Identify, document, track, and correct issues identified during testing before the system goes live.

Use the test results to refine implementation procedures and training processes before ful-ly implementing the system.


4.2.8.1. Test plan. The Contractor shall deliver a system test plan that describes how the Con-tractor will test the system to validate that it meets system requirements, including gen-erating and delivering all reports and robust analytics required by the Airports Authority for the SDMS. The plan shall include activities, schedule, and roles and re-sponsibilities for testing the SDMS. It shall also include test scenarios and test data needed to test all requirements and interfaces, as well as resources and live data re-quired from the Airports Authority. The plan shall describe how the Contractor will track test results and the actions the Contractor will take if a specific test scenario fails.

The Contractor shall deliver one draft and one final test plan to the SDMS COTR. The documents shall be delivered IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

Detailed Scope

4-11

4.2.8-2. Test plan execution and test reports. The Contractor shall do the following:

Demonstrate it has the latest approved list of system requirements (functional and technical) before configuring and testing the SDMS solution.

Participate in test readiness reviews to ensure the SDMS system is ready for testing, the scope of the tests is clearly defined, and the test data are available.

Perform and support test activities.

Prepare a detailed test report upon completion of phase 1 testing. The Airports Au-thority will prepare the test report for UAT. The Contractor’s test report for phase 1 shall provide the outcome of each use case or test scenario in a manner that ena-bles the Airports Authority to validate results, perform internal quality assess-ments, and make recommendation for a go-live decision.

The Contractor shall execute the test plan and deliver one draft and one final of the test reports IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.9 SDMS Task 9—Training Services The Contractor shall deliver training materials and tutorials, conduct classroom training on-site at the Airports Authority, train UAT testers, and provide computer-based training (CBT) or web-based training hosted by the Contractor. Training and materials shall be provided for the follow-ing user groups:

System administrators—2 users

Power users—21 users

Standard users—977 users.


Conduct train-the-trainer (T3) training on-site at Airports Authority locations for about 23 employees (2 system administrations and 21 power users). System administrators and power users shall be trained on all aspects of the SDMS solution, receiving advanced sys-tem training. The Airports Authority may also record the classroom training sessions for future use by Airports Authority staff.

Train system administrators and power users on how to troubleshoot issues and analyze methods related to the functional aspects of the system. Contractor

Support the development of Airports Authority’s SDMS training plan and develop train-ing materials to assist with T3 activities. The plan will include information on training ac-tivities throughout the SDMS life cycle. (The Contractor shall not conduct classroom training for the standard users. The Airports Authority will take a T3 approach, where the

Detailed Scope

4-12

system administrators and power users will train these users on the basic features and functionality of the system.)

Provide CBT or web-based training with the SaaS solution hosted on the Contractor’s environment.

Provide online system help features.

Provide training tutorials, user guides, and other training materials to support T3 training and supplement CBT or web-based training as required.


4.2.9.1. Training plan. The Contractor shall deliver a training plan that details the approach and schedule for conducting training for system users. The SDMS COTR shall approve the plan before training is scheduled.

The Contractor shall deliver one draft and one final training plan to the SDMS COTR. The documents shall be delivered IAW the approved final detailed project plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.9.2. Training. The Contractor shall train system administrators and power users on-site at DCA:

4.2.9.2.1. System administrator training for two people.

4.2.9.2.2. Power user training for 21 people.

The Contractor shall train system administrators and power users on site at DCA IAW the approved final detailed project plan and training plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.9.3. Written training materials. The Contractor shall deliver training materials to support system administrator and power user training on the SDMS solution as well as tutorials for standard and non-standard users. Training materials may include participant slide decks, quick reference aids, and training manuals; instructor guides, copies of exercises, activities and exams; supplemental and reference materials; and videos.

The Contractor shall deliver 25 printed copies of the training slide deck, training manu-al and quick reference aids (one for each participant and two additional copies). The Contractor shall also deliver two printed copies of the instructor guides, copies of exer-cises, activities and exams, and supplemental and reference materials; and one copy of the training video (if applicable).

The Contractor shall provide all training materials IAW the final approved detailed pro-ject plan and training plan on or before the day of training (no later than six months af-ter the detailed project plan is approved or before the SDMS solution goes live).

Detailed Scope

4-13

4.2.9.4. CBT or web-based training. The Contractor shall furnish access to its CBT specific to SDMS for use by Airports Authority personnel focusing on non-power users and non-system administrators. The CBT shall be hosted by the Contractor. The Contractor shall provide a direct uniform resource locator (URL) to its web-based training program. The Contractor shall also deliver a printed version of any CBT or web-based training that consists of training screens and scripts.

The Contractor shall provide all CBT or web-based training materials IAW the final approved detailed project plan and training plan on or before the day of training (no lat-er than six months after the detailed project plan is approved or before the SDMS solu-tion goes live).

4.2.9.5. User manual. The Contractor shall deliver a user manual in electronic format that de-scribes the concept of operations for the SDMS and the specific steps a user will per-form to execute system functions.

The Contractor shall provide the user manual IAW the final approved detailed project plan and training plan on or before the day of training (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.9.6. Standard operating procedures. The Contractor shall deliver standard operating proce-dures for the SDMS in electronic format, including the SaaS solution processes and the new Airports Authority processes required to operate the SDMS.

The Contractor shall deliver the standard operating procedures IAW the final approved detailed project plan and training plan on or before the day of training (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.10 SDMS Task 10—Full Implementation and Cutover (Go-Live) Services

The Contractor shall implement the SDMS solution. The Airports Authority prefers an incremen-tal implementation approach to ensure full deployment of the total SDMS solution with Contrac-tor full implement no later than six months after the SDMS COTR approves the final detailed project plan.


Deliver a cutover plan that describes the cutover approach with approval and sign-off by the SDMS COTR.

Implement the system core functions in phases, starting with certification, followed by compliance, goal setting, and outreach.

Monitor operations during the implementation.

Detailed Scope

4-14

Demonstrate the solution to users, including Airports Authority employees and managers, verifying the following:

The solution works using each type of input provided by the Airports Authority.

Accurate data can be produced.

Data transmissions are received and submitted.

System interfaces work.

Resolve any issues that may arise for which the Contractor has responsibility and assist the Airports Authority with resolving other issues identified during implementation.

Obtain authority to go live from the SDMS COTR upon successful implementation of all phases, certifying that the system is ready to become operational.

Cut over and go live after receiving notification from the SDMS COTR to proceed.

Provide post-implementation support a minimum of three months after the system goes live. This does not include recurring O&M activities but does include initial implementa-tion support to ensure optimal operations.


4.2.10.1. Cutover plan and schedule. The Contractor shall deliver a cutover plan and schedule that describe the processes and procedures the Contractor will use to go live (such as run in parallel for some time or turn the new system on and off). The plan should speci-fy the sequence of events for cutover, including data migration, and Contractor and Airports Authority responsibilities. It also should identify potential risks and mitiga-tions and an approach for rollback if necessary.

Implementation depends on completion of the readiness review, so the schedule should indicate the number of days or months from readiness review completion to cutover. The schedule should consider days the Airports Authority is closed, such as federal hol-idays, and busy periods. The SDMS COTR will specify these closure dates and busy periods and must approve the schedule before the start of cutover.

The Contractor shall deliver one draft and one final cutover plan and schedule to the SDMS COTR. The documents shall be delivered IAW the approved final detailed pro-ject plan (no later than six months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.10.2. System readiness review and fully implemented SDMS solution (go-live). The Con-tractor shall review system readiness and deliver a summary of the test results and proof that the system is ready to go live and meets the information assurance and secu-rity requirements. The Contractor shall work with the SDMS COTR to ensure comple-tion of the readiness review and achieve approval to proceed with cutover.

Detailed Scope

4-15

The Contractor shall implement the cutover plan and deliver a fully integrated and con-figured COTS SaaS SDMS solution to the Airports Authority—hosted on the Contrac-tor’s platform—no later than six months after the SDMS COTR approves the final detailed project plan. Contractor

4.2.11 SDMS Task 11—O&M Services Upon full implementation (go-live), the Contractor shall provide O&M support services for the SDMS solution. The Contractor shall provide recurring annual subscription services, including hosting the SaaS software, software patches and updates, SaaS maintenance support, security and SLA support, records and data management, change management, and customer service (help desk) support services. The Contractor shall not begin providing recurring annual SaaS services until after the system has been implemented (go-live). O&M support includes the following:

Hosting support. The Contractor shall provide recurring hosting and secure infrastructure management services.

SaaS patch support. The Contractor shall support the installation of required software patches designed to fix problems with, or update, the SaaS solution or its supporting data. This includes fixing security vulnerabilities and other bugs, configuration management to ensure that changes or fixes are documented and tracked, and improving system usability and performance.

SaaS maintenance support. The Contractor must maintain the Airports Authority–specific SDMS software functionality throughout the life of the contract.

Security and SLA support. The Contractor shall address security and fix breaches and meet or exceed SLAs (Section 5).

Records and data management. The Contractor shall ensure and maintain the quality of data and adhere to data ownership, achieve and retain certification data for the data life cycle and archive date older than 6 years.

Change management. The Contractor shall institute a change control and configuration management process assessed and agreed upon by the SDMS COTR.

Customer service (help desk) support. The Airports Authority has a three-level problem escalation process:

Level 1 support (tier 1)—Airports Authority Technology Service Desk (Techworks)

Level 2 support (tier 2)—Airports Authority power users

Level 3 support (tier 3)—the Contractor’s customer service (help desk).

At the lowest level, SDS users will escalate all issues to the Airports Authority Technol-ogy Service Desk (tier 1). If the issue can’t be resolved there, the Technology Service Desk will escalate the issue to the power users (tier 2). If the power users can’t resolve

Detailed Scope

4-16

the issue, they will escalate the problem to the Contractor’s help desk (tier 3), the highest level for resolution.

The Contractor shall provide tier 3 customer service (help desk) support to assist with system performance issues escalated by the Airports Authority. The Contractor shall ad-here to support requirements referenced in SLA section 5.1.2 incident response time and 5.1.3 incident resolution time.


4.2.11.1. SaaS services support plan. The Contractor shall deliver a support plan that describes how it will host and support the SDMS after system implementation (go-live) over the contract period of performance. The plan also shall include any other support the Con-tractor will provide to operate and maintain the solution, as well as how it will manage patches and upgrades to the SaaS solution and perform records and data management activities to keep the system operational.

The Contractor shall deliver one draft and one final SaaS services support plan to the SDMS COTR. The final document shall be delivered IAW the approved final detailed project plan (no later than 6 months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.11.2. Preliminary transition plan (exit).

Input provided by Procurement

The Contractor shall deliver one draft and one final preliminary transition plan (exit) to the SDMS COTR. The final document shall be delivered IAW the approved final de-tailed project plan (no later than 6 months after the detailed project plan is approved or before the SDMS solution goes live). Contractor

4.2.11.3. Final transition plan (exit).

Input provided by Procurement

The Contractor shall deliver one draft and one final transition plan (exit) to the SDMS COTR. The final document shall be delivered IAW the approved final detailed project plan (no later than 6 months after the detailed project plan is approved or before the SDMS solution goes live).

4.2.12 Supplemental Services The Contractor shall provide services related to the O&M and improvement of the SDMS after the system becomes operational (after the go-live date) as directed by the CO. The services may include the following:

Development of new or modification of current interfaces between the SDMS and other Airports Authority systems

Detailed Scope

4-17

BPR services to assist in the creation of new or modification of current processes relating to the SDMS

Configuration of the SDMS that requires no software code changes.

The Contractor shall provide labor rates for the five labor categories listed below, with the asso-ciated expertise and experience, for providing supplemental services related to the operation, maintenance, and improvement of the SDMS SaaS solution.

Project Leader. Responsible for the execution of small to medium-sized, technically complex projects. Interacts with Airports Authority project managers to report on the cost and schedule status of projects.

Has 5+ years’ experience leading projects and, at a minimum, a bachelor’s degree.

Senior Technical Specialist. Serves as a subject matter expert related to technical aspects of the SDMS. Executes the technical aspects of project tasks, including the development of interfaces using available APIs and configuration of the SDMS that require no soft-ware code changes.

Have 10+ years’ experience developing, customizing, or administering enterprise sys-tems. Bachelor’s degree in computer science or related technical field. 5 years’ additional experience can be used in lieu of a degree.

Technical Specialist. Serves as a subject matter expert related to technical aspects of the SDMS. Executes the technical aspects of project tasks, including the development of in-terfaces using available APIs and configuration of the SDMS that require no software code changes.

Have 2+ years’ experience developing, customizing, or administering enterprise systems. Bachelor’s degree in computer science or related technical field. 5 years’ additional expe-rience can be used in lieu of a degree.

Senior Business Process Reengineering Specialist. Serves as a subject matter expert re-lated to supplier diversity aspects of the SDMS. Executes project tasks, including the de-velopment and implementation of new and improved supplier diversity processes.

Have 10+ years’ experience developing, changing, and implementing supplier diversity processes. Bachelor’s degree. 5 years’ additional experience can be used in lieu of a de-gree.

Business Process Reengineering Specialist. Serves as a subject matter expert related to supplier diversity process aspects of the SDMS. Executes project tasks, including the de-velopment and implementation of new and improved supplier diversity processes.

Have 2+ years’ experience developing, changing, and implementing supplier diversity processes. Bachelor’s degree. 5 years’ additional experience can be used in lieu of a de-gree.

Detailed Scope

4-18

4.2.13 Deliverables Summary Table 4-2 lists the major contract deliverables for which the Contractor is responsible, along with the due dates. The Contractor shall deliver one draft and one final document to the SDMS COTR.

Note 1. Draft documents shall be delivered for review and comment to the SDMS COTR IAW approved deliverable 4.2.1.1, final detailed project plan (no later than six months af-ter the SDMS COTR approves the detailed project plan, or before the SDMS solution goes live). The Airports Authority will provide review comments to the contactor seven calendar days upon receipt of the draft.

Note 2. Final documents shall be delivered to the SDMS COTR for approval no later than seven calendar days after the Airports Authority submits review comments to the Con-tractor IAW the approved final detailed project plan (no later than six months after the SDMS COTR approves the detailed project plan, or before the SDMS solution goes live). The SDMS COTR will have three calendar days to approve the final document.

Note 3. Tasks shall be executed IAW the approved final detailed project plan (no later than six months after the SDMS COTR approves the detailed project plan, or before the SDMS solution goes live).

Table 4-2. SDMS Contract Deliverables

Task Number Title Due Date

4.2.1. Program Management Services

4.2.1.1 Detailed project plan (including risk management plan)

Draft – 15 calen-dar days after the kickoff meeting Final – 7 calendar days after Airports Authority submits review comments

4.2.1.2 Status reporting Weekly after the kickoff meeting

4.2.1.3 Progress meetings Weekly after the kickoff meeting

4.2.2. Requirements Manage-ment Services

4.2.2.1 Requirements management plan Draft – note 1 Final – note 2

4.2.2.2 Detailed requirements document and execution

Note 3

4.2.3. SaaS Solution Configura-tion Services

4.2.3.1 Configuration management plan Draft – note 1 Final – note 2

4.2.3.2 Configuration management plan exe-cution and fully configured SDMS solu-tion

Note 3

4.2.4. Business Process Rede-sign Services

4.2.4.1 BPR plan Draft – note 1 Final – note 2

4.2.4.2 BPR document and plan execution Note 3

Detailed Scope

4-19



4.2.5. Contractor Hosting Ser-vices

None None None

4.2.6. Data Cleansing, Migra-tion, Validation, and Manage-ment Services

4.2.6.1 Data management plan Draft – note 1 Final – note 2

4.2.6.2 Data management plan execution and data migration into SDMS solution

Note 3

4.2.7. Interface Development Services

4.2.7.1 Interface plan Draft – note 1 Final – note 2

4.2.7.2 Interface plan execution, testing and integration of validated and accepted interfaces

Note 3

4.2.8. Testing Services 4.2.8.1 Test plan Draft – note 1 Final – note 2

4.2.8.2 Test plan execution and test reports Note 3 4.2.9. Training Services 4.2.9.1 Training plan Draft – note 1

Final – note 2 4.2.9.2 Training Note 3 4.2.9.2.1 System administrator training Note 3 4.2.9.2.2 Power user training Note 3 4.2.9.3 Written training materials Final – on or be-

fore training date 4.2.9.4 CBT or web-based training Final – on or be-

fore training date 4.2.9.5 User manual Final – on or be-

fore training date 4.2.9.6 Standard operating procedures Final – on or be-

fore training date 4.2.10. Full Implementation and Cutover (Go-Live) Services

4.2.10.1 Cutover plan and schedule Draft – note 1 Final – note 2

4.2.10.2 System readiness review and fully im-plemented SDMS solution (go-live)

Note 3

4.2.11. Operations and Mainte-nance Services

4.2.11.1 SaaS services support plan Draft – note 1 Final – note 2

4.2.11.2 Preliminary transition plan (exit) Draft – note 1 Final – note 2

4.2.11.3 Final transition plan (exit) Draft – note 1 Final – note 2

5.1.1 System Reliability (SLA) 5.1.1.1 Availability report* Monthly and quar-terly after go live date

5.1.1.2 Maintenance schedule* 7 calendar days before the system becomes unavail-able

Detailed Scope

4-20



5.1.1.3 Voluntary product accessibility tem-plate (VPAT)*

Within 7 calendar days of publishing

5.1.2 Incident Response Time (SLA)

5.1.2.1 Response time report (issue notifica-tion)*

Monthly and quar-terly after go live date

5.1.3 Incident Resolution Time (SLA)

5.1.3.1 Incident analysis and resolution report* Monthly and quar-terly after go live date

5.1.4 Hosting Security (SLA) 5.1.4.1 Continuous security monitoring report and C&A security input*

Quarterly after go live date

5.1.5 Disaster Recovery and COOP (SLA)

5.1.5.1 Disaster recovery plan* Draft – note 1 Final – note 2

5.1.5.2 COOP plan* Draft – note 1 Final – note 2

5.1.5.3 Disaster recovery and COOP report* Monthly after go live date

5.1.6 Elastic Scaling (SLA) 5.1.6.1 Usage report* Monthly and quar-terly after go live date

* Section 5 details the deliverable.

5-1

5. Performance Standards and SLAs

The Contractor shall deliver services that meet SDMS performance expectations over the SaaS development life cycle, supporting the entire user experience, including the prompt resolution of operating and system performance issues while maintaining data security and integrity consistent with industry standards.

5.1 SLAS

The following SLAs establish the minimum performance levels the Contractor shall meet to en-sure the SDMS solution meets the Airports Authority’s SOW requirements:

System reliability

Incident response time

Incident resolution time

Hosting security

Disaster recovery and COOP

Elastic scaling

Deliverable quality.

5.1.1 System Reliability The Contractor shall maintain availability and accessibility performance levels to ensure continu-ity of service for the SaaS servers and network:

Availability. The Contractor shall meet system availability requirements and ensure all SDMS components are available for use 24 hours per day, every day, year-round at a ser-vice level of 99 percent. Compliance with the 99 percent service level will not depend on the proper operation of users’ Internet access, so failure to access the SDMS due to Inter-net service outages at the users’ locations will not be held against the Contractor’s ser-vice-level compliance. However, system availability service-level compliance shall be impacted by unplanned and planned downtime.

Downtime is the total time users cannot access the system due to the fault of the Contrac-tor or the Contractor’s service providers. Unplanned downtime is unscheduled downtime due to software, hardware, or network failure or emergency software, hardware, or net-work maintenance or repair. Planned downtime is scheduled downtime for software, hardware, or network maintenance or upgrades:

Performance Standards and SLAs

5-2

The Contractor shall notify users when it plans to make the system unavailable at least 7 calendar days in advance (or longer if practical).

Scheduled downtime shall be allowed during low usage hours as determined by usage statistics except for critical periods specified by the SDMS COTR and high transac-tion periods.

If the SDMS solution or any of its functionality is unavailable, the Contractor shall notify the SDMS COTR, SDMS program manager (PM), and the on-call member of the Airports Authority Technology Service Desk.

If system reliability fails to meet the 99 percent service level for a given month, the Con-tractor shall reduce the subscription cost 10 percent for the month of the service-level non-compliance. For each subsequent month the service level of 99 percent is not met, the Contractor shall reduce the subscription cost another 10 percent. The maximum re-duction will be capped at 40 percent. The reduction percentage will remain in effect until the acceptable service level is met 2 consecutive months; the reduction percentage will reset to 10 percent for the next month the 99 percent service level is not met.

Accessibility. The Contractor shall meet system accessibility requirements, which include users accessing the SDMS using a mobile device such as a tablet or smart phone. Down-time associated only with mobile access shall be considered when evaluating the availa-bility service-level compliance. Accessibility also includes the ability for people with disabilities to effectively access the SDMS. The Contractor shall demonstrate compliance with Section 508 through the completion of a voluntary product accessibility template (VPAT) and provide a copy of and changes to the VPAT to the COTR. The Section 508 standards do not require the installation of specific accessibility-related software or the attachment of any assistive technology devices, but they do require the SDMS to be com-patible with such software and devices.

The Contractor shall provide the following SLA deliverables:

5.1.1.1. Availability report. The Contractor shall deliver monthly and quarterly reliability re-ports to the SDMS COTR demonstrating the system complies with the 99 percent availability SLA. The report shall include downtime notification details, time and dura-tion of the downtime, reason for the system being unavailable, when the system was re-stored, and the accessibility methods affected.

5.1.1.2. Maintenance schedule. The Contractor shall deliver its maintenance schedule. Sched-uled downtime notifications shall be provided to the SDMS COTR at least 7 calendar days before the system becomes unavailable.

5.1.1.3. VPAT. The Contractor shall deliver any new versions of its product’s VPAT to the SDMS COTR within 7 calendar days of publishing.


5-3

5.1.2 Incident Response Time Per Section 4, the Contractor shall provide tier 3 IT support for the SDMS. The Contractor shall promptly respond to requests for support on the basis of the severity of the issue. The Contrac-tor’s response time does not reflect the time in which the Contractor must resolve the problem, but rather the time in which the Contractor must respond and identify a strategy for addressing the request or problem. The Airports Authority is aware that when assessing the criticality of a problem, it is important to ensure the Contractor clearly understands the nature of the problem so that an appropriate response can be determined.

The Airports Authority has defined four classification levels to characterize the seriousness of issues that may be experienced: critical, high, medium, and low. The Contractor shall meet the response rates on the basis of the defined criticality of the technical issue (Table 5-1).

Table 5-1. Incident Response Time Requirements

Level Type Description SLA

1 Critical Issues that directly impact the SDMS, making it inoperative; that severely impact business operations, with no available workaround; or that are criti-cal security problems

30 minutes

2 High Issues that significantly disrupt business operations, with an inadequate workaround, and the SDMS continues to operate

1 hour

3 Medium Issues that moderately or slightly impact the business operations, with an available workaround or alternative, and the SDMS continues to operate

2 hours

4 Low Issues that are a minor inconvenience for the SDMS, that do not impact business operations in any significant way, and that have little or no time sensitivity

1 day

The Contractor shall meet the service level by responding to the necessary percentage of calls (Table 5-1) for each severity level each month. Failure to comply with the service levels in a giv-en month will result in the Contractor reducing its subscription fee for the month 2 percent if the Level 1 service level is not met, 1.5 percent if the Level 2 service level is not met, 1 percent if the Level 3 service level is not met, and 0.5 percent if the Level 4 service level is not met. For each subsequent month that at least 1 response time service level is not met, the corresponding cost will be reduced by the same percentage. The total cost reduction will be capped at 20 per-cent. After the Contractor meets the incident response time service levels for 2 consecutive months, the cost reduction will reset to initial values for the next month an incident response time service is not met.


5.1.2.1. Response time report (issue notification). The Contractor shall deliver monthly and quarterly response time notification detail reports to the SDMS COTR, including the date and time of issue notification, how the issue was identified (Contractor or Airports Authority), the issue, the assessed criticality level, and the response time. The Contrac-tor shall coordinate the delivery of response time reports with the submission of invoic-es to the Airports Authority.


5-4

5.1.3 Incident Resolution Time The resolution time indicates the amount of time by which a technical solution must be achieved or an alternative business solution or work-around must be defined to mitigate an issue. It starts when the Contractor’s support team opens a trouble ticket in the system and ends when the issue is documented as resolved. The required resolution time shall be determined by the criticality level of the reported problem, commensurate with the recovery time objective (Subsection 5.1.5). Table 5-2 shows the SLA values.

Table 5-2. Incident Resolution Time Requirements.

Level Type Description SLA

1 Critical Issues that directly impact the SDMS, making it inoperative; that severely impact business operations, with no available workaround; or that are criti-cal security problems

18 Hours

2 High Issues that significantly disrupt business operations, with an inadequate workaround, and the SDMS continues to operate

2 Days

3 Medium Issues that moderately or slightly impact the business operations, with an available workaround or alternative, and the SDMS continues to operate

4 Days

4 Low Issues that are a minor inconvenience for the SDMS, that do not impact business operations in any significant way, and that have little or no time sensitivity

8 Days

The Contractor is expected to resolve issues within the defined resolution time. Failure to com-ply with the resolution time service level for a given month will result in the Contractor reducing its subscription cost or IT service cost (if priced separately) by 2 percent for the month if the Level 1 service level is not met, 1.5 percent if the Level 2 service level is not met, 1 percent if the Level 3 service level is not met, and 0.5 percent if the Level 4 service level is not met. For each subsequent month, the cost reduction will be another percentage reduction corresponding to the criticality level. The cost reduction will be capped at 20 percent. After the Contractor meets the acceptable performance standard 2 consecutive months, the reduction percentage will reset to initial values for the next month a resolution time service level is not met.


5.1.3.1. Incident analysis and resolution report. The report shall include an analysis of SDMS-related calls to the Contractor’s help desk, how issues are resolved, and the response and resolution times. The Contractor shall provide resolution time details and status of trouble tickets, including the date and time notification was received, required resolu-tion time, issue identified, issue authenticated, actual resolution time, description of the resolution, and user validation that the initial issue was resolved. The report shall also identify trends and common problems with the SDMS and resolution practices. The Contractor shall provide this report monthly and quarterly to the SDMS COTR.


5-5

5.1.4 Hosting Security The Contractor shall ensure policies and practices are in place and implement security measures to safeguard the SDMS solution and its data against security breaches. The Contractor’s security measures shall meet the technical requirements in Appendix A.

The Contractor shall resolve all security incidents as follows:

Physical security (hosting center security). The Contractor shall have measures in place to prevent unauthorized access to the hosting data centers, including surveillance measures (such as cameras and security guards); separately secured racks; and cooling, fire, and flood detection systems for the hosting center.

Infrastructure security (hosting environment security). The Contractor shall secure the hosting environment, including the SaaS software, network, operating system, and serv-ers and have current virus protection, an intrusion prevention system/intrusion detection system (IPS/IDS), event logging and altering, security configuration standards for serv-ers, and security patches and firewalls.

Administrative security. The Contractor shall provide security awareness training for all staff members, have information security policies in place, and have an incident response plan addressing recovering the SDMS SaaS solution and data per the required service levels.

Logical security. The Contractor shall have role-based access controls, applica-tion/database change and event logging, and two-factor authentication for remote ac-cess/remote desktop protocol (RDP) for its employees to access the SaaS system and hosting environment.

Other security. The Contractor shall ensure all required system C&As are current, includ-ing third-party certifications.

The Contractor shall, at minimum, meet the following quality levels for the security SLA:

Average security breach notification time. 30 minutes—the time it takes the Contractor to notify the Airports Authority of security incidents and breaches.

Average time to resolve security incident. 18 hours—the time it takes the Contractor to correct the exploited security vulnerability.


5.1.4.1. Continuous security monitoring report. The Contractor shall deliver a quarterly stand-ard security monitoring report of the SaaS environment to the SDMS COTR. The Con-tractor shall also provide documentation summarizing any security audit findings, describing changes to security C&As, and detailing changes to the Contractor’s hosting environment’s security posture. This documentation shall also detail how the changes affect the security requirements identified by the Airports Authority. Contractors shall


5-6

reference Standard Operating Procedure, Information Security Standard Requirements for SaaS (7/17/15), SEC-DOC-SS001.01.

5.1.5 Disaster Recovery and COOP In case of a catastrophic failure of the Contractor’s infrastructure, the Contractor shall meet the following acceptable quality levels for disaster recovery and COOP procedures to ensure mini-mal disruption of service. The Contractor shall use geographically separated data centers with system redundancy and data backups hosted in at least two of the geographically separated data centers. Geographic separation is defined by distances of 50 miles or more. The Contractor shall demonstrate its disaster recovery and COOP procedure using system redundancy in the event of a disaster.

The Contractor shall meet the following disaster recovery SLAs:

RTO. 18 hours—the maximum allowable length of a single downtime event. By the 18-hour mark, the system shall be restored to an operational status either through failover to a redundant system or through primary system recovery.

RPO. 1 day—the maximum time a data backup will be considered current. If a system failure occurs and recovery includes the use of a data backup, the backup must have been created no more than 1 day before the failure.


5.1.5.1. Disaster recovery plan. The Contractor shall deliver one draft and one final disaster recovery plan to the SDMS COTR. This plan shall explain the system and data backup procedures and backup storage locations, notification procedures, roles and responsibil-ities, and disaster recovery testing processes.

The document shall be delivered IAW the approved final detailed project plan (no later than six months after the final detailed project plan is approved or before the SDMS so-lution goes live).

5.1.5.2. COOP plan. The Contractor shall deliver one draft and one final COOP plan to the SDMS COTR, including an explanation of system redundancy and failover processes, roles and responsibilities, and testing processes.

The document shall be delivered IAW the approved final detailed project plan (no later than six months after the final detailed project plan is approved or before the SDMS so-lution goes live).

5.1.5.3. Disaster recovery and COOP report. The Contractor shall deliver a monthly log of data and system backups, failover events, recovery events, and other information that demonstrates the Contractor is following its disaster recovery and COOP plans.


5-7

5.1.6 Elastic Scaling The Contractor shall provide elastic scaling (fully automated) with the ability to quickly increase or decrease capacity (processing or memory) of the SDMS when needed. This includes the abil-ity to add new user accounts and remove old user accounts.

The Contractor shall establish triggers to monitor the SDMS to meet the following acceptable quality levels:

Simultaneous users. 175—number of users the system shall support at one time.

Simultaneous users increase. 3 percent per year—percentage increase of simultaneous users per year.

Transaction rate. 5,000 per day—maximum number of transactions that the system shall support daily. The typical number of transactions per day will be closer to 1,000.

Transaction rate increase. 3 percent per year—percentage increase of daily transactions per year.


Usage report: The Contractor shall provide a monthly and quarterly report to the SDMS COTR, of the monthly scaling rate, 12-month scaling rate trend, number of unique users monthly, 12-month user trend, number of monthly transactions, 12-month transaction trend, and the number of active accounts as of the end of the month.

5.1.7 Deliverable Quality The Contractor shall deliver all contract deliverables to the SDMS COTR on time and with ac-ceptable quality with minimal rework for acceptance.

The Contractor shall maintain the following SLAs for deliverables:

On-time deliverables. 100 percent—percentage of deliverables the Contractor shall sub-mit on time.

Deliverable quality. 90 percent—percentage of deliverables accepted by the SDMS COTR with no more than one round of rework (defined as one draft and one final).

Table 5-3 summarizes the SLAs and their impact on the Contractor if acceptable quality levels are not met.


5-8

Table 5-3. SDMS SLA Summary

Requiredservice SLAs and performance factors Impact of not meeting SLA

Systemreliability

Availability rate—99% mini-mum24 x 7 x 365 real-time 7 days scheduled downtime notification

The Contractor shall reduce the subscription cost 10% for 1 month if the system reliability fails to meet the 99% service level. For each subsequent month that the service level of 99% is not met, the Contractor shall reduce the subscription cost another 10%. The cost reduction will be capped at 40% until the Contractor meets the 99% service level for 2 con-secutive months. After 2 successful months, the reduction will be reset to 10% for the next month the 99% service level is not met.

Incidentresponse time

Critical—30 minutes High—1 hour Medium—2 hours Low—1 day

The Contractor shall reduce its subscription cost or IT sup-port cost (if it is separately priced) for 1 month 2% if the criti-cal service level is not met, 1.5% if the high service level is not met, 1% if the medium service level is not met, and 0.5% if the low service level is not met. For each subsequent month that at least one response time service level is not met, the reduction will increase according to the criticality level not met. The total cost reduction will be capped at 20% until the Contractor meets the performance standard two consecutive months, at which time the reduction percentage will reset to the initial levels for the next month an incident response time service level is not met.

Incidentresolution time

Critical—18 hours High—2 day Medium—4 days Low—8 days

The Contractor shall reduce its subscription cost or IT sup-port cost (if it is separately priced) for the subsequent month 2% if the critical service level is not met, 1.5% if the high service level is not met, 1% if the medium service level is not met, and 0.5% if the low service level is not met. For each subsequent month that at least one response time service level is not met, the reduction will increase according to the criticality level not met. The corresponding cost reduction will be capped at 20% until the Contractor meets the perfor-mance standard 2 consecutive months, at which time the reduction percentage will reset to the initial levels for the next month an incident resolution time service level is not met.

Hosting security Average security breach notifi-cation time—30 minutes Average time to resolve securi-ty vulnerability—18 hours

Remediation meeting.

Disasterrecovery and COOP

Recovery time objective (RTO)—18 hours Recovery point objective (RPO)—1 day

Remediation meeting and increased reporting.

Elastic scaling Simultaneous users—175 Transaction rate—1,600 daily Transaction increase rate—3%/year



5-9

Table 5-3. SDMS SLA Summary

Requiredservice SLAs and performance factors Impact of not meeting SLA

Deliverablesubmitted on time and within qualitystandards

On-time deliverables—100% submitted on time Deliverable quality—90% sub-mitted with no more than 1 round of rework


5.2 SLA MANAGEMENT

The Airports Authority will implement the following practices for managing SLAs entered into with the Contractor. The Airports Authority will monitor performance for each SLA monthly on the basis of SLA performance reports submitted by the Contractor. The monthly evaluation peri-od will begin the first day of the calendar month and end the last day of the calendar month.

At the end of each quarterly performance period (3 months), the SDMS COTR will host an SLA remediation meeting with the Contractor. The purpose of the meeting is to review actual Con-tractor performance against performance SLAs for the quarter, review remediation measures if the Contractor fails to meet SLAs, agree on adjustments required for Contractor invoices, and formally identify recurring performance issues and attempt to resolve them. The Contractor shall provide credits to the Airports Authority on the next invoice on the basis of the calculated in-voice remediation adjustments.

The quarterly SLA remediation meeting will also be used to review the number of active user accounts. This number will be used to determine invoice adjustments associated with changes in the overall subscription count.

5.2.1 Terms for Nonperformance Contractor nonperformance for the established SLAs may result in the following remediation actions:

Increased surveillance or increased Contractor reporting when performance is below standard for a given period.

Remediation sessions with the COTR and CO to determine why it is not meeting the per-formance standards established in the contract.

Payment adjustments as detailed in this SOW.


5-10

5.2.2 Terms of Changes to SLAs The following procedures will govern changes to the SLA:

Review of agreement. The SLA shall be reviewed and formally renewed annually.

Amendment to the agreement. Any amendment to the terms and conditions of the SLA requires approval by the SDMS CO and COTR. Periodic status meetings shall be used to introduce routine amendments.

Termination of SLA agreement. When the SDMS COTR/CO determines that the SLA agreement is no longer required, the SDMS COTR/CO will send a 90-day written notice of intent to terminate the SLA to the SDMS PM and the Contractor. The notice will de-scribe the circumstances for terminating the SLA and allow time for analysis and concur-rence or further discussion between the SDMS COTR/CO and the Contractor.

A-1

Appendix A – Detailed Requirements

Table A-1-SDMS Functional Requirements

Req.# Focus Area Requirements Description

MustHave

In Existing COTSSaaS

Software

Requires Software

Configuration Comments1. Certification The system shall provide an online registration pro-

cess for businesses to apply for DBE/ACDBE/LDBE/SBE certification.

Yes

2. Certification The system shall provide definitions of all business terms and acronyms to the certification applicants.

Yes

3. Certification The system shall provide a DBE/ACDBE applica-tion template compliant with 49 CFR Part 23 and Part 26.

Yes

4. Certification They system shall allow document uploads by certi-fication applicants as part of the certification appli-cation processes including for tax returns and affidavit.

Yes

5. Certification The system shall provide an online registration pro-cess for businesses to apply for LDBE certification.

Yes

6. Certification The system shall allow businesses to save incom-plete certification applications and complete them at a later time.

Yes

7. Certification The system shall purge incomplete applications that were last saved more than 3 months in the past.

Yes

8. Certification The system shall prevent the submission of incom-plete certification applications based on incomplete data fields and failure to upload the necessary doc-uments.

Yes

9. Certification The system shall prevent changes to a certification application by the applicant once the application has been successfully submitted.

Yes


A-2



MustHave


Software

Requires Software

Configuration Comments10. Certification The system shall allow the MWAA certification spe-

cialist to allow a certification application to be re-vised by the applicant by indicating application deficiencies exist.

No

11. Certification The system shall track all types of applications (DBE, ACDBE, SBE, and LDBE) from receipt to approval.

Yes

12. Certification The system shall give MWAA certification special-ists the ability to review, approve, and deny certifi-cation applications.

Yes

13. Certification The system shall track the certification application review process duration. The review process starts upon successful submission of an application by a business.

Yes

14. Certification The system shall notify MWAA certification special-ists when new certification applications have been submitted and are ready for review.

Yes

15. Certification The system shall notify MWAA certification special-ists when a DBE/ACDBE application review is 30, 60, 90 days old, when an interstate DBE/ACDBE application review is 30, 50, 60 days old, and when a LDBE application review is 10, 20, 30 days old.

Yes

16. Certification The system shall allow MWAA certification special-ists the ability to generate deficiency notices for a certification application. Deficiencies include, but are not limited to, un-notarized affidavits and in-complete documents.

Yes

17. Certification The system shall provide status reports detailing the number of deficiency notices sent to certifica-tion applicants.

No


A-3



MustHave


Software

Requires Software

Configuration Comments18. Certification The system shall determine if a LDBE certification

applicant’s address is more than 100 miles away from the Washington DC zero mile-marker. The system shall notify the MWAA certification specialist if the applicant’s address is over 100 miles away from the Washington DC zero mile-marker.

Yes

19. Certification The system shall calculate Annual Gross Receipts (AGR) for a certification applicant including its affili-ates and subsidiaries.

Yes

20. Certification The system shall determine if an applicant’s AGR is above the allowable threshold for the correspond-ing certification small business size standard.

Yes

21. Certification The system shall notify the MWAA certification spe-cialist if an applicant’s AGR is above the threshold value for the corresponding certification.

Yes

22. Certification The system shall generate certification denial let-ters with signatures of appropriate MWAA officials and send them to certification applicants.

No

23. Certification The system shall track when a certification denial notification was sent to the certification applicant and indicate if the denial can still be appealed.

No

24. Certification The system shall generate certification approval letters with certification type, approved NAICS codes, and signatures of appropriate MWAA offi-cials and send them to certification applicants.

Yes

25. Certification The system shall track all suppliers’ present net worth (PNW) and Annual Gross Receipts (AGR) by year for up to 10 years.

No

26. Certification The system shall provide a real time, online directo-ry of xDBE-certified suppliers searchable by suppli-er name, current certification type, keyword, NAICS and NIGP codes, description, and last certification date.

Yes


A-4



MustHave


Software

Requires Software

Configuration Comments27. Certification The system shall generate a downloadable version

of certification directory searches upon request by the user.

Yes

28. Certification The system shall have the capability to cross-reference and automatically track contracts and vendors based on NAICS and NIGP codes, and owner names.

No

29. Certification The system shall have computerized and/or mobile capability to take notes and otherwise complete the site visit report.

No

30. Certification The system shall monitor the appeals process of an application.

No

31. Certification The system shall have one centralized database used by all parties (DSD, Procurement, and Busi-ness Owners).

Yes

32. Certification The system shall notify certified suppliers 90 days, 60 days, and 30 days before LDBE certification expiration and 90 days, 60 days, and 30 days be-fore DBE annual update anniversary. The notifica-tion should include instructions for maintaining certification.

Yes

33. Certification The system shall track the certification status of all businesses in the certification database including businesses denied certification and businesses that have allowed their certification to lapse.

Yes

34. Compliance The system shall provide a data collection and re-trieval tool to calculate overall 3 year DBE and ACDBE goals reported to the FTA.

No

35. Compliance The system shall track all solicitations released by MWAA.

No

36. Compliance The system shall track all bids on a solicitation in-cluding the prime bidder and all sub bidders on a bid.

Yes


A-5



MustHave


Software

Requires Software

Configuration Comments37. Compliance The system shall track contracts awarded by

MWAA including, but not limited to the following information: contract #, prime Contractor, program type, contract type (LDBE/DBE), award date, period of performance, contract value, and LDBE/DBE participation goal.

Yes

38. Compliance The system shall track task orders awarded under task order contracts.

Yes

39. Compliance The system shall submit automatic alerts to DSD of contracts awarded by Procurement.

No

40. Compliance The system shall allow MWAA compliance special-ists to link contracts to their corresponding solicita-tions.

Yes

41. Compliance The system shall allow Airports Authority personnel to search for LDBE suppliers using the directory (limited access).

No

42. Compliance The system shall allow online submission for prime bids to submit Exhibit D.

Yes

43. Compliance The system shall generate Exhibit E document for each sub bidder identified in an Exhibit D.

Yes

44. Compliance The system shall create PDF files of the Exhibit D and Exhibit E that can be downloaded by the prime bidder.

No

45. Compliance The system shall allow updates to Exhibit D and Exhibit E documents when a contract modification is made.

Yes

46. Compliance The system shall provide an Exhibit J form online for prime Contractors to enter on a monthly basis for each active contract or task order.

Yes

47. Compliance The system shall auto-populate appropriate Exhibit J information from corresponding Exhibit D.

Yes


A-6



MustHave


Software

Requires Software

Configuration Comments48. Compliance The system shall notify the MWAA compliance

specialist when a new Exhibit J is submitted. Yes

49. Compliance The system shall allow the MWAA compliance spe-cialist the ability to review and approve Exhibit J submissions.

Yes

50. Compliance The system shall generate approve/denial notifica-tions based on the MWAA compliance specialist’s review and send to CO and COTR.

No

51. Compliance The system shall, upon approval of an Exhibit J, notify subcontractors identified in Exhibit J that payment verification is required.

Yes

52. Compliance The system shall provide an online form for sub-contractors to verify payment including the date of receipt and amount received.

Yes

53. Compliance The system shall notify the MWAA compliance specialist when payments are not received by sub-contractors within deadline.

No

54. Compliance The system shall have the ability online to produce accurate reports on all contracts awarded such total amount for all contracts vs amount to DBE, LDBE, ACDBE, SBE, MBE, WBE firms.

Yes

55. Compliance The system shall provide an online module for Primes to enter monthly payments. Payments can be tracked in real-time and verified with subcontrac-tors.

Yes

56. Compliance The system shall provide an online module with capability to produce customized reports on com-pliance with DBE/LDBE financial goals.

Yes

57. Compliance The system shall provide an online dashboard re-porting current status of DBE/LDBE goals.

Yes

58. Outreach The system shall send e-mails to businesses for upcoming and future outreach events.

Yes


A-7



MustHave


Software

Requires Software

Configuration Comments59. Outreach The system shall allow prime Contractors and

MWAA purchasing agents to search the certified supplier directory by supplier attributes including, but not limited to, NAICS code, NIGP code, suppli-er’s number of employees, and location. The output of these searches must include the suppliers’ con-tact information.

No

60. Outreach The system shall have an outreach module that allows the planning and status of outreach events such as budget, contacts, mailing list, timeline, and documents.

No

61. Outreach The system shall have the ability to follow-up and conduct a survey of outreach events.

No

62. Outreach The system shall create campaigns and add sup-pliers based upon certification status, NAICS/NIGP code, location.

No

63. Outreach The system shall track other small/disadvantaged business certifications from accredited certifying agencies including, but not limited to, the National Minority Supplier Development Council, Women’s Business Enterprise National Council, National Gay and Lesbian Chamber of Commerce, Small Busi-ness Administration, and Department of Transpor-tation.

No

64. Vendor Management

The system shall provide self management and registration by vendors.

Yes

65. Vendor Management

They system shall search the extensive vendor database and generate comprehensive reports.

Yes


A-8

Table A-2. SDMS Technical Requirements

Req.# Requirement

ISO 25010 Characteristic

ISO 25010 Sub characteristic

In the Service Offering

Requires Configuration of the Service

Offering Comments

1. The system shall maintain a virtual pri-vate network (VPN) connection to MWAA’s network to allow for system interfaces.

Compatibility Interoperability

2. The system shall include documented application programming interfaces (APIs) to support system interfaces. The APIs must support one or more of the following: REST, SOAP, or JSON-based web services.


3. The system shall exchange any XML content using an industry standard schema or a custom schema that is fully documented.


4. The system shall use MWAA’s ETL solu-tion when needed to implement interfac-es to MWAA systems.


5. The system shall generate a log of all system errors during system operation. This log shall be made accessible to MWAA’s system administrators.

Maintainability Analyzability

6. The system shall allow MWAA system administrators to create, update, and delete new data fields, workflows, and related business rules without the need to modify base software code.

Maintainability Modifiability


A-9


Req.# Requirement





Offering Comments

7. The system shall have a production en-vironment, a test environment, and a development environment. The produc-tion environment will serve as the opera-tional environment for end users. The test environment will be used to perform unit testing as well as user-acceptance testing. The development environment will be used by system administrators to create new customizations.


8. The system shall support customization migration between the development en-vironment, test environment, and pro-duction environment.


9. The system shall support replication of environment between the development environment, test environment, and pro-duction environment.


10. The system shall support 175 concurrent users without noticeable performance degradation.

PerformanceEfficiency

Capacity

11. The system shall support a minimum of 5000 transactions a day including certifi-cation application transactions.


Capacity

12. The system shall provide usage statis-tics reports on a weekly, monthly, and yearly basis.


Capacity

13. The system shall be fully compatible with future updates to common PC web browsers including, but not limited to, Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, and Apple Sa-fari.

Portability Adaptability


A-10


Req.# Requirement





Offering Comments

14. The system shall be fully compatible with all common PC web browsers in-cluding, but not limited to, Microsoft In-ternet Explorer, Google Chrome, Mozilla Firefox, and Apple Safari.

Portability Installability

15. The system vendor shall recognize that all MWAA certification data, contract data, and reports stored in the system are the property of MWAA.

Portability Replaceability

16. The system shall maintain an up-time availability of 99%.

Reliability Availability

17. The system shall provide downtime noti-fication details including time and dura-tion for all scheduled downtimes. The downtime notification shall be provided at least 7 days before scheduled down-time.


18. The system shall maintain all vendor certification records and reports in ac-cordance with MWAA record retention policy.


19. The system shall integrate with MWAA printers to allow the printing of records and other relevant information.


20. The system shall support redundant hosting with failover in the event of infra-structure failure at one hosting site.

Reliability Fault Tolerance

21. The system shall roll-back any database changes associated with a transaction if that transaction does not complete suc-cessfully.

Reliability Fault Tolerance


A-11


Req.# Requirement





Offering Comments

22. The system shall support redundant hosting in geographically separated lo-cations to support recovery from disaster in one geographic location.

Reliability Recoverability

23. The system shall perform database back-ups to support a recovery point objective (RPO) of 1 day. The database back-ups should be stored in at least 2 geographically separated locations.

Reliability Recoverability

24. The system shall authenticate MWAA users by integrating with Microsoft Azure Active Directory, MWAA’s Identity and Access Management System.

Security Authenticity

25. The system shall support user-created accounts for suppliers in support of certi-fication application, certification renewal, and contract reporting. The user-created accounts shall be password protected.

Security Authenticity

26. The system shall employ HTTP over TLS communications protocol (https or secure http).

Security Confidentiality

27. The system shall employ role-based access controls to data.


28. The system shall employ user-based access controls to data.


29. The system shall encrypt all data both in the operational database and data backups.


30. The system shall encrypt all data during transit between systems and to client computing devices.



A-12


Req.# Requirement





Offering Comments

31. The system shall transfer all files using the SFTP protocol.


32. The system shall employ role-based access controls to define transaction permissions such as data CRUD per-missions.

Security Integrity

33. The system shall detect and log intru-sion attempts. The log shall be accessi-ble by MWAA system administrators.

Security Integrity

34. The system shall include intrusion pre-vention system technology.

Security Integrity

35. The system shall include virus and mal-ware prevention technology.

Security Integrity

36. The system shall maintain metadata on all transactions for the lifetime of the effected record. The metadata should include the User ID executing the trans-action, the timestamp of the transaction, and what was changed.

Security Non-repudiation

37. The system shall support electronic sig-nature for all necessary approvals and signatory actions.

Security Non-repudiation

38. The system shall comply with all acces-sibility standards regarding web-based intranet and internet systems enumerat-ed in Section 508 of the Rehabilitation Act.

Usability Accessibility

39. The system shall be accessible from both the MWAA intranet and world wide web.



A-13


Req.# Requirement





Offering Comments

40. The system shall be accessible from personal computers, tablets, and smart phones.


41. The system shall allow system adminis-trators to add custom MWAA branding to the user interface.

Usability Appropriateness Recognizability

42. The system shall allow system adminis-trators to edit data field names to terms recognized by MWAA staff.

Usability Appropriateness Recognizability

43. The system shall include self-help train-ing materials.

Usability Learnability

44. The system shall allow system adminis-trators to customize the color palette of the user interface to correspond with MWAA preferences.

Usability User Interface Aesthetics

B-1

Appendix B –System Interfaces

Interface Name

Interface Description (including description of information exchanged, schemas/file formats used, etc.)

SourceSystem

Source on AirportsAuthorityIntranet?

TargetSystem

ReceivingSystem (Sink) on Airports Authority In-tranet?

InterfaceType

Exchange Frequency

Comments / Notes

1. Upload of all awarded (Prime)con-tracts/Updates on all con-tracts/Payment updates

This interface shall be used to send Contract number, Prime Company Name, Program Type, Contract Award Date, Contract End Date, De-scription, Original Con-tract Amount, Current Contract Amount, Pay-ments, Modifications, New Contracts, Payments made by Accounts Paya-ble

OracleERP

Yes SDMS No TBD Every Week Procurement enters the awarded con-tracts into Oracle ERP; therefore, al-lowing the contracts to also appear in EOP I

2. AC/DBE Directory

This list is used to gather new ACDBE and DBE vendors certified each month

SupplierDiversitySystem

No VSBSD No (S)FTP Every Month None

3. AC/DBE Directory

This list is used to gather new ACDBE and DBE vendors certified each month by VSBSD

VSBSD No Supplier Diversity

Yes (S)FTP Every Month System must distin-guish between VSBSD certified firms and Airports Authority certified firms

4. ACDBE Conces-sions partic-ipation

System will be used to capture concessions data by contract/lease. Cap-ture Contractor name, address, location, con-cession type, monthly gross receipts, lease

Prop-Works

Yes SDMS No TBD TBD None

System Interfaces

B-2

Interface Name

Interface Description (including description of information exchanged, schemas/file formats used, etc.)

SourceSystem

Source on AirportsAuthorityIntranet?

TargetSystem

ReceivingSystem (Sink) on Airports Authority In-tranet?

InterfaceType

Exchange Frequency

Comments / Notes

start/end date, certifica-tion status (ACDBE/Non-ACDBE, MBE/WBE, oth-er)

5. Vendor Da-ta Ex-change

The exchange of all ven-dor data from SDMS to Oracle ERP

SupplierDiversitySystem

No Oracle ERP

Yes TBD Every Week Contact information, Tax ID numbers, NAICS/NIGP codes, certification type

6. Vendor Da-ta Ex-change

The exchange of all ven-dor data from Oracle ERP to SDMS

OracleERP

Yes SDMS No TBD Every Week Contact information, Tax ID numbers, NAICS/NIGP codes, certification type

C-1

Appendix C –Target State Process Flows

C1. DBE Certification

Target State Process Flows

C-2

C2. LDBE Certification


C-3

C3. DBE Renewal Process or Annual Update


C-4

C4. Compliance

C5. Outreach: Vendor Registration

D-1

Appendix D –Capability Model

E-1

Appendix E - Initial Service Level Agreements (checklist)

Required Service SLAs and performance factors

Remediation (Impact of Not Meeting the SLA)

ExceedsSLA

MeetsSLA

NotMeetSLA Comments

1. System reliability Availability rate–99% minimum

24 x 7 x 365 real-time 7 days scheduled

downtime notification

The Contractor shall reduce the subscription cost 10% for 1 month if the system reliability fails to meet the 99% service level. For each subsequent month that the service level of 99% is not met, the Con-tractor shall reduce the subscription cost another 10%. The cost reduc-tion will be capped at 40% until the Contractor meets the 99% service level for 2 consecutive months. Af-ter 2 successful months, the reduc-tion will be reset to 10% for the next month the 99% service level is not met.

2. Incident response time

Critical–30 minutes High–1 hour Medium–2 hours Low–1 day

The Contractor shall reduce its subscription cost or IT support cost (if it is separately priced) for 1 month 2% if the critical service level is not met, 1.5% if the high service level is not met, 1% if the medium service level is not met, and 0.5% if the low service level is not met. For each subsequent month that at least one response time service level is not met, the reduction will increase according to the criticality level not met. The total cost reduc-tion will be capped at 20% until the Contractor meets the performance standard two consecutive months, at which time the reduction per-centage will reset to the initial levels for the next month an incident re-sponse time service level is not met.


E-2



ExceedsSLA

MeetsSLA

NotMeetSLA Comments

3. Incident resolution time

Critical—18 hours High—2 day Medium—4 days Low—8 days

The Contractor shall reduce its subscription cost or IT support cost (if it is separately priced) for the subsequent month 2% if the critical service level is not met, 1.5% if the high service level is not met, 1% if the medium service level is not met, and 0.5% if the low service level is not met. For each subsequent month that at least one response time service level is not met, the reduction will increase according to the criticality level not met. The cor-responding cost reduction will be capped at 20% until the Contractor meets the performance standard 2 consecutive months, at which time the reduction percentage will reset to the initial levels for the next month an incident resolution time service level is not met.

4. Hosting security Average security breach notification time–30 minutes

Average time to re-solve security vul-nerability–18 hours


5. Disaster recovery and Continuity of Op-erations

Recovery time objec-tive (RTO)–18 hours

Recovery point objec-tive (RPO)–1 day

Remediation meeting and in-creased reporting.

6. Elastic scaling Simultaneous users–175

Transaction rate–1,600 daily

Transaction increase rate–3%/year



E-3



ExceedsSLA

MeetsSLA

NotMeetSLA Comments

7. Deliverable submitted on time and within quality standards

On-time deliverables–100% submitted on time

Deliverable quality–90% submitted with no more than 1 round of rework


F-1

Appendix F –Supplier Diversity Reports

Function Area Report Title Recipient / Description Frequency

Certification Applications Received Report To DSD DBE/LDBE applications received for processing (by firm name and type) and current status of applications

Daily

Certification Certified or Recertified Firms by Name

To DSD Firms certified or recertified by type of certification for a speci-fied time period. Internal DSD management report

Daily

Certification Management Aging Report To DSD DBE/LDBE applications in process by firm, type, days in pro-cess. Management tool to ensure DSD compliance with certifi-cation processing timelines

Daily

Certification Management Summary Report To DSD Summary report of DBE/LDBE completing certification during a specified time period based on approvals, denials, de-certifications, re-certifications, and annual updates

Daily

Certification Renewal Request Report To DSD DBE/LDBE firms by certification expiration date and/or annual update (DBE). Internal DSD report used to notify firms of pend-ing expiration dates 30, 60, 90 days in advance

Monthly

Compliance NAICS/NIGP Code, AGR, Em-ployee Report

To DSD Currently certified DBE/LDBE firms by NAICS and/or NIGP code, Annual Gross Receipts (AGR) and Number of employ-ees (ANE). Used as a sourcing report for DSD, COTRs, COs and other MWAA internal users

Daily

Compliance Uniform Report of DBE Awards/Commitment/Payments (DCA/IAD)

To FAA Two separate reports; one for each airport; the parameters/ data for the report are defined by DOT 49 CFR part 26 (DBE)

Annual

Compliance Uniform Report of ACDBE Awards/Commitments/Payments (DCA/IAD)

To FAA Two separate reports; one for each airport; the parameters/ data for the report are defined by DOT 49 CFR part 23 (ACDBE)

Annual

Compliance Uniform Report of DBE Awards/Commitment/Payments (DCMP Phase 1)

To FTA Parameters/data for the reports are defined by DOT 49 CFR part 26

Semi-annual

Compliance Uniform Report of DBE Awards/Commitment/Payments (DCMP Phase 2)

To FTA Parameters/data for the reports are defined by DOT 49 CFR part 26

Semi-annual

Compliance Small Business Contracting Summary Report

To the Airports Authority Board of Directors Small business contracting/ achievement for non-concessions contracts. Reports overall LDBE/DBE participation on all active contracts

Quarterly

Initial Service Level Agreements (checklist)

F-2

Function Area Report Title Recipient / Description Frequency

Compliance ACDBE Concession Achieve-ments

To the Airports Authority Board of Directors ACDBE participation in airport concessions contracts; includes ACDBE participation by concession type and achievement against goals

Annual

Compliance ACDBE Concession Achieve-ments (DCA/IAD)

To the Airports Authority Board of Directors ACDBE participation in airport concessions contracts; includes ACDBE participation by concession type and achievement against goals

Annual

Compliance DBE/LDBE Achievement Report To DSD DBE and/or LDBE achievement based on commitments for individual contracts (data from Exhibits D & J). A cumulative report of all active contracts

Daily

Compliance Daily Commitment Transaction Report

To DSD DBE/LDBE commitment by contract (a profile sheet on each contract) and all DBE/LDBE participation committed (data from Exhibit D). A contract-specific report

Daily

Compliance Committed vs Actual Achieve-ment Report

To DSD DBE/LDBE achievement compared to actual payments by in-dividual contract (a profile sheet on each contract). A contract-specific report

Daily

Compliance Payment to Subcontractors Re-port

To DSD Payments to subcontractors by individual subcontractor. Tracks a subcontractor’s participation on multiple contracts in a single report

Daily

Outreach Outreach Event Summary Re-port

To Airports Authority Management Summary report of hosted/attended outreach events

As needed

Outreach Outreach Event Detail Report To Airports Authority Management Detail report by event of outreach event activities, materials, contacts, follow-up actions

As needed

metropolitan washington airports authority … · istandard operating procedure, information...

Documents