U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
Concept Exploration identifies the promising and feasible projects for development. This activity assesses the best system alternative to implement based on cost and benefit.
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:
CONCEPT EXPLORATION AND BENEFITS ANALYSIS PROCESS
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.
Agency policy and procedures for the procuring agency will constrain the project. State and Federal policies may also influence choices.
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.
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]
Each of the following steps is reviewed by the stakeholders.
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.
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 benefits, cost, and gaps then compare these alternatives using trade study technique.
Document conclusions and rationale in a report. Caltrans includes this benefits analysis in a Feasibility Study Report [FSR].
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?
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:
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:
On the project management side:
Checklist: Are all the bases covered?
|Is there a validated statement of vision, goals, and objectives?|
|Have constraints been collected from all key stakeholders?|
|Has the evaluation criteria in comparing alternatives been selected, validated, and documented?|
|Is there a comprehensive list of candidate solutions, both technical and procedural?|
|Is there a comprehensive and varied list of alternative concepts?|
|Is the "Do Nothing" case one of the alternatives?|
|Has the comparison approach been documented and validated?|
|Has the selected concept, and the rationale for its selection, been documented; and has it been reviewed by the stakeholders?|
|Does the documentation satisfy relevant reporting standards, if any, for example, for a Feasibility Study Report if required by the state?|
|Do the conclusions and recommendations flow in a clear and defensible manner from the needs, alternatives selection, and analysis?|
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: