HC1047-17-R-0001_-_Att_7_-_Problem_Statements.pdf

HC1047-17-R-0001

Attachment 7 – Problem Statements

PROBLEM STATEMENTS 1 AND 2 ARE FOR THOSE PROPOSING IN THE UNRESTRCITED POOL.

PROBLEM STATEMENTS 3 AND 4 ARE FOR THOSE PROPOSING IN THE RESTRICTED POOL.

PROBLEM STATEMENT #1:

For the Unrestricted Pool

Framed Requirement Seeking Innovative Solution:

PROBLEM STATEMENT: The Defense Information Systems Agency (DISA) has a requirement to develop an internal consolidated personnel management system capable of managing the applicable aspects of the DoD’s Hire-to-Retire (H2R) program for civilian employees at DISA. The H2R business process encompasses the business functions to recruit, in-process, develop, retain, and out-process civilian employees at DISA. Specific business functions required for this system include, but are not limited to: workforce management (i.e. organizational assignment, human resource data, in/out processing, or separation/retirement), learning management (i.e. training & development), talent management (i.e. recruitment, accession, ascension, and retention), and security information management (i.e. roles, responsibilities, & personnel classification). DISA stakeholders have identified several high-level features for the requirement; to include, the use of an open architecture to allow for decoupling of data and static business rules, the flexibility for the system to adapt to evolving business workflows, a modular design, and the ability to customize reports & queries. Leadership has directed a maximum three-year window to go from the initial concept determination, to system development, to implementing the functional system into production.

In responding to this problem statement, the offeror will propose a plan that enables the Government to make a Concept Determination (pre-Milestone-A). To substantiate the Concept Determination milestone, offerors may consider the following example criteria in creating their proposed plans:

• Formalized goals & objectives to accomplish the requirement

• Recommended preferred concept consistent with approved Systems & Technical View Architectural

Artifacts (ref: DoDAF)

• Demonstrated ability of preferred concept to meet program objectives

• Assigned appropriate security sensitivities, classifications, & caveats

• Defined viable High-Level Concept of Operations

• Established alignment to preliminary resource plans, if applicable

• Defined system support objectives, with tolerance for feedback and iteration throughout the Systems

Development Life Cycle (SDLC)

INTENDED OUTCOME: The Government’s intended outcome for the Concept Determination is to accomplish the following:

• To refine the stakeholder, user, mandates, and basic operating concepts

• To identify and assess potential material solutions to accepted & endorsed capabilities against defined stakeholder, architectural, operational, and Information Assurance (IA) constraints

• To provide a preliminary investigation of alternatives and risk analysis, & high-level cost-benefit analysis to determine if the project has a favorable return on investment

• To assess solution alternatives & to provide information about capabilities and risks to permit an objective comparison of competing solutions concepts

As part of the proposed plan, it is expected that the offeror includes relevant decision making information typical of an Initial Capabilities Document (ICD); which may contain, but is not limited to:

• Capability need definition

• Market research

• Solutions concept review

• Feasibility study

• Preliminary requirements assessment

• System maintenance and support objectives

• High-level architecture and description

ASSUMPTIONS: The offeror shall make the following assumptions in responding to Problem Statement #1:

• Assume that the Government has reached the Material Design Decision (MDD) and has confirmed the necessity of a material solution.

• For the purposes of this problem statement, and referencing the overarching H2R initiative, business functions required do not include providing employee benefits, performing payroll activities, garnishing wages, or collecting and paying taxes. All of which are functions expected to be provided by the Defense Civilian Pay System (DCPS).

• The requirement will be owned and operated by DISA, with all authoritative data originating from DISA internal resources. It is not expected for the proposed system to have any integration or interface links with non-DISA systems.

• The proposed solution will operate solely on the UNCLASSIFIED NIPRNET.

• The proposed solution will process and store Personally Identifiable Information (PII).

• Appropriate Role-Based Access Controls are expected for a variety of user use-cases.

• Relevant reference information includes; but is not limited to:

o DoD Architecture Framework, version 2.02 o Federal Enterprise Architecture Framework (FEA) o DoD Information Environment Architecture (DoD IEA), version 2.0 o DoD Strategy for Operating in Cyberspace (DSOC) o Resource management processes as defined by Planning, Programming, Budgeting, & Execution

(PPB&E)

o Requirements management processes as defined within the Joint Capabilities Integration and

Development System (JCIDS) o Acquisition processes as defined within DoD 5000.02 o DoD Open System Architecture (OSA)

Offeror’s proposed plans will be evaluated on the following PWS Task and Sub-Task areas:

Task Area 1: Systems Engineering: Specifically, PWS Paragraph 6.1.9. The offeror’s plan must demonstrate process knowledge, particularly regarding the requirements analysis process. The response shall include how the offeror plans for interactions among various business and technical functions to achieve a set of consolidated and refined requirements that meets the objective. The offeror shall demonstrate the ability to analyze non-functional user requirements and translate those user needs into basic functions. Additionally, an offeror shall demonstrate an understanding of the integration paths for the system to mature from development to implementation.

Task Area 3: Systems Architecture: Specifically, PWS paragraphs 6.3.4, 6.3.5, & 6.3.14. The offeror’s plan will be evaluated based on the ability to identify, assess, and select systems to be utilized versus competing requirements for new systems to be developed. The proposal must demonstrate how they will collect and organize architecture data required for system development through system modeling and documentation techniques that support capability and service mapping.

Task Area 5: Systems Integration: Specifically, PWS Paragraphs 6.5.1 and 6.5.2. The offeror’s plan will be evaluated based on the ability to define objectives, develop criteria mapping proposed system features to requirements, and to develop an integration strategy for incorporating the potential of multiple current software applications, data repositories, and internally-sourced enterprise services. The proposal must include information on how they will ensure consistency and traceability between the system design and the anticipated system elements.

Task Area 7: Systems Deployment and Life-cycle Engineering: Specifically, PWS paragraph 6.7.2. The offeror’s plan must demonstrate, at a high-level, how they will be using systems engineering processes, and design maturation processes, within the Defense Life-Cycle Management system to ensure critical activities are accounted for at each critical milestone, phase, and decision point, up to Milestone C. The proposal must demonstrate a comprehension of key phase activities in the areas of: requirements development, systems engineering, test & evaluation, and logistics/sustainment.

PROBLEM STATEMENT #2

For the Unrestricted Pool Open-Ended Problem Seeking Innovative Approach:

PROBLEM STATEMENT: In today’s mobile environment, the end user experience for DISA’s customers and mission partners is of the utmost importance to stakeholders. This user experience (UX) is created by the devices, operating systems, networks, communications, and servers that compose DISA’s mobile ecosystem. This ecosystem, as it adapts to changes in technology, implementation, and use cases – needs to be designed and built to not only satisfy, but to exceed expectations of the warfighters, operators, and end users. To accommodate this in an efficient manner, an end-to-end architecture framework -- from mobile device to back-end server – is needed to describe the tasks and activities, operational elements, and resource flow exchanges required to manage operations of a mobile environment. Through the planning phases of developing this end-to-end architecture, stakeholders intend to focus the objectives around reducing system costs and increasing performance by facilitating an enhanced and more reliable UX, enhancing design decisions, and proactively identifying bottlenecks and shortcomings. Additionally, many end-user applications are highly affected by network performance and information assurance capabilities; as such, the identification of key performance indicators to help determine the impact of new components – both positively and negatively – is a key functionality need.

INTENDED OUTCOME: In responding to this problem statement, the offeror shall propose a plan for developing an architecture that would accomplish the above objectives if the architecture plan were executed. The offeror shall frame their plan around the use of the standard All Viewpoint, Operational Viewpoint Models, and any other Viewpoint that the offeror deems necessary to represent the solution (ref: DoDAF v2.02). The offeror shall provide a brief rationalization for each DoDAF Viewpoint used. The following considerations are provided to offerors to help with the offeror’s planning activities, but are not required:

• Providing a mechanism to map user requirements to strategic-level capability needs, enabling early agreement to be reached on the capability boundary by stakeholders.

• Providing a validated reference model of the business/operations against operational technology capabilities so that a completeness of a requirements definition can be assessed (visualization aids validation).

• Creating the ability to link functional requirements to a validated model of the business or operations activities.

• Capturing information-related requirements in a coherent manner, and in a way that appropriately reflects the UX needs of our warfighters, operators, and end users.

• Analyzing the impact that an insertion of a capability, at any point in the architecture, will have on dependent capabilities.

• Capturing the iterative activities for process engineering or process re-engineering.

ASSUMPTIONS: The offeror shall make the following assumptions in responding to Problem Statement #2:

• Design decisions, motivated by security needs, cost, or upgraded performance, shall be measured against the end user experience and their effects on usability.

• Identification of bottlenecks and system shortcomings shall enable cost savings through the identification of negative system effects caused by individual components.

• A pure architectural model is material independent.

• Specific elements that could be included in plan to develop an enterprise architecture are not limited to any one particular service, strategy, standard, project, or application.

• The presentation aspects shall not overemphasize the pictorial presentation at the expense of the underlying data necessary for adequate approach planning.

• Relevant reference information includes; but is not limited to:

