U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.3.2 Concept Exploration and Benefits Analysis

 

OBJECTIVE:

Concept Exploration identifies the promising and feasible projects for development. This activity assesses the best system alternative to implement based on cost and benefit.

DESCRIPTION:

The figure illustrates the Phase 0 steps leading to the definition of a project concept. This is the first step toward developing requirements. The goal is to describe the concept with enough concreteness to develop the concept of operations and to provide something tangible for stakeholder review. This is the bridge between needs and requirements. It is important to satisfy the stakeholders and development team that the selected solution is superior to all other alternatives, in order to start the development going in the right direction. The process is driven by project vision, goals, objectives, and constraints. It starts by collecting a broad and varied range of potential approaches to meeting the goals and putting them together into candidate system concepts. These are compared relative to the goals, objectives, and constraints. The recommendations provide a documented rationale for the shape the project will take and verification that it is feasible.

CONTEXT OF PROCESS:

 

Shows the flow for Phase [0] Task 2, Concept Exploration and Benefits Analysis Process.  Summaries are described for inputs, constraints, and enablers into the task;  activities of the task; and outputs from the task.  The flow is described in detail in the accompanying text.

CONCEPT EXPLORATION AND BENEFITS ANALYSIS PROCESS

Inputs:

Key needs come from the needs assessment; and identify the transportation needs that indicate a requirement for a project.

Constraints also come from the needs assessment; and identify limitations on the design and operation of the system.

Regional ITS Architectures, which may include statewide [inter-regional], sub-regional, or county-level; and the National ITS Architectureprovides guidance and context for the project concept.

Control:

Agency policy and procedures for the procuring agency will constrain the project. State and Federal policies may also influence choices.

Enablers:

Elicitation helps stakeholders provide essential inputs and review.

Trade studies compare alternative concepts.

Stakeholder involvement ensures that the concept meets the essential needs without violating any constraints.

Outputs:

Concept Exploration rationale documents the effectiveness and feasibility of the recommended project concept, including justification for the choice in terms of benefit and cost.

Recommended system concept describes the concept selected having the best benefit for the cost.

Feasibility assessment or FSR is the document that collects the recommendations and rationale. The agency may require a formal document in a specified form, such as California’s Feasibility Study Report [FSR]

Process Activities:

Each of the following steps is reviewed by the stakeholders.

Define vision

Write one paragraph describing in non-technical terms what the system will do. The idea is to allow lots of stakeholders to review it quickly.

Define goals and objectives

Describe what the potential project should accomplish from the point of view of the traveling public, the operating agencies and their operators, and other stakeholders.

Identity constraints

The constraints come from the regional architecture and inputs from the stakeholders [see Needs Assessment]. They will be used to determine feasibility. Constraints may include technical, organizational, funding, schedule, legal, and other considerations.

Define evaluation criteria

Evaluation criteria derive from the goals and objectives, and are the measures of effectiveness used to compare alternatives. Examples are response time for incident management and average system-wide speeds for a signal system.

Identify candidate solutions

Create a toolkit of technologies and procedures that may help meet the goals. The regional ITS architecture often provides ideas.

Identify alternative concepts

Build project concepts from the candidate solutions or select pieces from the regional ITS architecture. Consider several alternative system concepts that have a wide range of capabilities. [e.g.,  centralized, distributed, hybrid of both centralized & distributed]. Initially, keep these alternatives at a high level for comparison purposes.

Evaluate alternatives

Evaluate benefits, cost, and gaps then compare these alternatives using trade study technique.

Document results

Document conclusions and rationale in a report. Caltrans includes this benefits analysis in a Feasibility Study Report [FSR].

Illustrates where the Concept Exploration and Benefits Analysis are defined and refined in the Vee Development Model. The Concepts for the Region are defined in the Regional Architecture section of the Vee Development Model.  The Concepts for the Project are defined in the Concept Exploration section.  The Concepts are revisited and refined in the Concept of Operations section.

Where do Concept Exploration and Benefits Analysis take place in the project timeline?

Is there a policy or standard that talks about Concept Exploration and Feasibility Assessment?

FHWA Final Rule requires identifying the portion of the regional ITS architecture being implemented, identifying participating agencies, defining requirements, and analyzing alternatives.

Some states have documented requirements specifically for IT projects. In California, SAM 4819.35 [6/03] requires an FSR for all state IT projects except those with low costs or for acquiring microcomputer commodities.

Which activities are critical for the system’s owner to do?

  • Describe needs, vision, goals, objectives, and constraints
  • Suggest or review evaluation criteria
  • Review candidate concepts
  • Review the selection process and conclusions
  • Approve the selected concept

How do I fit these activities to my project? [Tailoring]

The level of each activity should be appropriately scaled to the size of the project and the number of unique needs. The following guidance can be used for tailoring on small projects that have widely known capabilities [e.g., signal systems, CMS, and CCTV]. A qualitative comparison with a limited number of alternatives.

If the operational system will be significantly different from the one it replaces or it depends the following:

  • Significant operational changes
  • increased inter-agency coordination
  • a new set of unique needs

In these types of projects, alternatives analysis may need to be explored in more detail.

This activity may also be dictated by state or regional reporting requirements. For example, FSR must be approved by the State of California for ITS projects with IT components.

What should I track in this process step to reduce project risks and get what is expected? [Technical Measures, Metrics]

On the technical side:

  • Selected Technical Measures of the system [project-specific] will be used to compare alternatives

On the project management side:

  • Number of candidate solutions
  • Number of alternative concepts
  • Percentage of candidate concepts evaluated
  • Percentage of stakeholders who have approved the study

Checklist: Are all the bases covered?

check Is there a validated statement of vision, goals, and objectives?
check Have constraints been collected from all key stakeholders?
check Has the evaluation criteria in comparing alternatives been selected, validated, and documented?
check Is there a comprehensive list of candidate solutions, both technical and procedural?
check Is there a comprehensive and varied list of alternative concepts?
check Is the "Do Nothing" case one of the alternatives?
check Has the comparison approach been documented and validated?
check Has the selected concept, and the rationale for its selection, been documented; and has it been reviewed by the stakeholders?
check Does the documentation satisfy relevant reporting standards, if any, for example, for a Feasibility Study Report if required by the state?
check Do the conclusions and recommendations flow in a clear and defensible manner from the needs, alternatives selection, and analysis?

Recommendation.Are there any recommendations that can help?

 Stakeholder involvement is essential at this point to translate needs into requirements. Be sure that the views of operators, owners, maintainers, managers, the traveling public, and other stakeholders are included.

Why is a conceptual architecture being developed this early? Isn’t this getting into design?

There needs to be enough specificity to start designing the system. Here it is done at a very high level. For example, one may need to decide whether the system is distributed or centralized. This will make a difference in how the system will be used. The Concept of Operations cannot be written until this is resolved. In other cases there may be multiple ways to meet a need. For example, before designing a bridge, one might need to verify that a bridge is a more cost-effective approach than expanding the existing ferry service.

One will see these same steps used in the design process, but at a much more detailed level. At this point, the concepts should be developed in no more detail than is necessary to provide a structure for the Concept of Operations. The concept is a tool to gather a complete set of needs and expectations from the stakeholders. It will be successively defined in increasing detail, as discussed under the Concept of Operations topic. [Ch. 3.4.3]

A closer look at identifying candidate solutions is key to making sure that all of the viable approaches have been evaluated.

The candidate solutions are the toolkit of technologies and COTS sub-systems and procedures that will help achieve the desired goals.

Generally, for complex systems it takes the integration of a number of solutions to address all of the user needs. Examples of candidate solutions are detectors, controllers, workstations, software, and communications.

First, review all relevant literature. Search the web. Query the key stakeholders, colleagues, and technology experts. Brainstorm around each need. Examine what procedures or technologies could help meet the need. Describe each potential solution at a high operational level. For example, a detector that can provide traffic speeds or vehicle-to roadside communication.

Using information gathered from above, construct a straw man list of alternatives [pros and cons of each], and needs satisfied by each. Query all stakeholder groups. Ask if they think each list is complete. Ask if they have anything to add, modify, or suggest.

Calculate a rough life cycle cost, risk, or other relevant drawback for each alternative, such as political issues, time to implement, or manpower required. Modify the choices where appropriate, possibly changing some alternatives.

Developing alternative concepts comes by synthesizing the candidate solutions into complete systems that work together to meet some of the needs. Be sure the list includes a broad range of approaches. The following are some possible classes of alternative analysis:

  • Do nothing This is one comparison case, the choice of just leaving everything as is. A business case needs to be developed that the project will generate benefit commensurate with its costs
  • Do everything This is the high-end system
  • Simple and cheap This is the cost-conscious system, possibly an evolutionary step toward a later “do everything” system
  • Single need Focus on the one most essential need
  • Centralized Operate from a central point
  • Distributed Operate from local points that co-ordinate
  • Procedural Solve the problem without technology e.g., regulatory
Checklist  
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000