Mitre Solution-Service Strategy Guidance V2.0 August 2022.pdf

Solution/Service Strategy Development Guidance

Version: 2.0

August 24, 2022

© 2022 The MITRE

Corporation. All rights reserved.

Federal Government – unlimited usage rights.

i

© 2022 The MITRE Corporation. All rights reserved.

Federal Government – unlimited usage rights.

Version History

Version Date Change Description Author of Change

1.0 6/11/2019 Baseline Release MITRE

2.0 8/24/2022 Updates guidance to reflect changes to solution/service strategy development process

MITRE

ii

Federal Government – unlimited usage rights.

Table of Contents

Overview of Solution/Service Strategy Development Guidance

Purpose and Usage

Contents

Solution/Service Strategy Development

Develop Objectives, Assumptions, and Constraints (OACs)

Define Business Needs/Standards

Conduct Inventory and Analysis of Current State

Develop Future State Solutions Landscape

Market Analysis

Future State Solution/Service Landscape Architecture

Develop Delivery and Implementation Strategies

Delivery Strategy

Implementation Strategy

Develop Workforce Strategy

Develop Acquisition Strategies

Technology Acquisition Strategy

Human Resources Acquisition Strategy

Develop Cost Estimates

Develop Funding Strategy

Determine Risks and Mitigation Strategies

Solution/Service Strategy Maintenance

Updates to the Solution/Service Strategy

Synchronization

Appendix A Guidance and Templates ..................................................................................... A-1

Appendix B Sample OACs...................................................................................................... B-1 iii

Federal Government – unlimited usage rights.

List of Figures Figure 2-1. Solution/Service Strategy Process

Figure 2-2. Federal Integrated Business Framework (FIBF) Components

Figure 2-3: Example of Future State Business Operating Model

Figure 2-4: Sample Format for Summary Market Research Results by Objective and Activity ... 7

Figure 2-5: Example of Future State Solution/Service Landscape Architecture

Figure 2-6: Sample Format for Business Capability Delivery Strategy

Figure 2-7: Example of Solution/Service Implementation Strategy

Figure 2-8: Example Excerpts from Workforce Strategy

Figure 2-9: Sample Format for a Cost Summary

Federal Government – unlimited usage rights.

Overview of Solution/Service Strategy Development Guidance A Solution/Service Strategy provides the information needed to make investment decisions, obtain funding, and oversee the acquisition, implementation, and operation of a single solution/service or a collection of solutions/services. This document provides a guide to developing the contents of a Solution/Service Strategy.

Purpose and Usage

The Solution/Service Strategy should be used to ensure:

• Stakeholders have a common understanding of the future state business operating model and solutions/services and the approaches to be used for their funding, acquisition, implementation, and sustainment.

• The program/project management team has the foundational information needed to plan and manage the program/project.

• Implementation and sustainment teams maintain continuous alignment between the future state solutions/services and the future state business operating model.

Contents

A fully developed Solution/Service Strategy should contain the following information:

• Objectives, Assumptions, and Constraints (OACs) – provides the desired outcomes and boundaries for achieving and sustaining the future state

• Business Needs/Standards Definition – provides the future state business operating model that the solutions/services must support or enable

• Inventory and Analysis of Current State – provides the current state systems/tools and information assets and their alignment with the future state business operating model

• Future State Solutions Landscape – provides the conceptual architecture of existing, modified, and new solutions/services that will support the future state business operating model and identifies current state systems/tools to be retired

• Delivery and Implementation Strategies – provides the scope and sequencing for incrementally delivering business capabilities identified in the future state business operating model and implementing the technologies identified in the future state conceptual architecture

• Workforce Strategy – provides the roles, skills, and competencies needed to implement and sustain the future state business operating model and solutions/services and identifies approaches to ensuring these are available when needed

• Acquisition Strategies – identifies the approaches to acquire the technologies and human resources needed to implement and sustain the future state business operating model and solutions/services

Federal Government – unlimited usage rights.

• Cost Estimates – provides the estimated costs of the technologies and human resources needed to implement and sustain the future state business operating model and solutions/services

• Funding Strategy – provides the funding and/or revenue sources, timeframes, and amounts needed to implement and sustain the future state business operating model and solutions/services

