FBODaily.com | FedBizOpps: MOD | D | Agency Workload Management System (AWLS) acquisition

FBO DAILY - FEDBIZOPPS ISSUE OF OCTOBER 22, 2015 FBO #5081
MODIFICATION

D -- Agency Workload Management System (AWLS) acquisition

Notice Date: 10/20/2015
Notice Type: Modification/Amendment
NAICS: 541511 — Custom Computer Programming Services
Contracting Office: Defense Logistics Agency, DLA Acquisition Locations, DLA Contracting Services Office - Philadelphia, 700 Robbins Avenue, Philadelphia, Pennsylvania, 19111-5096, United States
ZIP Code: 19111-5096
Solicitation Number: SP4701-16-R-8889
Archive Date: 12/4/2015
Point of Contact: John Dormer, Phone: 2679811765, Robert Tomczak, Phone: 215-737-2257
E-Mail Address: john.dormer@dla.mil, Robert.Tomczak@dla.mil
(john.dormer@dla.mil, Robert.Tomczak@dla.mil)
Small Business Set-Aside: N/A
Description: Description: PURPOSE: The purpose of this Request for Information (RFI) is to conduct market research seeking to identify vendors who would be interested in offering on a forthcoming Request for Proposal (RFP) for the Defense Logistic Agency’s Operations Research and Resources Analysis (DORRA) Agency Workload Management System (AWLS) acquisition. This RFI is issued solely for information and planning purposes and does not constitute a formal Request for Proposal, or promise to issue a solicitation in the future. Respondents are advised that the Government will not pay for any information or administrative costs incurred in responding to this RFI. All inquiries must be submitted in writing via email to john.dormer@dla.mil. The Government will not entertain any requests to meet individually with a contractor, and will not respond to any telephonic inquiries. Please see the below capabilities and requirements for a description of the possible acquisition. Target Audience: All Interested Businesses AGENCY WORKLOAD LEVELING SYSTEM (AWLS) Summary/Background: The staffing process prior to Enterprise Business System (EBS) was for DLA HQ and field activities to request full time equivalents (FTE) based upon programmatic requirements. This concept involved regulating their FTEs based on workload. In addition, DLA Operations Research and Resources Analysis (DORRA) managed the Defense Integrated Management Engineering System (DIMES) for work measurement and standards, as well as the Labor and Production Effectiveness Reporting System (LAPERS) which compiled time and attendance information and measured it against standards. DIMES is comprised of standards that represent the time it takes to do a specific job. LAPERS was a DLA unique reporting system which integrated DIMES data with report output from other DLA systems. Over time, DLA went from a reactive hourly/resource approach to an activity based costing system. The activity based costing system is a costing methodology that identifies activities in an organization and assigns the cost of each activity with resources. As a result, DLA lost all assets for staffing models to assist the supply chains with work allocation, workforce planning, and end user alignment. The implementation of the Enterprise Business System (EBS) changed many business processes and job roles. Those process changes will allow DLA to take a proactive approach in using the hourly/resource method for workload productivity. In the interim, DORRA developed a staffing model tool that was specifically tailored for each PFLA organization. The DORRA staffing models are developed using Excel spreadsheets to provide an annual FTE estimation based on work processes. The Excel spreadsheets are reviewed annually and recalculated to fit the model for the next year. In addition, DLA Distribution continues to maintain and use their productivity-based model that determines estimated FTE requirements using projected workload and productivity goals. DLA Distribution is working towards enhancing their tool to utilize engineering labor time standards as a basis for their staffing estimates. Current Environment DLA Distribution developed an in-house Access database to manage staff production. The Access database imports completed workload tasks from an external data system called Distribution Standard System (DSS). These data imports are manually done by the J4-BT Standardization team on a specified day. The supervisor must use functionality in the database which allows him to enter the hours the employee spent working on the task. The database can output two reports. The first report is used to track an individual performance summary. The second report is a team efficiency report. The tool automatically recalculates its performance metrics based on the last load. The system context diagram below shows how the system currently works. DLA Aviation developed an in-house Excel spreadsheet to monitor individual and team performance. Personnel update the Excel spreadsheet with a list of completed tasks weekly. Once those spreadsheets have been updated the manager can run weekly performance reports (employee utilization report and performance goal). Division leaders can look at higher level reports that provide visibility throughout the organization. The context diagram below shows how the system works. DLA Land and Maritime has developed two in-house Access databases Long Term Contract (LTC) and Disciplined Production Control ( DPC) to manage staff performance. Land and Maritime technical support team manually exports data using a combination of queries from SQVI, BEX/BI, and SAS. Those extracts are then loaded into the database. Team leads assign work to employees using these tools. Employees are provided a work management view of assigned work. As work is completed, employees update the assigned purchase request. Reporting capability is available to team and division leads. The table below shows how the system works. Table 1 : Current Environment Current Environment [Agency/# of Users] Software MS Excel Workload Prioritization Aviation/ 50 MS Excel Employee Work Aviation/ 200 MS Access Database DPC L&M/200 Distribution StandardsPro Distribution/ 100 Distribution StaffPlanPro Distribution / 100 Users MS Access Distribution Workload Performance Distribution / 100 Users SAS Data Sources SQVI L&M Data Extracts BEX/BI L&M Data Extracts JDA Distribution EBS DSS DORRADW Objectives DLA requires an Agency Workload Management system that meets the objectives listed below. a. Business Objectives Information systems that will help organizations properly staff their workforce to meet strategic and operational objectives. By developing such a system, DLA can improve productivity and efficiency through computerized algorithms that will allow DLA to function as a highly optimized agency. b. Technical Objectives A web based information system with mobile functionality. c. Service Objectives The AWLS solution with the necessary redundancy, resiliency, and contingency capabilities to ensure service availability that meets DLA’s current and future needs. d. Security Objectives The AWLS solution should has prerequisite security controls and requirements in accordance with the DLA Policy. e. Management & Administrative Objectives The AWLS solution with cost effective, responsive, and efficient management and customer support. f. Integration Objectives The AWLS solution with necessary integration services to extend the AWLS solution to related applications. g. Section 508 Compliance IT products and services developed in response to this Performance Works Statement are required to comply with Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d), which requires Federal agencies acquiring electronic and information technology to ensure that Federal employees with disabilities have access to and use of information and data that are comparable to the access and use by Federal employees who are not individuals with disabilities. Scope Of Work The contractor shall provide DLA Information Operations (J6) with a real time automated information system, Agency Workload Leveling System (AWLS). The AWLS shall trace specific work processes and associated time standards, allowing management to adjust assigned workload and resources across the workforce. The system shall have the ability to accurately measure and report production across DLA, as well as forecast workload based on historical data or projected future volume data. The enterprise tool shall provide reporting capability allowing DLA to monitor productivity and efficiency from the lowest possible level and provide visibility at the highest possible level. Requirements High Level Requirements Number High Level Requirements High Level Outcome Title High Level Outcome Description 1 Up to date reports with immediate response times Immediate Response Time Provide an up to date reporting/visibility view of work item/task 2 Ability to provide customized reports Customized reports The ability for users to customize reports 3 Provided mobile devices integrated into system. Mobile Functionality Ability to utilize mobile devices to navigate through system. 4 Ability to integrate with external systems Integrates with external systems. Ability to be integrated with external DLA systems (DSS, EBS, Eagle) 5 Ability to maintain DLA Policy and Procedures for IT Services Maintain DLA Policy and Procedures Maintain DLA Policy and Procedures 6 Ability to provide engineering labor standards Provides engineering labor standards Provide an enterprise labor standard for DLA 7 Recalculate engineering labor standards based on data pulls and task completeness Recalculate Labor Standards Ability to recalculate engineering labor standards based on data pulls, task completeness, and current labor standards. 8 Provide role based user access (security) User Security and Roles Provide role based user access (security) By Employee – employee based performance Supervisor – Team Visibility Division Lead – Division Visibility HR Reps – Position Visibility Director – Organization Visibility 9 Ability to provide work item/task status Work Item Status Ability to provide work item/task status. Complete In-progress Unassigned 10 Provide real time reporting Real Time Reporting Ability to provide real time reporting Ad Hoc reporting Employee work counts 11 Provide real time data visualization Pie Charts Bar graphs Real Time Data Visualization Ability to provide real time data visualization Pie Charts Bar graphs 12 An automated data pull of unassigned warehouse work Automated Warehouse Data Load An automated data pull of unassigned warehouse work items/task list below: Pick Pack Receive Store 13 Ability to update unassigned warehouse work item/task status. Update Work Items Ability to update unassigned warehouse work item/task status. (Complete, in-progress, cancelled) 14 An automated data pull of unassigned e-procurement data Automated procurement request data An automated data pull of unassigned e-procurement data for the types listed below: LTC SAT MICRO LARGE 15 An automated data pull of unassigned e-procurement phases. Automated procurement phases An automated data pull of unassigned e-procurement phases list below: Pre-Solicitation Solicitation Evaluation Awards Cancellation 16 View team workload of unassigned task View team workload Ability to view team workload of assigned task 17 A what-if analysis of assigning task What-if Analysis Ability to view a “what-if” analysis of assigning task 18 Team visibility reports for division level Team visibility Visibility over team with various reports list below Performance monitoring Trend/forecast analysis Individual employee analysis 19 Ability to edit standards Edit engineering standards Ability to edit engineering standards 20 Ability to edit performance measurements Edit performance measurements Ability to edit performance measurements 21 Ability to assign e-procurement unassigned task to employees Assign procurement task Ability to assign e-procurement unassigned task to employees 22 Ability to assign warehouse unassigned work item/task to employees Assign warehouse task Ability to assign warehouse unassigned work item/task to employees Detailed Requirements Requirement ID Requirement 1 The system shall automatically receive data pulls from DSS for workload data(fields to be determined at a later date) 2 The system shall automatically receive data pulls from EBS for workload data (fields to be determined at a later date) 3 The system shall automatically integrate with EAGLE (functionality to be determined at a later date) 4 The system shall provide labor management engineering standards 5 Minimum 13 months readily accessible data, on a rolling basis, with indefinite archive ability 6 Ability to support multiple users simultaneously with 24/7 access, with the exception of scheduled maintenance times 7 Accessible and operable from mobile devices such as Wi-Fi enabled tablets 8 Fast response time to process user requests based on user inputs/selections such as employee number, date/time range, report generation, line item data view, etc. 9 The system shall provide role based security based on user access, and user roles) Multi-tiered access levels based on user role, with each higher level able to view information for all levels below, ranging from individual employee (self view) to Distribution HQ level with oversight of all distribution centers 10 Access secured by Common Access Card certificates 11 The system shall allow organizations administrator rights for customized report capability. 12 The system shall allow administrator right for modifying engineering standards. 13 The system shall provide print capability for all reports, tables, and data displays 14 The system shall provide supervisor a tabular\detailed view of employees w/ ability to sort by fields. (fields to be determined at a later date) 15 The system shall provide supervisor a tabular\detailed view of incoming procurement workload with the ability to sort by fields. (fields to be determined at a later date) 16 Ability to edit user-supplied data tables which may or may not be used in calculations, such as employee data, (name, ID number, shift hours, etc.), standards tables by site, performance targets, etc. 17 The system shall alert supervisors of procurement phase changes. 18 The system shall provide supervisor a read only tabular/detailed view of engineering standards. (fields to be determined at a later date) 19 The system shall provide supervisors a view of employees’ current workload. Ability to view available workload and assigned task down to the team level (first line supervisor) 20 The system shall provide daily uploads of current workload (interval can be determined at a later date). 21 The system shall allow supervisors an external customization of engineering standards for more in depth analysis. 22 The system shall allow supervisor to distribute work to employees. 23 The system shall provide a color scheme (red, yellow, green) for workload forecasted to miss deadline 24 Print capability for all reports, tables, and data displays 25 The system shall provide supervisor with team productivity reports and measurable. 26 The system shall provide supervisor with data visualization reports (pie charts, line graphs) for presentation. 27 The system shall provide branch level productivity reports 28 The system shall provide reports forecasting future workload based on historical history (type of reports can be determined at a later date) 29 The system shall provide an estimated annual FTE for Program Budget Review. 30 The system shall provide “what if” analysis, supporting research queries across multiple parameters (fields to be determined later) 31 The system shall allow queries to be run using a set of defined parameters. Where applicable, logical operators may be changed as required. 32 The system shall allow queries (see #1) to be formulated by chain, division, IST (or set of ISTs), individual buyer (or set of buyers), PR (or set of PRs), NIIN (or set of NIINs), FSC (or set of FSCs), or NSN (or set of NSNs) 33 The system shall display query results in either interactive forms or customized spreadsheets. The fields included in the customized spreadsheet can be specified for each query. 34 The system shall provide interactive forms that provides key information for each PR and on-demand, detailed PR information; when desired (for example, backorders for an NSN, stock on hand for an NSN, time to award information for all significant PR status areas (e.g., technical blocked, supply blocked, in referral, buyer work, 2nd look, EBT, etc.). 35 The system shall provide a means to clearly identify PRs which are in referral, the referral area, and the current workflow agent (with on-demand detailed information for the agent, when desired). 36 The system shall provide a set of standard comments to allow quick entry of routine comments. 37 The system shall provide a set of standard 'PR Award Delay Reasons' that can be selected, when desired. 38 The system shall provide a visual means to identify late PR awards, out-of-date comments, etc. 39 The system shall provide the details of current quotes for each PR. 40 The system shall provide an event history for each PR, which can be reviewed when desired. The event history should include: status changes, assignment changes, referrals, delay reasons, and all comments. Dates/times and the user triggering the event will be included for each event. 41 The system shall provide the event histories and key PR information for all awarded and cancelled PRs. 42 The system shall provide a means to quickly create emails to request further information about a PR. 43 The system shall provide a means to specify organizational escalation reviews for selected PRs, when required. Levels should include: 1st level manager, IST, division, directorate, and command. The time that the PR remained in each escalation level will be retained and be available for review or reports. 44 The system shall provide a means to 'wedge' (without process delay) selected PRs, increasing their weight/importance and their location in the assigned user's workload. 45 The system shall provide a means to specify different categories levels of wedges and monthly quotas for each type. Categories levels should include IST manager, CAS, supply planner, and directorate. 46 The system shall provide a means to inform wedge-enabled users of their remaining monthly wedge quotas, if applicable. 47 The system shall provide the event histories and key PR information for all awarded and cancelled PRs. 48 The system shall provide a means to quickly create emails to request further information about a PR. 49 The system shall provide a means to specify organizational escalation reviews for selected PRs, when required. Levels should include: 1st level manager, IST, division, directorate, and command. The time that the PR remained in each escalation level will be retained and be available for review or reports. 50 The system shall provide a means to identify PRs in the following priority areas: Super KID, CCIR, MSST, Top 500 backorders, Pace Candidates, MRAP, RCV, SEPA, 21N, Classified documentation, Approved SAR, and Customer Pay. Flags shall be shown in the data display to clearly indicate when a PR is in one or more of the priority areas. 51 The system shall provide a means to 'wedge' (without process delay) selected PRs, increasing their weight/importance and their location in the assigned user's workload. 52 The system shall provide a means to specify different categories levels of wedges and monthly quotas for each type. Categories levels should include IST manager, CAS, supply planner, and directorate. 53 The system shall provide a means to inform wedge-enabled users of their remaining monthly wedge quotas, if applicable. 54 The system shall provide the event histories and key PR information for all awarded and cancelled PRs. 55 The system shall provide a means to quickly create emails to request further information about a PR. 56 The system shall provide a means to specify organizational escalation reviews for selected PRs, when required. Levels should include: 1st level manager, IST, division, directorate, and command. The time that the PR remained in each escalation level will be retained and be available for review or reports. 57 The system shall provide a means to 'wedge' (without process delay) selected PRs, increasing their weight/importance and their location in the assigned user's workload. 58 The system shall provide a means to specify different categories levels of wedges and monthly quotas for each type. Categories levels should include IST manager, CAS, supply planner, and directorate. 59 The system shall provide a means to inform wedge-enabled users of their remaining monthly wedge quotas, if applicable. 60 The system shall provide the event histories and key PR information for all awarded and cancelled PRs. 61 The system shall provide a means to quickly create emails to request further information about a PR. 62 The system shall forecast daily workload based on historical data to aid in staffing planning, leave issuance, etc. 63 The system shall define unassigned workload by functional area and in accordance with engineered standards (ex. Picks would be further broken down by total weight, cube, and type, such as hazardous, classified, cuttable, etc.) 64 The system shall monitor workload as completed 65 The system shall monitor available production capability by employee role, functional activity, and/or physical location 66 The system shall provide work item/task status, (complete, in-progress, unassigned, cancelled etc.), with updates 67 The system shall prioritize workload based on mission/unit requirements or changes to same 68 The system shall recommend personnel allocation based on a calculation of available workload multiplied by standards times and divided by available production hours (from current attendance) 69 The system shall provide the ability to conduct "what-if" analysis of altered personnel recommendation by calculating changes to projected workload completion 70 The system shall assign available work items/tasks to individual employees 71 The system shall calculate production hours needed to complete available workload (multiply items by standard time for completion) 72 The system shall calculate number of FTEs required to complete available workload (divide required production hours by pre-determined production hours per employee) 73 The system shall import and display number of available employees from EAGLE 74 The system shall calculate available production hours based on attendance information from EAGLE 75 The system shall capture completed work items/tasks per employee as defined in accordance with engineered standards 76 The system shall combine attendance and staffing information with production data and manual user inputs to form a complete record 77 The system shall display and print records as described in requirement DistR02, as well as archive and retrieve such records without data loss or corruption 78 The system shall allow users to enter information manually, such as personnel task assignments for off-standard work, work delays, stoppages, etc. 79 The system shall calculate the four (4) Engineered Standards Performance Metrics used by DLA Distribution at all levels from individual employee to depot level 80 The system shall calculate the four (4) Engineered Standards Performance Metrics used by DLA Distribution when depots are combined by service branch, geographic region, etc. 81 The system shall store and display all site-specific engineered standards in table format 82 The system shall calculate and display Blended Rate information, (a mathematical combination of the engineered standards), by work area and job function for each site 83 The system shall provide lookup capability of Blended Rate information by job function and/or work area 84 The system shall combine current data with data retrieved from archive to produce comprehensive customizable reports 85 The system shall display reports in a variety of applicable formats, such as text, graphs/charts, or combinations of the above 86 The system shall all team visibility for first-line supervisors including performance monitoring and performance trend analysis at the individual employee level 87 The system shall calculate annual FTE requirements, broken down from depot level to department/work area, using forecasted workload and engineered standards 88 The system shall sort calculated FTE requirements by organization level, job role, and/or activity 89 The system shall perform comparative analysis of current staffing levels with calculated FTE requirements 90 The system shall track historical workload to calculate FTE requirements 91 The system shall perform "what-if" scenario planning to determine impacts to FTE requirements, broken down from depot level to department/work area, for events such as: changes to workload, changes to standard times, work hour variations, FTE increases/reductions, workload prioritization, and readiness threshold 92 The system shall incorporate user-supplied data, either manually input or table driven, to make adjustments to depot staffing as calculated by the tool, and/or to account for FTEs in positions/roles not captured by other means. 93 The system shall create, modify, and update work process standards using Maynard Operating Sequence Technique (MOST) methodology to enter numeric values corresponding physical movements or other process actions required to complete a work process from start to finish. 94 The system shall convert/calculate entered numeric values into units of time needed to perform actions as described at the Sub-Operation and Operation level, where a Sub-Operation is a complete process step and an Operation is a complete work process. 95 The system shall use annual workload volume to determine the frequency with which a Sup-Operation is performed on a per-line basis and apply the result to the engineered for the complete Operation. 96 The system shall provide Pareto analysis at the Operation level and Rt analysis at the Sub-Operation level to illustrate which engineered standards are utilized most frequently due to varying workload and product mix at different sites. 97 The system shall modify engineered standards based on differences in physical layout and equipment used at different sites. 98 The system shall update engineered standards for all locations due to either a change in mission, process, physical layout and/or equipment by making a single input that the tool will apply to all corresponding standards. 99 The system shall filter and display the engineered standards by various categories, such as work site, work process type, i.e. Receiving, Warehousing, Inventory, etc. 100 The system shall produce reports that show all work process steps/actions along with time to perform each listed work process step/action, as well as product mix information relevant to the steps/actions of the work process. 101 The system shall display engineered standard and associated times in day, hour, minute, second format, out to the thousandth of a second, (3 decimal places) 102 The system shall display relationship data uniting volume driver information with corresponding engineered standards. 103 The system shall perform, display, and print Box-Plot analysis and/or Analysis Of Variance of actual times to perform work processes/work process steps based on manually entered or table-driven user-supplied data. 104 The system shall integrate with J6 ITSM Remedy (IT Incident and Service Request Ticketing System). 105 The system shall integrate with ECRT. 106 Process needs require "proof of concept" for evaluation of stakeholders/users, prior to selection of solution. 107 Should be tested on VDI platform for teleworkers 108 Testing should include at several OCONUS locations for performance 109 Include user training (multi-media) and sustainment up front Tasks Task 1: Project Management The contractor shall provide project management to establish project governance; develop and implement project plans, establish communication and escalation procedures; support change control processes; monitor, control and report program status, cost, schedule and performance; conduct regular project reviews; ensure compliance with PWS requirements and milestones; manage budget. The contractor shall support program change management efforts. Project Management Plan The contractor shall prepare a Project Management Plan (PMP) describing the technical approach, organizational resources, and management controls to be employed to meet the cost, performance, and schedule requirements for the proposed effort. The contractor shall provide the planning, supervision, coordination and controls necessary to accomplish all work contained in this PWS. The contractor shall document the approach in a PMP that defines the activities, tools, and techniques to produce high-quality products that are defect-free, that meet PWS requirements and that are delivered in accordance with the approved schedule. The PMP shall include a description of the organization structure and assigned responsibilities, including the contractor staff that will deliver and implement this PWS. The organization structure shall include the identification of key personnel. The contractor shall provide an organization chart and describe other corporate organizations that will support the team. The contractor shall provide an explanation of how, within the scope of this PWS, technical management will be performed; personnel and physical resources will be managed; and the mechanisms to be used to control cost, schedule and quality. The contractor shall employ a quality management system to ensure effective program management execution and software quality. The PMP shall include a work breakdown structure (WBS) that shows tasks required to complete the work and the dependencies of each task. The WBS shall be detailed to the level of effort necessary to support the accomplishment of work to be performed under the PWS. Integrated Master Schedule The Integrated Master Schedule (IMS) is a time-based schedule containing the networked, detailed tasks necessary to ensure successful program execution. The IMS is traceable to the PMP, the WBS, and this PWS. The IMS is used to verify attainability of program objectives, to evaluate progress toward meeting program objectives, and to integrate the program schedule activities with all related components. The contractor shall produce and maintain an IMS that shows the activities required for the completion of tasks and deliverables for this PWS. The contractor shall deliver to the COR a draft and baselined IMS within 30 and 60 calendar days after contract award, respectively. The contractor shall deliver a Program IMS, with updated actuals, to the COR with each Monthly Performance and Progress Report described below. The IMS shall be delivered in a contractor proposed, Government approved format. Kick-off Meeting The contractor shall schedule a kick-off meeting with the Program Management Office (PMO), Contracting Officer’s Representative (COR), and stakeholders within two (2) weeks of contract award or as agreed on between the Government and contractor, to introduce the Government team to the contractor’s overall operating plans and approach to this work. The contractor shall present and deliver the Kick-off Meeting Briefing Presentation Material and be prepared to discuss the content of the PMP, to include the staffing plan, schedule and proposed metrics. The contractor shall produce and distribute Kick-off Meeting Minutes identifying all the discussion points, agreements and action items following the meeting. Monthly Performance and Progress Report The contractor shall monitor activities and deliverables under this PWS and provide a Monthly Performance and Progress Report (MPPR) that describes program progress, costs, issues, problems and their status. The MPPR shall be the contractor’s method of reporting progress against the PMP. The period covered by the MPPR shall include the previous calendar month’s activities; any issues, actions or other MPPR reported information not satisfied or closed in previous reporting periods; and any required interfaces, meetings or other commitments. If applicable, travel costs shall be broken down by destination, duration, purpose, and costs for both monthly and cumulative to date. MPPRs for the previous month shall be delivered to the COR by the fifth business day of the following month. The MPPR shall include, but not be limited to the following information: Summary of Activities Activities and Progress (Integrated Master Schedule) Software Engineering Metrics and Measures Deliverables Significant Meetings Significant Issues Significant Plans Travel Action Item Status Risks Registry Risks to the contractor based on Government Pending Actions Risk Register The contractor shall apply a risk management approach and plan to develop and maintain a risk register that documents and tracks contractor and Government identified program risks. For each risk, the register shall include at least a description of the risk, a rating (high, moderate, low), a description of the impact should the risk occur and a mitigation strategy. The contractor shall deliver a Risk Register resulting from the contractor’s risk management process to the COR within 30 calendar days of contract award and provide updates within the Monthly Performance and Progress Report. The Risk Register shall be provided in a contractor proposed, Government approved format. Meeting and Teleconference Support The contractor shall prepare briefing materials and represent the AWLS PMO at briefings, meetings and conference calls with organizations of interest, stakeholders, external and internal systems. This representation shall be at a level that functionally and technically represents the AWLS mission and capabilities. The COR or an authorized Government representative will be present at all briefings, meetings and conference calls. Read ahead and presentation materials shall be delivered to the COR two business days prior to any meetings, briefings or conference calls, as required. If meetings, briefings or conference calls are scheduled less than two business days in advance, the Contractor shall provide read ahead and presentation material as soon as practicable. The Contractor shall document meeting notes including, but not limited to, any action items, status of action items, and summary of discussions. The Contractor shall deliver these meeting minutes to the COR no later than two business days after the meeting. Approved meeting notes will be disseminated by the COR. Task 2: Design The contractor shall develop Design Documentation that describes how functional and technical requirements are met considering solution hardware and software capacity and limitations, operating time and desired results. The contractor shall ensure that application design and detailed specifications meet all requirements. The contractor shall obtain Government concurrence with the detailed software and database design through the technical reviews described below. The contractor shall design and develop a System Architecture Plan. The architecture plan shall include, at a minimum, the architectural process and approach, the architecture documentation or electronic models including hardware, connectivity, network infrastructure and components; associated Information Technology (IT) software in terms of component functions, implementation techniques, and interfaces; storage, backup and recovery procedures, recommended operational and administration procedures. The contractor shall comply with current Department of Defense Architecture Framework (DODAF), Business Enterprise Architecture (BEA), and DLA Architectural standards. All architecture material will be usable by the Government without any specialized tools or software. Preliminary Design Review The Preliminary Design Review (PDR) is a technical assessment establishing the physically allocated baseline to ensure that the system under review has a reasonable expectation of being judged operationally effective and suitable. This review assesses the allocated design documented in subsystem product specifications for each configuration item (CI) in the system and ensures that each function in the functional baseline has been allocated to one or more system CIs. The PDR establishes the allocated baseline (hardware, software, human/support systems) and underlying architectures to ensure the system under review have a reasonable expectation of satisfying the requirements within the currently allocated budget and schedule. As directed by the COR, the contractor shall schedule a formal PDR briefing. The contractor shall coordinate the date, time, location, and attendance for the PDR briefing with the COR. The contractor can expect that there will be representatives from the Government AWLS Program Office, DLA J62 PEO, and stakeholders in attendance. The contractor shall complete all of the entrance criteria for which they are Office of Primary Responsibility (OPR) and shall work with the Program Management Office (PMO) to complete the entrance criteria with shared responsibility as identified in the PDR checklist (Section J of the RFP) prior to the briefing. The contractor shall record the PM’s direction for PDR checklist exit criteria and submit to the COR in a PDR Report within 10 calendar days after the PDR briefing. The contractor shall provide read ahead and presentation material to the COR 5 business days prior to the PDR briefing. Critical Design Review A Critical Design Review (CDR) is a multi-disciplined technical review to ensure that a system can proceed into development, demonstration, and test and can meet stated performance requirements within cost, schedule, and risk. A successful CDR is predicated on a determination that the detailed design satisfies the requirement. The contractor shall update the required Design Documentation and provide to the COR. As directed by the COR, the contractor shall conduct a formal CDR briefing. The contractor shall coordinate the date, time, location, and attendance for the CDR briefing with the COR. The contractor can expect that there will be representatives from the Government AWLS Program Office, DLA J62 PEO, and stakeholders in attendance. The contractor shall complete all of the entrance criteria for which he is the Office of Primary Responsibility (OPR) and shall work with the Program Management Office (PMO) to complete the entrance criteria with shared responsibility as identified in the CDR checklist (Section J of the RFP) prior to the briefing. The contractor shall record the PM’s direction for the CDR checklist exit criteria and submit to the COR in a CDR Report within 10 calendar days after the CDR briefing. The contractor shall provide read ahead and presentation material to the COR 5 business days prior to the CDR briefing. Task 3: Development/Configuration As directed by the COR, the contractor shall provide applications development to design, develop, enhance, debug and implement software; address issues with systems integration, compatibility and platforms; work with project teams and end users to ensure application meets requirements; recommend application software changes, and application integration as appropriate; resolve problems; participate in development of appropriate documentation. Commercial Operating Systems (OS) and software applications (Middleware, databases) shall be configured in accordance with DISA’s System Technical Implication Guide (STIG). Supplied software components shall be compliant with these STIG configurations. The contractor shall develop and deliver Configured Software and Software Version Description as required by the IMS. Task 4: System Security The contractor shall ensure that the solution delivered is in compliance with the Defense Information Assurance Certification and Accreditation ( DIACAP) or Risk Management Framework (RMF) as the DOD is migrating from the existing DODI 8510.01 (Information Assurance Certification and Accreditation Process (DIACAP)) dated November 28, 2007 to DODI 8510.1 (Risk Management Framework (RMF) for DOD Information Technology (IT)) dated March 12, 2014. The contractor shall assess the security posture of the delivered solution and shall provide the necessary artifacts for annual certification and accreditation, Systems Security Plan, Hardware/Software Listing, Listing of Ports, Protocols, and Services, Firewall Rules, others as required. The contractor shall incorporate and document the security practices used in the development of the solution and changes to the solution. The security practices shall be modeled after industry best security practices and principles. Examples of best practices can be found at: www.owasp.org and http://iase.disa.mil. The contractor shall ensure that proposed changes to the solution are assessed for certification and accreditation impact prior to implementation. The contractor shall ensure that NIST FIPS validated cryptography standards are used for encryption, key exchange, digital signature, and hash where applicable. The contractor shall develop System Security Documentation (CDRL A026), describing the technical, administrative and procedural cybersecurity program and policies that govern the system. The contractor shall ensure that public domain software is not used in the system unless compelling reasons are established, the product is assessed by the DLA Designated Approving Authority (DAA) or Authorizing Official (AO) for cybersecurity impact, and the product is approved for use by the DAA or AO. The contractor shall ensure that all IT products deployed within the system are reviewed for compliance with governing security implementation guidance documents, DISA Security Technical Implementation Guides - STIGs or Security Requirements Guides - SRGs, National Security Agency - NSA guidelines, Payment Card Industry Data Security Standard (PCI DSS) and National Institute of Standards, Guide to Industrial Control Systems (ICFS) Security. The contractor shall develop and deliver a System Security Plan in a COR approved format within 45 days after award. Task 5: Test The Contactor shall provide testing to ensure system requirements are met; develop and maintain test scripts and architectures for application products; write, implement and report status for system test cases; analyze test cases and provide regular progress reports; provide testing procedures for the support of user requirements in applications; inputs to risk management assessments on test design and test tools selection. The contractor shall support functional unit testing, regression testing, integration testing and user acceptance testing as required to ensure that the COTS solution fully supports existing and proposed functionality. The contractor shall deliver all test results from all tests to the Government. Section 508 Testing Testing shall ensure compliance with Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d), which requires Federal agencies acquiring electronic and information technology to ensure that Federal employees with disabilities have access to and use of information and data that are comparable to the access and use by Federal employees who are not individuals with disabilities. IT products and services developed in response to this PWS are required to comply with Section 508 standards (available on the U.S. Access Board website at: www.access board.gov/508.htm) and the Federal Acquisition Regulation (FAR) both Subpart 7.103 and Subpart 39.2. System Testing The Contractor shall develop and follow a System Test Plan (STP) prepared for each Systems Change Package release. This STP shall include test case and procedure specifications used by the developer to validate requirements and verify proper operation of the system. The Software Test Report (STR) shall validate requirements and verify proper operation of the system; document the conduct and results of the unit, regression, performance, system and integration tests performed by the Contractor. The STR shall be provided to the COR at the completion of all internal test events. The Contractor shall support System Integration Testing (SIT) and Operational Acceptance Testing (OAT) activities. The Contractor shall provide a copy of the Software Test Results to the COR for each problem received. The Contractor shall submit Functional Test Conditions and End-to-End Test Conditions to be used during System Integration Testing. The Contractor shall submit Functional SIT Results and End-to-End SIT Results to the COR on completion of the tests. The Contractor shall document the details of the outcome of each test case using the test script form provided by the AWLS Test Manager. In the case of test failure, the Contractor shall submit a Deficiency Report to the AWLS PMO via the Configuration Management System. Security Test and Evaluation The contractor shall assist the AWLS PMO in Certification Test and Evaluation (CT&E) and Security Test and Evaluation (ST&E) activities described in DIACAP DODI 8500.1 and DODI 8510.1 or DODI 8500.01 Cybersecurity and DODI 8510.01, Risk Management Framework (RMF) for DOD Information Technology (IT). In completing the steps in the RMF process, the contractor shall support the AWLS PMO in reviewing the Field Security Office (FSO) generated detailed checklists and the results evaluation scripts for each Security Technical Implementation Guide (STIG) to support Security Readiness Reviews (SRR) and site self-assessments involving AWLS applications. As directed by the COR, the contractor shall develop, review and update, as necessary, the test plans and reports and develop or update the PKI Interoperability Test Report (PITR). As directed by the COR, the contractor shall provide ST&E Test Conditions/procedural scripts and an ST&E Test Report for IA controls identified in DODI 8500.01 for a Mission Assurance Category (MAC) III/Sensitive system and Cyber Security controls identified in NIST SP 800-53 Revision 4 for the applicable category to the COR for review/approval. The contractor shall also make recommendations for mitigating of residual risks. Test Readiness Review A Test Readiness Review (TRR) assesses contractor’s readiness for testing configuration items, including hardware and software, regarding to the test objectives, procedures, resources and testing coordination. As directed by the COR, the contractor shall conduct a formal TRR briefing. The contractor shall coordinate the date, time, location, and attendance for the TRR briefing with the COR. The contractor can expect that there will be representatives from the Government AWLS Program Office, DLA J62 PEO, and Stakeholders in attendance. The contractor shall complete all of the entrance criteria for which he is the Office of Primary Responsibility (OPR) and shall work with the PMO to complete the entrance criteria with shared responsibility as identified in the TRR checklist (Section J of the RFP) prior to the briefing. The contractor shall record the PM’s direction for the TRR checklist exit criteria and submit to the COR in a TRR Report within 10 calendar days after the TRR briefing. The contractor shall provide read ahead and presentation material to the COR 5 business days prior to the TRR briefing. Production Readiness Review A Production Readiness Review (PRR) is a formal examination of a program to determine if the design is ready for production and if the producer has accomplished adequate production planning. As directed by the COR, on successful completion of Government testing, the contractor shall conduct a formal PRR briefing. The contractor shall coordinate the date, time, location, and attendance for the PRR briefing with the COR. The contractor can expect that there will be representatives from the Government AWLS Program Office, DLA J62 PEO, and Stakeholders in attendance. The contractor shall complete all of the entrance criteria for which he is the Office of Primary Responsibility (OPR) and shall work with the PMO to complete the entrance criteria with shared responsibility as identified in the PRR checklist (Section J of the RFP) prior to the briefing. The contractor shall record the PM’s direction for the PRR checklist exit criteria and submit to the COR in a PRR Report within 10 calendar days after the PRR briefing. The contractor shall provide Read Ahead and Presentation Material to the COR 5 business days prior to the PRR briefing Task 6: Training The contractor shall conduct end-user training that comes with the product and is provided by the vendor. The Training Materials including a User’s Manual shall be easily used by incidental operators and no formal residential training post initial fielding training shall be required to operate this program. Task 7: Deployment The contractor shall make the system product available to the prescribed users; develop a deployment plan that details the training schedule, user registration and access control, on-site support the execution of the deployment plan; provide on-site deployment support; ensure that the delivered capability complies with DoD information assurance requirements; follow a transition plan as applicable; validate data migration, application configuration, application migration; assess configuration management processes; measure and monitor system performance and user acceptability. Task 8: Sustainment The contractor shall provide expertise in system administration, system security, web administration, database administration, and help desk support to operate, maintain and administer the delivered capability; support the operations, administration, and maintenance of AWLS; support all the hosting environments of AWLS including COOP as applicable; capture performance issues; make recommendations for resolution of future system upgrades, updates and enhancements; implement operational systems at a Government-specified location to include a COOP and backup site; ensure all mission hardware, and software operating systems and applications are up to date by installing the proper security and functional patches in accordance with the configuration management plan; provide for routine backup and configuration management of the AWLS solution, including all equipment and software as necessary to keep AWLS performance within acceptable tolerances. Deliverables A deliverable under this contract must meet the following requirements to be accepted by the COR: System requirements are fully met; System passes testing; System passes IA scans or WebInspect scans; Approval by a variety of policy boards and reviews. If a deliverable fails one or more of the above requirements, the contractor shall resubmit the product until it is found acceptable, i.e., until it meets all of the above requirements. A deliverable will not be accepted if it has a critical, high or medium WebInspect findings or category 1 or 2 severity codes. “Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) definition states: E2.1.66. Severity Code. Indicates the Certification Authority (CA) assessment of the likelihood of system-wide IA consequences, given a single or multiple findings. The Severity Code is assigned to a system IA security weakness by a CA as part of a certification analysis to indicate i. the risk level associated with the IA security weakness and (2) the urgency with which the corrective action must be completed. Severity codes are expressed as “CAT I, CAT II, CAT III,” where CAT I is the indicator of greatest risk and urgency. E2.1.66.1. CAT I Severity Code. Assigned to findings that allow primary security protections to be bypassed, allowing immediate access by unauthorized personnel or unauthorized assumption of super-user privileges, and usually cannot be mitigated. E2.1.66.2. CAT II Severity Code. Assigned to findings that have a potential to lead to unauthorized system access or activity. CAT II findings can usually be mitigated and will not prevent an authorization to operate (ATO) from being granted. E2.1.66.3. CAT III Severity Code. Assigned to recommendations that will improve IA posture but are not required for an authorization to operate. WebInspect vulnerability definitions are listed below. Critical, high, and medium findings must be resolved before final approval is granted: Critical - a vulnerability wherein an attacker might have the ability to execute commands on the server or retrieve and modify private information. High- the ability to view source code, files out of the web root, and sensitive error messages Medium – indicates non-HTML errors or issues that could be sensitive Low - interesting issues or issues that could potentially become higher ones. Contractor deliverables shall conform to Federal, DoD and DLA life-cycle process policy. The contractor has a vital role in ensuring that projects follow these guidelines and can be moved into production on government web servers. The contractor shall apply its best-efforts to identify non- conformance issues prior to implementing a change to the AWLS system. If the deliverable is disapproved due to nonconformance, the contractor shall bring the deliverable into conformance without additional cost to the government and will be held to the deliverable dates. The deliverable is not considered received until non-conformance issues have been resolved. If a contractor has recurring non-conformance issues during performance under this contract, these issues will be used as negative past performance if the contractor is evaluated for future contract awards. DLA uses a software development life-cycle model which mirrors an industry best practice called Capability Maturity Model Integrated (CMMI). The AWLS contractor will follow iDLC processes such as testing, configuration management, and release management procedures. For example, when the contractor is required to participate in testing, documented test results shall be provided to the government. System specification and architecture documentation will be required. The contractor may be required to provide assistance with development of user guides, including installation instruction and conducting training classes. DLA web sites must be compliant with policies and processes prescribed by Federal, DoD, and DLA such as: Section 508 of the Rehabilitation Act, 29 U.S.C. Section 794d is a Federal law and all Federal government information technology products must be Section 508 compliant. Section 508 requirements are provided at http://www.section508.gov. DLA will provide tools such as ACC Verify, ACC Compliance Sheriff, and JAWS to validate Section 508 compliance. As technology evolves, these tools may change. Deputy Secretary of Defense (DEPSECDEF) memo, “Web Site Administration Policies and Procedures” at: http://www.defense.gov/webmasters/policy/dod_web_policy_12071998_with_amendments_and corrections.aspx DLA Web Site Development and Administration Instruction - focuses on the DLA Internet process and policy, Section 508 of the Rehabilitation Act, DLA Web development standards, and other technical issues. This guidance will be provided to the contractor upon award. The contractor shall provide system documentation as directed by the Contract before the contract will be considered complete and final payment provided. Examples of system documentation are a System Specification and user guide. The contractor shall diagnose and resolve errors and meet deadlines as assigned by COR The contractor shall conduct daily reviews to insure that the work performed is high quality and that products are delivered according to schedule. All work and products resulting from this PWS shall be compliant with Public Law, Federal Statues, the Federal Acquisition Regulation (FAR), Department of Defense (DoD), and Defense Logistics Agency (DLA) Directives, Instructions, and CERT tasking. Especially critical is Section 508 of the Rehabilitation Act, 29 U.S.C. Section 794d is a Federal law and all Federal government information technology products must be Section 508 compliant. Section 508 requirements are provided at http://www.section508.gov. DLA will provide tools such as ACC Verify, ACC Compliance Sheriff, and JAWS to validate Section 508 compliance. As technology evolves, these tools may change. Deliverable Requirements The COR will review all deliverables to ensure accuracy, functionality, completeness, professional quality, and overall compliance with contract requirements. The contractor shall ensure the accuracy and completeness of all deliverables. Unless otherwise noted, the contractor shall only deliver final completed products to the Government for acceptance. The Government will consider errors, misleading statements, incomplete or irrelevant information, excessive rhetoric, or repetition as deficiencies and the contractor shall make corrections. Unless otherwise indicated in a deliverable description, the Government will have ten business days to review deliverables. If the Government has comments, the contractor shall have five business days to make corrections to the deliverable and resubmit the deliverable to the Government. In the event that there are exceptional circumstances impacting the delivery of a CDRL item, the COR may grant up to a five business day extension on the delivery of any CDRL item. To be granted an extension the contractor shall submit a written justification to the COR and Contracting Officer no less than 2 business days in advance of the CDRL item due date. All completed deliverables shall be delivered to the COR and/or Government individual identified for this effort. Except as specified in this PWS, the contractor shall use best commercial practices for formatting all deliverables. Electronic copies of all deliverables shall be sent to the COR via email in Microsoft Office compatible or Portable Document Format (PDF) formats. If deliverable exceeds email size limitations (10 MB), the deliverable shall be sent via Compact Disk (CD) or other media as appropriate for the size of the deliverable and approved by the COR. Deliverables Schedule CONTRACT DELIVERABLES PWS Tasks Deliverables Frequency Due Medium/Format Submit To MEETING/REPORTS/MINUTES Section 6.1.1 Project Management Plan (PMP) 30 days after contract award In mutually approved format with electronic materials used in meeting Section 6.1.2 Integrated Master Schedule (IMS) 30 days after contract award In mutually approved format with electronic materials used in meeting Section 6.1.5 Risk Register Initial 30 days after contract award ; 5th business day of each month 1 Arrange the kick-off meeting Once COB 2 work days after contract award Phone/ e-mail KO/COR 1 Kick-off meeting Once COB 5 work days after contract award In person KO/COR 1 Meeting Minutes (i.e. Quarterly IPR, Ad Hoc IPR, Ad Hoc Status Report, Briefings) Once per meeting, unless otherwise informed 5 work days following the meeting In mutually approved format with electronic materials used in meeting COR, designated DLA Contract Specialist & Contracting Officer 1 Monthly Project Status Report Monthly 5 work days after the month ends and must be delivered at least 5 work days before that period’s invoices are submitted e-mail/ hard copy, as requested COR 1 Transition Progress Report Once a week, last 8 weeks Once a week for the last two months of the Contract e-mail/ hard copy, as requested Arrange with COR 1 Ad hoc status reports As directed 1600 of the due date given by DLA or time of meeting e-mail and/or meeting, as requested COR others as directed 1 Reports, demonstrations, and briefings As directed COB of the due date given by DLA Meeting/ e- mail Arrange with COR 1 Discussion of content etc. of Quarterly In-Process Review (IPR) Quarterly 1 calendar month prior to the IPR In person or by phone COR or designated DLA personnel 1 Quarterly In-Process Review (IPR) Quarterly By the end of the first full work week of the months of January, April, June, and September Meeting COR DLA Branch Chief/others, Contract Specialist, and other as directed 1 Ad Hoc IPRs As directed Meeting time on the day requested Meeting COR DLA Branch Chief/others 1 Trip Reports Once per trip 5 work days prior to submission of invoices for trip Electronic and hardcopy COR DLA Branch Chief PLANNING/OUTPUT DOCUMENTS 1 Project Plans As directed COB date indicated by COR/ACOR and throughout the project Electronic/ CD COR Designated DLA Personnel 1 Attend necessary meetings of various review and process boards with necessary documentation As directed As determined by COR/ACOR and Project Plan Electronic/ phone/ in person as agreed upon COR, designated personnel 1 and 3 System Documentation As directed in the Contract COB date indicated by Contract PWS and the COR/ACOR Electronic and hardcopy COR, designated personnel PWS Tasks Deliverables Frequency Due Medium/Format Submit To TRAVEL INVOICING Section 5.6 Monthly Invoices (Maintenance) Monthly 5 work days after the submission the monthly status or 5 work days after the submission the end product depending on the CLIN structure NLT the tenth of the month. PDF and hardcopy COR, DLA Branch Chief Section 5.6 Request for travel approval/funding As needed In work proposal or 1 calendar month prior to the trip E-mail follow up with phone COR TRANSITION IN/TRANSITION OUT 1 Knowledge transfer to government or contractor Once At the close of the contract In person, by phone, and electronic COR and designated individuals 1 Knowledge transfer status meetings Once – with weekly meetings In the 2 calendar months prior to end of the contract E-mail and phone as agreed upon COR, designated personnel 1 Provide full documentation on the work/projects Twice 2 calendar months prior to end of contract and an updated version upon close of contract Electronic and CD COR, designated personnel PERSONNEL/SECURITY/DISCOLSURE DOCUMENTS Section 5.9 Government Review of Resumes and Invitation to Interviews Once per employee Prior to accepting an employee starting work Electronic/ Hardcopy/ In person COR Section 5.9 Contractor notification of full name, social security number and date of birth of all employees assigned to work on the contract. Within a reasonable time, as directed by the Government and the Contractor following award of the contract At start of contract and prior to any new employees starting on contract El ec tr on ic or hardcopy, as agreed upon in the startup meeting COR Section 6 Written report of any potential organizational conflicts of interests (OCIs) and to protect from disclosure of proprietary and source selection sensitive information At the beginning of contract and as needed This statement should be supplied at the kick off meeting and should be updated as changes occur Hardcopy Contracting Officer, Contract Specialist, COR Section 5.4 Nondisclosure Clause Once per employee Signed before an employee can start work Hardcopy Contract Specialist and COR Section 5.7 Appropriate IT Level Credentials As needed for each employee Prior starting work and throughout time on contract Forms specified in PWS Designated Security Personnel and COR Section 5.7 Secret Clearance or Interim Secret Clearance Electronic Personnel Security Questionnaire (ESPQ) – the government’s security background check, SF 85P (National Agency Check [NAC] and Badge and ID Request Form (DLAH 1728) As needed for each employee Must have clearance prior to working on secret and maintained throughout project requiring the clearance Forms specified in PWS Designated Security Personnel and COR PWS Tasks Deliverables Frequency Due Medium/Format Submit To 1 Government furnished property (to include IT equipment, IDs, parking decals) shall be returned Once per employee departure Prior to departure of any personnel In person Contract Specialist, COR 1 Notification of Contractor personnel no longer requiring access to Government equipment and infrastructure Once per employee departure Within 24 hours of personnel resignations, reassignments, terminations, or completion of portions of the contract E-mail COR TRAINING 2 Periodic Training Requirements As directed COB date provided by COR Certificate of completion COR SUSTAINMENT/MAINTENANCE 3 Maintenance/Sustainment Deliverables As directed COB on day indicated in individual Contract or as determined by the PCWG or CERT Successful implementation, backups, soft copy COR As directed PERIOD OF PERFORMANCE: The period of performance shall be from time of award for one (1) Base Year with two option years. The Period of Performance is as follows: Base Period: Twelve (12) Months from Date of Award Option Period 1: Twelve (12) Months from End of Base Period Option Period 2: Twelve (12) Months from End of Option Period 1 Key Personnel Required Certain skilled, experienced, professional and/or technical personnel are essential for successful accomplishment of the work to be performed under the resultant contract. These are defined as Key Personnel and are those persons whose resumes are to be submitted as part of the technical proposal. The Contractor agrees to use said Key Personnel during the performance of the resultant contract and that they shall not be removed from the contract work, replaced, or supplemented with additional personnel, unless authorized in accordance with the following provisions: The Contractor shall not substitute key personnel assigned to perform work under this contract without prior approval of the Contracting Officer. Requests for approval of substitutions shall be in writing and shall provide for a detailed explanation of the circumstances necessitating the proposed substitution(s). Requests must contain a complete resume for the proposed substitute, and any other information as requested by the Contracting Officer. Proposed substitutions must have qualifications that are equal to or higher than the key personnel being augmented and must possess a minimum of an IT1 level of trust. The Contracting Officer shall evaluate such requests and promptly notify the Contractor in writing whether the proposed substitution is acceptable. If the Contracting Officer determines that a suitable and timely replacement of key personnel who have been reassigned, terminated or have otherwise become unavailable for the contract work is not reasonably forthcoming or the resultant substitution would be so substantial as to impair the successful completion of the contract in accordance with the proposal accepted by the Government at the time of contract award, the Contracting Officer may pursue appropriate termination procedures and/or equitably adjust the contract price downward to compensate the Government for any resultant delay, loss or damage. These provisions shall be fully applicable to any subcontract that may be entered into. Key personnel placed against the contract are subject to the Contractor security requirements as stated in Section 14 of the PWS. Program Manager The Program Manager shall manage all day-to-day operations including administrative functions, assessing risks and identifying unstated assumptions, and resolving interpersonal conflicts in support of making the program successful. The Program Manager shall have a technical background as well as a management background. The Program Manager has experience with the execution and management of information technology (IT) programs. This includes direct experience in leading and executing IT solutions in the private or public sector. Experience includes: · Program management of technically and functionally diverse and complex IT programs · Implementation of detailed management techniques such as Critical Path Method (CPM) and Earned Value Management · Complex product configuration management and control · Business case development · IT solution architectural analysis and design · Detailed migration planning and trade-off analysis · System data exchange design, development, and implementation Duties and Responsibilities: The Program Manager acts as manager and overall point of contact for all work on this contract and: · Directs staff and reviews work products for completeness and adherence to customer requirements · Provides communication to management to review project plans, status reports, and deliverables · Develops overall project milestones and monitors the execution of the project against planned time lines · Directs and reviews program plans, status reports, and deliverables with the program director and project teams · Provides technical and functional management to one or more project teams for specific projects or sub-tasks Systems Engineer The Systems Engineer (Senior) has experience with the design, execution, and oversight of IT projects. This includes direct experience in the design and development of integrated software and hardware solutions in the private or public sector. Experience includes: · Detailed functional analysis and gap/fit analysis of software solution packages · Software solution package selection and business case development · Software and system developmental and acceptance testing · Legacy system data exchange design, development, and implementation Duties and Responsibilities: · Supports all program and project planning and milestone development · Supports business case analysis and identification of alternative solutions and resulting business impacts · Identifies possible solutions, and work with developers to implement those fixes Development Lead The Development Lead is responsible for translating technical software specifications into software design and providing IT technical guidance to junior engineers, analysts and programmers. The Development Lead shall also provide project leadership as the principal designer under this PWS. Experience includes: · Demonstrated experience in system/application design and development of complex IT projects · Proficiency in: Analyzing user-defined functional, technical system requirements as well as writing design and technical specifications Drafting integration test plans and integration test cases as well as executing and documenting integration testing activities Complex analysis, design, development, testing and debugging of mainframe, mid-tier, cloud and web-based applications Duties and Responsibilities: · Collaborates with business analysts, architects, others to plan, design, develop, test, and maintain applications · Collects and documents user requirements · Prepares reports, manuals and other documentation on the status, operation and maintenance of application software · Designs, develops, and unit tests applications in accordance with established standards · Participates in peer-reviews of solution designs and related code · Packages and supports deployment of releases · Develops, refines, and tunes integrations between applications · Configures services for performance, security, and error handling · Analyzes and resolves technical and application problems · Assesses opportunities for application and process improvement · Assists in the collaboration required for shared development environments · Assists in determining and enforcing development standards and best practices · Performs application related Security Technical Implementation Guides (STIGs) and Vulnerability Management System (VMS) reporting Applications Programmer The Applications Programmer is responsible for creating new applications and for maintaining and improving existing applications. The S Applications Programmer designs and implements collection, storage, computational, and web service layers; ensures that internal and external requirements for application reliability, latency, and scalability are satisfied; and implements functional and performance testing, monitoring, and troubleshooting strategies for production systems. Is a SME in application technologies, methodologies, and applications Proficient in: Application development, database design, requirements analysis/development, information engineering Analyzing user-defined functional, technical system requirements; writing design and technical specifications Drafting integration test plans and integration test cases; executing and documenting integration testing activities Web server administration Writing technical documentation Performs application related Security Technical Implementation Guides (STIGs) and Vulnerability Management System (VMS) reporting Has knowledge of Defense Information Assurance Certification and Accreditation Procedure (DIACAP) and Risk Management Framework processes for application Duties and Responsibilities: Designs, develops, enhances, debugs, and implements software. Troubleshoots production problems related to software applications. Researches, tests, build and coordinate the conversion and/or integration of new products based on client requirements. Designs and develops new software products or major enhancements to existing software. Addresses problems of systems integration, compatibility, and multiple platforms. Consults with project teams and end users to identify application requirements. Performs feasibility analysis on potential future projects to management. Assists in the evaluation and recommendation of application software packages, application integration and testing tools. Resolves problems with software and responds to suggestions for improvements and enhancements. Acts as team leader on projects. Instructs, assigns, directs, and checks the work of other software developers on development team. Participates in development of software user manuals. Responses: If you are interested in offering on such an opportunity please provide a response by close of business (COB) November 19, 2015 to John Dormer (john.dormer@dla.mil). Please have the subject of the email response read “Agency Workload Management System RFI.” (1) Based on the PWS attached, what would you estimate your total annual cost to be over 5 years? (2) Based on the PWS, how long after date of award would you be fully staffed or up to full operational capacity? (3) What type of labor categories would you view as being "Key Personnel" under your proposed solution? (4) Submit any questions or clarifications on the attached PWS to john.dormer@dla.mil. Proprietary information or trade secrets, if any, must be clearly marked on all materials. All information received that is marked Proprietary will be handled accordingly. Please be advised that all submissions become Government property and will not be returned. All government reviewing RFI responses will have signed non-disclosure agreements and understand their responsibility for proper use and protecting from unauthorized disclosure of proprietary information as described in 41 U.S.C. § 423. The Government shall not be held liable for any damages incurred if proprietary information is not properly identified.
Web Link: FBO.gov Permalink
(https://www.fbo.gov/spg/DLA/J3/DSCP-PB/SP4701-16-R-8889/listing.html)
Record: SN03926345-W 20151022/151020234706-3f3dc21f115ec1c79ef5f871d9d5f401 (fbodaily.com)
Source: FedBizOpps Link to This Notice
(may not be valid after Archive Date)

| FSG Index | This Issue's Index | Today's FBO Daily Index Page |

Loren Data's SAM Daily™

D -- Agency Workload Management System (AWLS) acquisition