U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
Federal Highway Administration Research and Technology
Coordinating, Developing, and Delivering Highway Transportation Innovations
|This report is an archived publication and may contain dated technical, contact, and link information|
|Publication Number: FHWA-HRT-11-064 Date: November 2011|
Publication Number: FHWA-HRT-11-064
Date: November 2011
The project development process is a long and complex process involving many analysts, many stakeholders, and many analysis tools. The process is a complex system in which the objective of the agency is to manage the risk inherent in the project so as to deliver the project on time and within budget. The way to manage risk is to take it explicitly into consideration in the development of an overall analysis plan for delivering the transportation improvement project. Thus, it is recommended that, at the project initiation stage, the agency develop an overall scope, approach, budget, and timeline for delivering the project. This plan is the PDAP.
Readers familiar with systems engineering will recognize the PDAP as performing the same function as a systems engineering management plan.(3) In fact, training in systems engineering is very useful in accomplishing the recommendations of this chapter.
Scoping and budgeting a traffic analysis include the same basic issues and tensions typical of any work-scoping effort. There is the perpetual tension between the ideal and the achievable. The decisionmakers want it all, but they only allow the manager a certain amount of time, budget, and resources to deliver the analysis. The manager must find an approach to the technical analysis that gives the decisionmakers the best information possible within the available resources.
Technical analysts often think of time as their friend, asking for more whenever they can, but time is the enemy of good technical analysis, the enemy of consistency, and, ultimately, the enemy of project delivery. While a minimum amount of time is required to perform an authoritative and accurate technical analysis, the world does not stand still while the analysis is conducted. Conditions change, assumptions become outdated, decisionmakers change, and even technical analysts change. The decisionmaking value of a technical analysis has a limited shelf life, decaying in value from the day the analysis is initiated.
Another basic fact often missed in the development of a PDAP is the necessarily evolving nature of the project as it proceeds through the project analysis process. What starts out as a straightforward high-occupancy vehicle (HOV) lane project may turn into a high-tech congestion pricing (high-occupancy toll (HOT) lane) project by its end. An interchange reconstruction may expand to include auxiliary lanes and ramp meters. Funding constraints may rule out key project components as cost estimates are refined. While not all changes can be anticipated, the PDAP must employ tools and methods that can be readily adapted or expanded to the evolving project description. Ideally, the manager leaves a reserve in the PDAP both in terms of time and budget to absorb the surprises that inevitably arise during the project development process.
Finally, the project needs and purpose will evolve as technical analyses are completed and as the various stakeholders participate in the process. The tools and procedures identified in the PDAP need to be flexible and general enough to accommodate these changes.
Developing the PDAP is all about managing the risk and complexity of a multistage, multitool project delivery process with evolving project needs and description in a changing world that often threatens to render earlier decisions and assumptions obsolete.
The PDAP is the agency's opportunity to coordinate how the project is evaluated and to maintain consistent analyses throughout the project development life cycle. It is the master scope and the scalable scope for all subsequent technical analyses of the project and its alternatives. The PDAP should cover the following topics:
The conceptual project description summarizes the project need and purpose, describes the overall concept for the project, describes possible project alternatives, and identifies the facilities and agencies likely to be affected by the project or its alternatives. Much of this material is a summary of the contents of the project initiation document. The purpose of summarizing this information in the PDAP is to establish the context for the traffic analysis objectives and the scope for the analysis.
The conceptual project description should attempt to bind the feasible range of conceptual alternatives and the likely effects of the project and its alternatives. The manager should slightly overestimate the likely geographic and temporal effects and let the subsequent technical analyses narrow the range of feasible alternatives and the expected range of effects.
The goals and objectives of the traffic analysis identify the questions that the analysis will need to answer and the required detail of the answers. The goals describe the general traits of the project (e.g., reduces congestion) while the objectives identify quantifiable measures of project performance (e.g., reduces delay to agency standards). The objectives should cover all stages of the project development cycle but may vary for each stage of the analysis. For example, in the early project initiation stage, the analysis may be focused more on identifying the demands to be served by the conceptual project and its general performance in comparison to the feasible alternatives and less on the specific details of the project's operation. Later in the development process, the focus is on pinning down the design details of the project and understanding in more detail the precise operational performance of each component of the project.
In this section of the PDAP, the manager identifies the MOEs to be generated by the traffic analysis at each stage of the project development process and how the results of the analysis will be presented to decisionmakers and the general public. The MOEs are the numerical outputs of the traffic analysis that address the specific objectives of the project. Examples of typical traffic MOEs include delay, stops, queues, speed, density, and travel time. These measures may be aggregated into vehicle-miles traveled (VMT), person-miles traveled (PMT), vehicle-hours traveled (VHT), or person-hours traveled (PHT). The MOEs may vary to address the objectives of each stage of the project development process. (MOEs and the presentation of analysis results to decisionmakers and the general public are covered in more detail in subsequent chapters.)
The overall traffic analysis approach is described in this section. Where feasible, the specific tools, assumptions, and parameters are specified for each stage of the project development process. The approach describes how the tools, assumptions, and parameters will be coordinated between tools and analysis stages. (This topic is covered in more detail in chapter 5.)
In this section, the manager identifies the risks to successfully completing the analysis on time and within budget. Risks can include changes in project purpose, changes in project concept, personnel changes, stakeholder changes, changes in assumptions driven by changes in the real world, advances in tools, agency unfamiliarity with specific tools, etc. For each risk, the manager describes the planned course of action to overcome the risk (fallback analysis approach) and the point in the analysis process when a go/no-go decision must be made.
This section identifies the personnel and budgetary requirements for each stage of the analysis.
This section identifies key milestones, delivery dates, critical path, and risk management decision points for each stage of the analysis.
Many agencies may have a standard PDAP already in place. It may exist under a different name, such as a Project Development Procedures Manual, and may cover a broader range of project delivery tasks than simply traffic analysis. If such a manual is already in place, then the duty of the manager charged with project delivery is to tailor the general guidance provided in the agency's manual to a specific traffic analysis plan for project delivery.
This section focuses on the specifics of scoping the overall traffic analysis plan for project delivery. As such, it may be helpful to agencies that already have a project delivery procedures manual because this section will address traffic analysis specifics that may not be covered in sufficient detail in a broader manual.
The steps for developing the PDAP are as follows:
These steps are shown in figure 6 and discussed in more detail in the following sections.
Figure 6. Chart. Steps to development of PDAP.
There will be a set of overall goals and objectives for project delivery. These will naturally follow from the project need and purpose statement. However, the manager should also identify specific analysis goals and objectives for each stage of project delivery.
For example, a project needs and purpose statement may read, "The section of highway X fails to meet agency standards for safety, pollutant emissions, and traffic operations." The project then has the following purposes:
While the goals for the project may be fairly general, it is desirable to refine the project goals as the project analysis proceeds to specific, measureable objectives. By the end of the analysis, the project objectives should be SMART: Specific, Measurable, Agreed upon, Realistic, and Time-bound.
The goal of the PDAP for the project is distinct from the goals and objectives of the project. The goal of the PDAP is to provide the data necessary to determine the design of the most cost-effective project for achieving the project purpose within budgetary and environmental constraints relevant to the project. This overall goal for the PDAP is achieved in stages.
At the project initiation stage, the objective is to better define the conceptual project design and alternatives. Therefore, the goal of the traffic analysis at this stage is to identify the feasible range of solutions to address the identified project need. The analysis should be robust enough to not overlook a feasible solution that is potentially superior to the proposed project. The traffic analysis objectives of the project initiation stage are usually to rapidly evaluate a variety of solutions using tools that do not require a great deal of detail on the specifics of the project design or its alternatives.
At the project clearance stage, the objective is to develop the project design and operation details, secure environmental clearance, and obtain management approval to proceed to PS&E. The objective of the traffic analysis at this stage is to provide data in support of project design and environmental analysis. The traffic analysis does not have to determine the precise signal control or ramp meter settings, just demonstrate it is feasible for the agency to operate the facility with the proposed design, within the expected range of demands, and within its target performance standards.
At the PS&E stage, the objective is to prepare the construction drawings and bid documents. The objective of the traffic analysis is to support the development of those documents, primarily the traffic plans (signals, signing, and striping) and the traffic handling plans during construction. The focus of the traffic analysis is on adapting the project clearance traffic analyses to the needs of traffic handling during construction as well as the design of the facility. Adequate turn pocket and ramp storage lengths must be designed so as not to unduly constrain the agency's flexibility to employ a range of signal and ramp control strategies. The work zone traffic management plan is developed at this stage.
During construction, the objective is to rapidly and cost-effectively construct the project with minimal adverse effects to the public and construction workers during the construction period. The traffic analysis is focused on safely and rapidly responding to conditions as they arise in the field.
Operation of the facility involves periodic updates of the facility control strategy and control settings in response to changes in demands and operating conditions. The traffic analysis is focused on day-to-day operating conditions.
The next step in the development of the overall PDAP is for the manager to assess the resources available for the analysis. This includes identifying personnel with proper training and experience and the analysis tools with which the agency has had extensive experience. The way to minimize risk in the analysis and delivery of a project is to use the tried and true tools and personnel that the agency regularly uses for traffic analyses.
The project delivery schedule should be set based on the manager's experience for each stage of the process. The scheduled time should be sufficient to complete an accurate analysis. Assumptions, costs, laws, decisionmakers, and analysts all change with time. The analysis schedule should be as tight as possible while still providing sufficient time to deliver accurate results for each stage of the analysis.
The schedule should include key checkpoints and decision points throughout the analysis. The checkpoints (often milestones) are for the manager to assess progress and determine if additional resources are required to meet the schedule. Decision points are where the manager must decide if the current analytical approach is not going to be successful and it is time to switch to a backup approach.
The surest way to deliver a project analysis on time and within budget is to use the traffic analysis tools and personnel with which the agency is already experienced. The traffic analysis approaches used in each stage of the project delivery process should use the agency's tried and true tools and experienced personnel as much as possible. Note that the phrase "tried and true" means that the proposed analysis approach should satisfy two criteria. The agency should be experienced with the proposed approach (tried), and the agency should have verified that the proposed approach, when applied in the past, has yielded good (true) results.
While it is tempting to try a new tool or analysis technique, research and project delivery should be kept entirely separate. Project delivery is usually under a strict time schedule, where each month's delay is an increase in the cost of the project and an added threat to the technical value of the analysis for decisionmaking. The world does not stand still. A delayed analysis may be rapidly rendered obsolete by changes in the world.
A manager should not fear sticking with tools and analysis approaches the agency is familiar with. A dumb tool in the hands of a smart engineer can still produce technically useful and valid results. It is rare when a smart tool in the hands of a dumb engineer can do the same. Save staff training and the testing of new tools for a research project where time is not constrained and the agency can afford the mistakes that invariably come with learning a new tool. Project development, with the cost implications of delays, is usually not the best time for an agency to embark on research and training to improve its traffic analysis capabilities.
Note that an old tool that is new to the agency is a new tool as far as project delivery purposes are concerned. In such a situation, the manager should build into the PDAP the borrowing of expertise from other agencies, universities, or consultants to advise staff on the use of a tool that is new to the agency.
Some ways to deal with uncertainty created by new tools and new procedures are as follows:
When employing a new tool or analysis procedure, the manager may also build into the PDAP a parallel analysis, where a known older tool is used in parallel with the new tool. As the analysis proceeds, the manager cross-checks the new and old tool results (to verify that the new tool is applied correctly), and when confidence is built up with the new tool, the old tool is abandoned. The old tool provides backup in case the new tool does not perform as expected or requires more resources than expected. Project delivery is not threatened by unexpected glitches in the new tool.
Although tried and true are the keys to successful project delivery, the manager can still be confronted with projects that are new not only to the agency but often to the profession as a whole. Congestion pricing and speed harmonization are examples of cutting-edge projects for which a manager may be called on to develop a PDAP and for which the agency has no experience. In such a situation, research is the only course of action. The PDAP should be scheduled and budgeted accordingly, recognizing that there will be surprises along the way.
The FHWA Resource Center's staff and Web site are good sources of information and expertise on new and innovative technologies and analysis tools.(4)
More specifics on the technical approach relevant to the selection of MOEs and to the selection of tools, parameters, and assumptions for consistent analyses are given in the following chapters.
The manager has no doubt already taken into account the risks of the various stages of the project traffic analysis when the draft technical approach was developed. However, the purpose of this step is to secure input from the technical analysts and supervisors who are responsible for performing the actual analyses. These people can best communicate the risks of the proposed technical analysis approach and suggest options for overcoming them. If outside agencies are involved in the analysis or the review of the analysis, it would be useful to obtain their input as well.
For each significant risk identified in the risk assessment, the manager should develop a fallback plan with an alternate approach for completing the analysis on time and within budget. The manager should also identify a decision point (date) and criterion for determining when the analysis must switch to the fallback approach.
Key to the success of the PDAP is securing commitments from the analysts and their supervisors to perform the analyses called for in the PDAP. If the analyst or supervisor is not happy with the proposed approach or tools, this is the time to find out.
With the commitments from the analysts in hand, the manager should revise the PDAP and deliver a copy to each team member.
This section illustrates the development of the PDAP, a scalable multistage traffic analysis scope, using a hypothetical case study. The selected case study is a project to add HOV lanes to 13 mi of interstate freeway. One option to be considered is to convert the HOV lanes at a later point to HOT lanes with various ITS infrastructure improvements to support their operation.
The project needs analysis established the following purposes for the project:
Every traffic analysis has the following basic goals:
The specific traffic analysis objectives for the PDAP for this case study are taken from the project needs and purpose statement. The traffic analysis should produce analytical results on the effects of the proposed project and its alternatives on the following:
The selection of specific MOEs to measure achievement of the project objectives is discussed later.
In this particular case study, the manager developing the PDAP found that his or her agency's district staff is familiar and experienced with travel demand forecasting and highway operations analysis using HCM techniques. The district staff is less familiar with microsimulation and has no experience with the evaluation of the traffic operations effects of ITS or HOT lanes.
The manager developing the PDAP noted that the requisite microsimulation expertise nevertheless resides within the agency at headquarters and in two other districts. The PDAP identified these as options to support the local district staff.
The PDAP noted that agency staff is generally unfamiliar with methods for evaluating the effects of ITS and management strategies on traffic operations. The HCM does not address ITS improvements, and microsimulation models require significant staff resources to evaluate such improvements. However, FHWA sponsored the development of ITS Deployment Analysis System (IDAS), a sketch planning program to assess the costs and benefits of ITS improvements, and was identified by the manager as a resource to advise the agency on the evaluation of ITS and HOT lane improvements.
The PDAP set the project delivery schedule and identified the tools, resources, and technical approach to deliver the traffic analyses within the target schedule.
The technical approach of the PDAP identifies the MOEs and tools to be used in the analysis (discussed in later chapters). General guidance (and bounds to the extent feasible) is provided in the PDAP on assumptions and parameters. However, the manager should resist the urge to put the analyst in a straightjacket of specific parameters and assumptions. Conditions evolve, and it is necessary to allow sufficient flexibility to react to changes while still preserving the overall consistency and validity of the analyses.
The MOEs appropriate for the analysis objectives were selected, as shown in table 1.
Reduce of recurrent and non-recurrent congestion
Encourage HOV and transit use
Support regional air quality attainment goals
Improve safety for motorists and agency maintenance workers
In this case, while non-recurrent congestion is indeed a component of total congestion, the PDAP manager concluded that the tools available to his or her staff did not enable a reliable estimate of non-recurrent congestion, so the manager selected MOEs only for recurrent congestion.
As explained in later chapters, after the appropriate investigation into the strengths and weaknesses of the available tools and technical analysis approaches, the manager determined that, in this case, the combination of a macroscopic sketch planning tool (such as IDAS), a travel demand model, an HCM model of the freeway, and an HCM-type model of the street arterials would be the most cost-effective option for delivering the traffic analysis on schedule and budget.
Dynamic traffic assignment (DTA) was considered to improve the accuracy of the travel demand model forecasts; however, this tool was rejected for this project analysis because the travel demand model had not been validated for DTA and because the agency lacked in-house expertise in DTA. A new travel model validation would have been required, triggering a significant increase of resource requirements for the analysis.
The scope, budget, and schedule for the traffic analysis was developed according to the stated conclusions.
Risk assessment and the strategies to manage that risk are project and agency specific. Usually, if the analyses can be completed within a year then the greatest risks are as follows:
The methods to manage risks associated with changes in project design are as follows:
The methods to deal with analysis errors are typical quality assurance/quality control techniques, as follows:
The methods for dealing with tool performance problems are as follows:
For analyses taking longer than a year, additional risks include the following:
The long-term risks are harder to manage. The key is to complete the technical analyses expeditiously so as to not confront these long-term threats to consistency. For longer technical analyses, the following are some techniques that might be useful for reducing the impact of changed conditions:
If the regional growth forecasting schedule is known, try to get advance information on the general magnitude of the changes and their timing. Then, try to incorporate them into the technical analysis through a sensitivity analysis.
Changes in funding usually mean reductions in project scope, delays in implementation, and splitting of the project into stages. These risks can be reduced by using tools that can be quickly modified to reflect changes in project design and scheduling. The forecast year for evaluating the project can be extended 5 to 10 years to allow for uncertainties in project construction year.
Changes in tools can be best managed by resisting the temptation to change (or update) tools in the middle of the analysis. Unless the updated tool fixes a bug known to affect the project analysis results, it is usually best to stick with the original tool and not risk introducing inconsistent results midway through the analysis process.
Advances in road technology are difficult to anticipate. When the HOV project was initiated, congestion pricing was untested in the United States. The manager should keep abreast of the latest developments and incorporate sensitivity testing to address technology improvements that may affect project design. FHWA maintains several Web sites that are useful for keeping abreast of technology changes.
Changes in personnel are generally impossible to predict but are best managed by ensuring that more than one person is involved in each critical stage of the analysis. Appropriate support staff, decisionmakers, and stakeholders should be identified as potential successors and kept informed of study progress, purpose, and key decisions.
Changes in project purpose, like technology changes, are difficult to anticipate. The best approach is to select a general purpose and comprehensive MOEs and tools that can respond quickly to changing project objectives.
Key decision points should be related to the delivery dates for key milestone results. The decision points should occur early enough in each task so the manager has a reasonable chance of delivering the analysis on schedule using an alternative approach but late enough so the manager is not needlessly changing analysis approaches when the original approach still has a chance to deliver the desired results on time.
The key is to identify when a tool (or an analytical approach) is not going to live up to expectations. It is always a difficult choice because one never knows if they are just one fix from having a successful outcome. If one has the resources, one can start a second team on the backup approach while the primary team continues to resolve problems with the preferred tool. The manager then lets the "best" team win, reporting on the approach that delivers the results on time.
The best scope of work is useless unless the people implementing it are committed to it. The manager developing the PDAP should seek commitments from the technical analysts and their supervisors to the objectives, approach, schedule, and budgets for the analysis.
The PDAP should be prepared and delivered to all involved parties.