• Risk Management Strategies – provides potential risks to implementing and sustaining the future state business operating model and solutions/services

Solution/Service Strategy Development The Solution/Service Strategy process includes activities to:

• Identify and document agreed upon objectives, assumptions, constraints

• Define business needs

• Document the current and potential future technology and data landscape

• Identify resources to implement and sustain the solution/service

• Define approaches for implementation, delivery, acquisition, and funding

• Identify risk and mitigation strategies

The Solution/Service Strategy development process is presented in Figure 2-1.

Figure 2-1. Solution/Service Strategy Process

The Solution/Service Strategy should use consistent terminology throughout the sections and ensure each section’s content has explicit ties to content in previous sections (e.g., Data Groups and Actors on the architecture graphic match those on the business operating model graphic).

Federal Government – unlimited usage rights.

Develop Objectives, Assumptions, and Constraints (OACs)

OACs provide the framework and boundaries for executing and evaluating the initiative or project. They provide a shared context and understanding for collaborative decision-making and are used to evaluate potential solutions against criteria derived from business needs. The OACs are categorized into six groups:

1. Business: Business processes used to achieve mission outputs or outcomes

2. Organizational: Organization capabilities, skills, and resource levels

3. Technology Design: Architecture and design of solutions/services that support the business processes

4. Technology Operation: Solution/service demand, support, and ongoing operation

5. Programmatic: Governance, legislation/regulations, accountability, integration, and dependencies with other initiatives

6. Economic: Funding, cost, contracting, and marketplace

Objectives should be developed for each category to ensure the expectations from all viewpoints have been explored and balanced (e.g., mission/business, IT, budget/finance, acquisition, human capital). Assumptions and constraints may or may not be needed for each Objective.

Assumptions should capture suppositions or beliefs that impact achieving the specified objective and, if changed, they may affect the ability to achieve the objective and/or the approach used for the other components of the solution strategy (e.g., current workforce will be retained and re-trained instead of hiring contractors with skills/competencies needed). Constraints are derived from pre-existing conditions, decisions, or plans and affect the ability to meet an objective and/or the approaches that can be considered for the other components of the solution strategy (e.g., a specific technology previously selected by an agency that must be considered before acquiring a similar technology).

As part of each development process in the Solution/Service Strategy, OACs should be reviewed and refined as needed. Appendix B provides example OACs.

Define Business Needs/Standards

The business needs/standards for the future state business operating model should be documented using the Federal Integrated Business Framework (FIBF) components depicted in

Figure 2-2. The FIBF components include Functions and Activities, Business Capabilities, Business Use Cases, Business Data Elements, and Service Measures that need to be supported by the future state solution(s)/service(s).

Figure 2-2. Federal Integrated Business Framework (FIBF) Components

If FIBF components have not been developed for a Functional Area within the scope of the future state business operating model, the FIBF components should be developed by leveraging the corresponding FIBF guidance and templates (see Appendix A for a list of FIBF guidance documents and templates). When developing FIBF components, they should be developed in the following order for each Functional Area within scope of the future state business operating model:

• Functions and Activities

• Business Capabilities and Business Use Cases

• Business Data Elements

• Service Measures

Note that as each FIBF component is developed, there will likely be updates to the previous

FIBF components to ensure that all FIBF components align with each other when completed.

1. Once the business needs/standards have been defined, prioritize the Functional Areas, Functions, and Activities that need to be supported by the future state solution(s)/service(s).

2. Develop a visual representation of the future state business operating model. The diagram should include:

a. The Functional Areas/Functions/Activities the future state landscape must support or enable and those that are external to the future state landscape (denote the difference visually through line boundaries or shape differences).

Federal Government – unlimited usage rights.

b. The Data Groups (documented in the Business Data Elements) that are exchanged between Functions/Activities (as much as possible, position Functions/Activities so information flows left to right and top to bottom in the diagram).

c. Icons denoting the Actors (documented in the Business Use Cases) that interact with each Function/Activity and the Data Group(s) they provide to and/or receive from the

Function/Activity.

Figure 2-3 provides an example of a visual representation of a future state business operating model.

Figure 2-3: Example of Future State Business Operating Model

Conduct Inventory and Analysis of Current State

Once business needs/standards are identified, develop an inventory of the current state systems/tools and business information assets using the Systems-Tools Inventory Template and the Information Asset Inventory Template. Assess the current state is against the defined business needs/standards to identify the following:

• Functional Areas/Functions/Activities that current state solutions/tools fully or partially perform or support users in performing

• Business needs gaps – specific Functional Areas/Functions/Activities that are not performed/supported or only partially performed/supported

• Multiple systems/tools performing/supporting the same Functional

Area/Function/Activity

Federal Government – unlimited usage rights.

• Systems/tools and technologies that are (or soon to be) obsolete or have other risks (e.g., not compliant with security standards or uncertain source of continued operations funding)

• Systems/tools that provide the intake or creation point for an information asset, maintain

(e.g., update, archive) an information asset, or provide access to an information asset

• Multiple systems/tools providing the same or similar services for the same information asset and/or used as the originating/authoritative source for the same information asset

• Commonality of information asset use across business Actors

• Information assets that require stronger access controls or have special handling/use restrictions (e.g., sensitive, classified, or proprietary data)

Develop Future State Solutions Landscape

The future state solution/service landscape provides a conceptual architecture that satisfies the business needs/standards and the OACs and is developed based on the current state solutions/tools analysis and a market analysis of potential new solutions/services.

Market Analysis

If the analysis of current state system/tools and business information assets identifies gaps or risks to be addressed, a market analysis may need to be performed that identifies potential solutions/services to address the gaps/risks, evaluates them against business functions/activities and OACs, and identifies one or more suitable solutions/services. The market analysis should be completed by collecting information on each solution/service and documenting observations of how well each solution/service aligns to each OAC and Activity. Many sources of information may be used in the evaluation, including design documentation and description information from the public internet, interviews with vendors, and researching market survey information for other projects.

After documenting observations, conclusions should be developed for how well each solution satisfies each OAC and Activity. An overall rating should be assigned for each solution/service for each Objective based on the conclusions. Based on the results of the market analysis, refine the business needs definition and the OACs (if needed).

Figure 2-4 provides a sample format for presenting a summary of market research results by

Objective and Activity.

Figure 2-4: Sample Format for Summary Market Research Results by Objective and Activity

Future State Solution/Service Landscape Architecture

Develop the future state solution/service landscape architecture based on the results of the current state (systems/tools and business information assets) analysis and market analysis.

Identify components of the future state solutions/services landscape as one of the following disposition types:

• Current state system to retain (“retain as is”)

• Current state system to retain with enhancements (“retain and modify”)

• New solution/service to be added (“new”)

• Current state system to be retired (“retire”)

For those components that are current state systems/tools, update the current state Systems/Tools

Inventory to document the proposed disposition type.

For those components that are “new”, use the Systems/Tools Inventory guidance and template to document the characteristics of the new components to the extent they are known (see

Attachment A for a list of relevant guidance and templates).

Develop the Future State Solution/Service Landscape Architecture (single graphical view of the future state solutions/services landscape) that satisfies the OACs and business needs. At a

Federal Government – unlimited usage rights.

minimum, the Future State Solution/Service Landscape Architecture should provide the following information:

• Functional Areas, Functions, and Activities performed by each solution/service and each current state system/tool, future state solution/service, and Actor that interfaces with the solution/service. Note there may be instances where a current state system/tool is retained but no longer interacts with any components in the future state landscape.

• External components (systems/tools/solutions/services) or Actors that interact with each solution/service.

• Information flows between future state components and Actors, both inputs and outputs.

Each information flow should indicate the Data Group(s), and the Data Group(s) should match those that are used in the visual representation of the business operating model developed as part of the Business Needs Definition.

• For each future state component, its disposition type.

• A list of the current state systems/tools that are being retired.

Each future state component should be represented in a way that identifies:

• The provider of the component if known; if not known, whether proposed to be a government or commercial provider

• The physical location of the component if known; if not known, whether proposed to be on premise or off premise

• Key technologies used in the component

• Any significant sub-components such as infrastructure services, information repositories, and sub-processing services

• If significant, information flows between sub-components.

The Future State Solution/Service Landscape Architecture should also be accompanied by a description of the main points that are being communicated by the Architecture. These should be drafted from the results of earlier sections that influenced the Architecture. For example, the main points may include which OACs resulted in key architecture decisions or how the Market

Analysis results directed what technologies were included and how they were used in the

Architecture. After completing the Architecture, refine the OACs if needed.

Figure 2-5 provides an example of a Future State Solution/Service Landscape Architecture.

Figure 2-5: Example of Future State Solution/Service Landscape Architecture

Develop Delivery and Implementation Strategies

Develop the business capability delivery and solution/service implementation strategies. The

Business Capability Delivery Strategy describes the sequence in which Functional

Areas/Functions/Activities/Business Capabilities will be delivered to end users. The

Solution/Service Implementation Strategy describes the approach and sequence to implement the components of the Future State Solution/Service Landscape Architecture. Each strategy includes dependencies between and priorities driving the sequenced components.

Delivery Strategy

The Business Capability Delivery Strategy documents which Functional

Areas/Functions/Activities/Business Capabilities will be met by each solution/service (or sub-components of a solution/service) and the sequence of planned releases. The Business Capability

Delivery Strategy should be developed using the following steps:

1. Write a summary of each release that describes the overall outcome accomplished by the release and how the release relates to OAC Business and Organizational Objectives and the other releases.

2. Define the scope of each release and the metrics for how far each release progresses in reaching full capability (e.g., the population of users that are supported, percentage of needed data that is addressed, or which agencies are participating)

3. Document the rationale that describes why the scope was selected for each release.

Federal Government – unlimited usage rights.

4. Document which Functional Areas/Functions/Activities/Business Capabilities and Data

Groups are addressed in each release

5. Document which Actors will be impacted by the release (include business information exchange data groups between functional areas).

6. Document which Architecture components will be included in the release.

7. Document which current state systems/tools are eligible for retirement after each release is completed.

Figure 2-6 provides a sample format for the Business Capability Delivery Strategy.

Figure 2-6: Sample Format for Business Capability Delivery Strategy

Implementation Strategy

The Solution/Service Implementation Strategy documents the engineering approach to be used to design, deliver, and operate each solution/service (or components of a solution/service).

Implementation strategies should be based on proven engineering approaches such as waterfall, Federal Government – unlimited usage rights.

agile/iterative, op/dev, or Modernization and Migration Management (M3). The strategy should be detailed enough to provide a guide for the implementation teams to begin to develop a project management plan. The Solution/Service Implementation Strategy should be developed using the following steps:

1. Define the approach for system development or sourcing services. This includes the development approach (e.g., agile or waterfall), pattern for releases (e.g., spiral or iterative), key milestones, and the definition of engineering phases that will be followed.

2. Define the contents of each engineering phase. Draft the outcomes for each phase. List the artifacts that will be produced and how they will be used in each release. Identify exit and entrance criteria for each phase.

Figure 2-7 provides an example of agile engineering phases with sample outcomes.

Figure 2-7: Example of Solution/Service Implementation Strategy

Develop Workforce Strategy

Determine roles, skill/competency profiles, and sources of personnel needed to implement, manage, support, and operate the future state solution(s)/service(s).

The Workforce Strategy should be developed using the following steps:

Federal Government – unlimited usage rights.

1. Use Business Needs Definition, Architecture, and Delivery and Implementation

Strategies to identify and confirm roles required for the implementation, management, support, and business and technology operation of the future state solutions/services.

2. Define the skill/competency profile required for each role, including the skills (e.g., software development), competencies (e.g., project management), and experience.

3. Identify which implementation, management, support, and operation roles are best fulfilled by agency internal government personnel, external government personnel (e.g., QSMO), and contractor personnel.

Figure 2-8 provides example excerpts from a Workforce Strategy.

Figure 2-8: Example Excerpts from Workforce Strategy

Develop Acquisition Strategies

Determine acquisition strategies for the future state solutions/services and human resources.

Develop a Technology Acquisition Strategy for each component in the Future State

Solution/Service Landscape Architecture. Develop a Human Resources Acquisition Strategy for roles based on the implementation, management, support, and business and technology

Federal Government – unlimited usage rights.

operations workforce analysis. Other acquisition strategy contents should be added if a different category of products or services are required to implement the future state solution/service landscape.

Technology Acquisition Strategy

For each component in the Future State Solution/Service Landscape Architecture, the

Technology Acquisition Strategy should include:

• Source (vendor or service provider) that the technology will be acquired from

• Technology products that will be used to implement the component. If a component requires more than one technology product, group the vendors and their products by component

• Internet reference, acquisition schedule, or purchase link that was the source of the information for acquiring the technology

Human Resources Acquisition Strategy

The Human Resource Acquisition Strategy provides a high-level description how personnel will be acquired/assigned to address each role in the Workforce Strategy section. For each personnel role, the strategy should include:

• Source of personnel to fulfill the role, either Government (Agency Internal or External), Contractor, or both

• Solution/Service Implementation Strategy phase when the personnel need to be involved.

Personnel may need to be added in an earlier phase to plan for when they will be contributing to a later phase. For example, the leads for each Implementation Phase need to be actively supporting the planning phase that is normally the earliest phase.

• Approach to obtain Agency External personnel needed to fulfill a role (e.g., intra-governmental agreement, memorandum of understanding (MOU))

• Available contract vehicles for the Contractor staff needed to fulfill a role. Available contract vehicles may be those that are currently on contract or those that would be most suitable for a new procurement (e.g., consider active contracts, then schedules, then new procurement)

• Decisions that have been made about priority sources for personnel

• Decisions that need to be made after approval of the proposed solution.

Develop Cost Estimates

Develop a cost model for the future state solutions/services defined in the Future State

Solution/Service Landscape Architecture and the human resources defined in the Workforce

Strategy. The cost model should include:

• Cost estimates for implementing, managing, supporting, and operating the future state solutions/services summarized by the Business Capability Delivery Strategy releases and

Federal Government – unlimited usage rights.

Solution/Service Implementation Strategy phases and categorized into, technology and human resources

• A high-level summary of all costs by fiscal year (FY) and, if needed, categories that will influence sources of funding (e.g., development vs. operations and maintenance, technology vs. workforce)

• Key cost assumptions, costing approach, and basis of estimates.

Refer to the GAO Cost Estimating and Assessment Guide (GAO-09-3SP) for specific guidance on developing rough order of magnitude estimates. Figure 2-9 provides a sample format for presenting a cost summary.

Figure 2-9: Sample Format for a Cost Summary

Develop Funding Strategy

Determine funding and/or revenue sources and availability-usage timeframes. Identify potential funding and/or revenue sources and level and timing of potential available funds. Assess potential funding and/or revenue sources against identified usage of funds by fiscal year documented in the high-level cost summary.

Determine Risks and Mitigation Strategies

Identify risks and determine risk management strategies throughout the process of developing the

Solution/Service Strategy. Identify risks associated with:

• Fully satisfying the OACs

• Fully addressing business needs/standards

Federal Government – unlimited usage rights.

• Future state solution/service landscape architecture implementation, management, support, and business and technology operation

• Delivery and implementation strategies

• Workforce strategy

• Acquisition strategy

• Cost estimates

• Funding strategy

Do not include risks that are normally addressed through proper project/program management and systems engineering management (e.g., contractors delivering products on schedule or participation by external stakeholders).

Assess probability and impact of each risk. Risks with medium-to-high probability and medium-to-high impact should be documented in the risk management strategy. Determine a risk management strategy (e.g., mitigate, avoid, accept, transfer) for each risk.

Solution/Service Strategy Maintenance

Updates to the Solution/Service Strategy

Once approved by appropriate executive bodies, the Solution/Service Strategy document should be used during acquisition, development, and implementation. The document should be updated when changes occur, for example:

• The Architecture should be updated if the acquired technology is different, or interfacing systems change.

• Decisions made or actions taken to address risks may need to be added to the OACs or reflected in the appropriate Solution/Service Strategy section (e.g., a decision is made to implement an Architecture component that otherwise would have been available in a later release/phase, then the Delivery and Implementation Strategies should be updated to reflect the move of Architecture component from later to an earlier release/phase).

Synchronization

Since the Business Needs Definition sections are summaries of FIBF products that are maintained separately, the related sections in the Solution/Service Strategy should be updated when changes are made to the FIBF source products. The related sections in the Solution/Service

Strategy need to remain up to date with the FIBF products to ensure that the Solution/Service

Landscape Architecture will address updated business needs.

The Solution/Service Strategy should be kept synchronized with changes in the current state

Systems/Tools and Business Information Asset Inventories. The Architecture should be reviewed for changes whenever these inventories are updated.

A-1

Appendix A Guidance and Templates

The following lists the guidance documents and templates available for use during business needs definition and current systems/tools and business information assets inventory and analysis. The version numbers and dates noted in the filenames are as of the date of this document.

Federal Integrated Business Framework Guidance and Templates

Functions and Activities

• FIBF Service Activity List Guidance V1.1 April 2020.docx

• FIBF Service Activity List Template V1.0 Sept 2021.docx

Business Capabilities

• FIBF Business Capabilities Guidance V1.0 June 2019.docx

• FIBF Business Capabilities Template V1.0 June 2019.xlsx

Business Scenarios and Use Cases

• FIBF Business Scenarios and Use Case Guidance V1.0 Sept 2019.docx

• FIBF Business Use Case Template V1.0 Sept 2019.docx

Business Data Elements

• FIBF Business Data Elements Guidance V2.1 May 2022.docx

• FIBF Business Data Elements Template V2.2 May 2022.xlsm

Service Measures

• FIBF Service Measures Guidance V2.01 June 2022.docx

• FIBF Service Measures Template V2.01 June 2022.docx

Current State Inventory and Analysis Guidance and Templates

• Systems-Tools Inventory Guidance V2.0_20210705.docx

• Systems-Tools Inventory Template V2.0_20210705.xlsx

• Business Information Asset Inventory Template-Guidance v1.01 20220107.xlxs

B-1

Appendix B Sample OACs

BUSINESS: Focuses on business improvements to achieve desired outcomes

Objectives:

BU.O1 Enable new and enhanced services to improve management.

BU.O2 Improve user experience.

BU.O3 Improve data/information discovery and analysis.

BU.O4 Increase transparency, accountability, and public trust in the process.

BU.O5 Ensure informed adoption and usage of services.

Assumptions:

BU.A1 FIBF artifacts (i.e., Function-Activity List, Business Capabilities, Use

Cases, and Data Elements) will be baselined and maintained throughout the process.

ORGANIZATIONAL: Focuses on Key Stakeholder Roles, Capabilities, Skills, and

Resource Levels to Achieve Desired Outcomes

Objectives:

OR.O1 Leverage key organizations to achieve an integrated set of services.

OR.O2 Leverage subject matter experts from Agencies, OMB, and other key stakeholders to inform modernization and program improvement.

Assumptions:

OR.A1 Business standards development will leverage a Working Group and the

Business Standards Council (BSC) for input and recommendations.

B-2

Federal Government – unlimited usage rights.

TECHNOLOGY DESIGN: Focuses on Solution/Service Architecture and Design to

Support Business Processes

Objectives:

TD.O1 Integrate separate systems into a single enterprise architecture.

TD.O2 Implement a common data repository and standards across systems.

TD.O3 Leverage cloud-based solutions.

TD.O4 Provide a modern user interface to improve the user experience

Assumptions:

TD.A1 Existing code can be refactored into the new architecture.

Constraints:

TD.C1 Systems that are no longer supported (or will be soon) must be replaced to mitigate security vulnerabilities.

TECHNOLOGY OPERATIONS: Focuses on Solution/Service Demand, Support, and

Operation

Objectives:

TO.O1 Transition to new services and solutions without impacting current services and activities.

TO.O2 Adapt and scale new solutions to increase capacity, add new capabilities, and implement business process changes.

PROGRAMMATIC: Focuses on Governance, Accountability, Integration, and

Dependencies on Other Initiatives

Objectives:

PR.O1 Increase federal agency engagement in the continuous improvement of solution/service capabilities.

PR.O2 Increase public engagement in the continuous improvement of the solution/service capabilities.

B-3

Federal Government – unlimited usage rights.

ECONOMIC: Focuses on Funding, Costs, Acquisition, and Marketplace for the

Solution(s)/Service(s)

Objectives:

EC.O1 Improve the value and cost effectiveness of services.

EC.O2 Reduce operations and maintenance (O&M) costs.

Assumptions:

EC.A1 Initial investments to modernize solutions will enable lower O&M costs.

Constraints:

EC.C1 Modernization efforts will be limited by fiscal year funding availability.