o DoD Architecture Framework (DoDAF), version 2.02 o Federal Enterprise Architecture Framework (FEA) o DoD Information Environment Architecture (DoD IEA), version 2.0 o DoD Strategy for Operating in Cyberspace (DSOC) o Requirements management processes as defined within the Joint Capabilities Integration and Development System (JCIDS)

PROBLEM STATEMENTS 3 AND 4 ARE FOR THOSE PROPOSING IN THE RESTRCITED POOL

PROBLEM STATEMENTS 1 AND 2 ARE FOR THOSE PROPOSING IN THE UNRESTRCITED POOL.

PROBLEM STATEMENT #3:

For the Restricted Pool

High-Level Requirement Seeking Technology-Unique Solution:

PROBLEM STATEMENT: Network communication flows between the user and the other end of the network, and everything along the way, need to work in order for the communication to occur. Network problems can occur when the communication is initiated, at any point along its route, or at the end points. When a problem occurs, remediating that problem is the first priority, but the fix often falls short of identifying a root cause, a long term solution, or a future enhancement that can permanently enhance the warfighter’s experience with information technology. As an example, in the future DISA may be required to create and manage communications links using additional, and more diverse, signal media including optical length wavelengths, electromagnetic spectrum frequencies, satellite communications, or emerging data transmission technologies. The various impacts of these new types of links, both positive and negative, will likely have short and long term ramifications for network tools and network management requirements, as well as impacts on the applications whose data is riding these networks.

To best account for these future requirements, DISA stakeholders require forward thinking contractors to have the capability to effectively problem solve at a rate that can keep up, or even be predictive, of future technology changes and their associated impacts.

In responding to this problem statement, the offeror will propose a plan to enable the Government to make a Material Development Decision (MDD), based on an identifiable information technology capability gap that may be solved by a technology, or technology area, that the offeror is highly-skilled in. The offeror may base their plan on the above example, or propose a different, yet quantifiable, capability shortfall in the DISA mission space.

To substantiate the MDD milestone, offerors may consider the following example activities in preparing their proposed plans:

• Develop high-level Operational and All View architectural artifacts, if applicable (ref: DoDAF)

• Conduct initial gap analysis

• Identify and quantify operational, security, architectural, performance, and sustainment constraints

• Conduct initial market research and preliminary analysis of alternatives

• Project scoping efforts and security classification identification

• Internal assessment and endorsement activities

• Forecast preliminary schedule, cost, and resource requirements

INTENDED OUTCOME: The Government’s intended outcome for the MDD is to accomplish the following:

• To identify, capture, describe, and define stakeholder, user, mandate, and basic operational capability needs as they relate to the proposed technical capability need.

• To identify and demonstrate the existence of, and the need to resolve, a shortfall in the agency’s ability to complete its mission in the most effective manner, or the need to explore an emerging technology or innovative opportunity to meet agency mission and capability needs more effectively.

• To define capability shortfall or technological opportunity in terms of mission, objectives, information requirements, performance metrics, & frequency of demand.

• To identify significant assumptions & constraints, to explore alternative concepts & methods in efforts to eliminate unsound concepts, and to formalize the viability of the identified capability need.

• To identify estimates for executive business and technical return-on-investment in the identification, validation, and acceptance of new development capabilities, technical innovations, emerging technologies, and/or service enhancements.

As part of the proposed plan, it is expected that the offeror includes relevant decision making information typical of an Initial Capabilities Document (ICD); which shall include at a minimum:

• Capability need definition

• Preliminary market research

• Solutions concept review

• Feasibility study

• Preliminary requirements assessment

• System maintenance and support objectives

• High-level architecture and description

ASSUMPTIONS: The offeror shall make the following assumptions in responding to Problem Statement #3:

• A non-material solution alone cannot satisfy the identified need, and that a potential material solution will be considered.

• The offerors identified information technology capability gap must map back logically to an existing technology in the DISA mission space or DISA’s primary areas of innovation interest (ref: L.4.2.3)

• The offeror’s identified information technology capability gap shall be based on UNCLASSIFIED existing and future technological capabilities.

• DISA will be the sole agency involved in the Material Development Decision, and stakeholders would only be from internal DISA organizational elements.

• It is not expected for the proposed system to have any integration or interface links with non-DISA systems.

• Relevant reference information includes; but is not limited to:

o DoD Architecture Framework, version 2.02 o Federal Enterprise Architecture Framework (FEA) o DoD Information Environment Architecture (DoD IEA), version 2.0 o DoD Strategy for Operating in Cyberspace (DSOC) o Requirements management processes as defined within the Joint Capabilities Integration and

Development System (JCIDS)

Offeror’s proposed plans will be evaluated on the following PWS Task and Sub-Task areas:

Task Area 1: Systems Engineering, Subtask 1 – Technical Planning: Specifically PWS Paragraph 6.1.1. The offeror’s plan will be evaluated on the offeror’s ability to present a plan that provides a discussion of how the identified technological solution would be used in the DoD environment to enhance the warfighter’s capabilities.

The plan must clearly demonstrate the offeror’s method in defining scope and objectives of the technical planning effort, identifying constraints and risks, dividing the engineering effort into discrete manageable elements, and establishing initial schedule, cost, and performance elements.

Task Area 1: Systems Engineering, Subtask 2 – Design Analysis: Specifically PWS Paragraph 6.1.2. The offeror’s plan will be evaluated on the offeror’s ability to manage requirements and assumptions to establish decision-making criteria (objectives and measures), criteria weight, and associated rationale to frame/structure the criteria in terms of supporting mission objectives. The plan must clearly demonstrate the offeror’s ability to identify, analyze, and track requirements and alternatives to enable a stakeholder’s ability to make a determination of suitability of the proposed plan.

Task Area 2: Design Analysis Engineering: Specifically, PWS Paragraphs 6.2.1 and 6.2.4. The offeror’s plan will be evaluated on the offeror’s ability to analyze an enterprise’s technology landscape, to identify a technical capability gap, and to recommend a solution that solves the problem in an enhanced, new, or innovative way. The plan must clearly demonstrate the offeror’s ability to develop and propose advanced technological solutions and/or methodologies to enable an effective soundness assessment of the technical solution within the planning phase of the Systems Development Life Cycle (SDLC). The offeror’s plan shall incorporate capabilities to manage dependencies, functionality, interoperability, & performance; and showcase consideration of high-level extensibility and scalability capabilities for future changes in the technological, organizational, or mission landscapes.

PROBLEM STATEMENT #4:

For the Restricted Pool Open-Ended Problem Seeking Innovative Approach

PROBLEM STATEMENT: In an environment of constricting budgets and increased focus on value-to-warfighter plus the more general – but equally important – value-to-citizens – there is a need to formally capture and articulate the role, fit, function, and value proposition of DISA’s technological landscape within the strategic concept and tactical implications of defend the nation. To support this need, DISA stakeholders require a capability to map and articulate relationships between DISA’s technology areas, business functions, processes, and capabilities. This capability would be used to enable decision-making support to DISA leadership of the consequences and/or benefits of on and off boarding systems; and to synchronize the introduction of capability increments across the enterprise portfolio.

INTENDED OUTCOME: In responding to this problem statement, the offeror will propose a plan for developing an enterprise architecture. The offeror shall frame their plan around the use of the All Viewpoint, Capability Viewpoint Models, or any other Viewpoint that the offeror deems applicable to create a coherent model of the enterprise to enable effective decision-making and analysis (ref: DoDAF v2.02). The proposed plan will allow the Government to answer the following questions if the enterprise architecture roadmap were executed:

• How does a particular capability or capabilities support the overall mission/vision?

• What outcomes are expected to be achieved by a particular capability or set of capabilities?

• What is the relationship between services and capabilities?

• What is the functional scope and organizational span of a capability or set of capabilities?

• What is our current set of capabilities and services that we are managing as part of a portfolio?

• What impact will an insertion of a capability, at any point in the architecture, have on dependent capabilities?

• Would the proposed enterprise architecture plan facilitate management, planning, and execution of agile, adaptive, and dynamic operations that proactively evolve according to external and internal influences;

including, warfighter needs, the evolving threat environment, changing legislative and regulatory environment, and/or new DISA strategic and tactical priorities?

ASSUMPTIONS: The offeror shall make the following assumptions in responding to Problem Statement #4:

• Assume that DISA does not currently have a formal enterprise architecture that captures and codifies business functions, processes, and technological capabilities.

• Assume that there is no clear articulation of the relationships among current business and technology processes or between the business-side of DISA and the operations-side of DISA.

• Specific knowledge of current DISA technological capabilities is not necessary for the offer to present a plan for how they would develop an enterprise architecture to accomplish the intended objectives.

• Specific elements that could be included in the plan to develop an enterprise architecture are not limited to any one particular service, strategy, standard, project, or application.

• The presentation aspects shall not overemphasize the pictorial presentation at the expense of the underlying data necessary for adequate approach planning.

• Relevant reference information includes; but is not limited to:

o DoD Architecture Framework (DoDAF), version 2.02 o Federal Enterprise Architecture Framework (FEA) o DoD Information Environment Architecture (DoD IEA), version 2.0 o DoD Strategy for Operating in Cyberspace (DSOC) o Requirements management processes as defined within the Joint Capabilities Integration and Development System (JCIDS)