National Academies Press: OpenBook

Guide to Contracting ITS Projects (2006)

Chapter: The Decision Model

« Previous: Before We Get Started
Page 11
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 11
Page 12
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 12
Page 13
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 13
Page 14
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 14
Page 15
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 15
Page 16
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 16
Page 17
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 17
Page 18
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 18
Page 19
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 19
Page 20
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 20
Page 21
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 21
Page 22
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 22
Page 23
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 23
Page 24
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 24
Page 25
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 25
Page 26
Suggested Citation:"The Decision Model." National Academies of Sciences, Engineering, and Medicine. 2006. Guide to Contracting ITS Projects. Washington, DC: The National Academies Press. doi: 10.17226/13925.
×
Page 26

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

11 The following considerations set the stage for applying the Decision Model, which is based on the characteristics of the project and capability level of the agency. More precise terminol- ogy will be defined later. The model has been developed with the following considerations in mind: • The characteristics of the ITS project you are implementing has a major influence on the con- tracting approach. • Your agency’s experience/environment has a major influence on the contracting approach. • The systems engineering process has major influence on contracting approach. • Defining the project, agency experience with ITS, and systems engineering process will allow selection of the appropriate contracting approach. • There are four basic contracting alternatives (procurement packages 1 through 4 identified in Table 1). The other contracting alternatives are adjustments to these packages. • Contract terms and conditions are an important element of the contracting process. They are defined once a package has been selected. The Decision Model used in this guide represents the results of multiple reviews, as well as the testing of the process with five real-world systems. The four dimensions of procurement shown in Figure 4, along with the terms and conditions, provide a structured representation of the contracting process (procurement). The purpose of the procedure described in this section is to select the combination of procurement characteris- tics (one from each of the four dimensions) that are most appropriate for the project’s charac- teristics and the agency’s capabilities. Only a few combinations of procurement characteristics are practical. Contracting packages are unique combinations of procurement characteristics, selected from each of the dimensions of Figure 4. Contract terms and conditions are not included in the procurement packages but are selected as a separate step. These packages are based on the work distribution dimension of Fig- ure 4, which is the fundamental variable that drives the entire process. The characteristics contained in each of the seven procurement packages are shown in Table 1. The objective of the selection process is to identify the most appropriate procurement pack- age for a given project. The package numbers shown in the table are referenced in the initial steps of the decision process. Generally, packages 1 through 4 are used for traditional system imple- mentation, although they can obviously be used for other purposes. Package 5 is either a sup- porting function for the system implementation or may be used for numerous other consultant activities. Packages 6 and 7 are used for the provision of activities (i.e., an internal agency process such as inspection, maintenance, operations, mowing, or signal timing) and functions (i.e., an entire agency service such as traffic management, traveler information or toll collection) in a manner that reduces the agency’s staffing requirements. The Decision Model

12 Guide to Contracting ITS Projects The objective of the selection process is to choose the most appropriate procurement package. This process is presented as a sequence of steps that must be followed to arrive at a conclusion, which in turn leads to the identification of the terms and conditions to be used with the selected package. Procurement Work Distribution Method of Award Contract Form Contract Type Low-Bid Contractor Systems Manager Systems Integrator DB (OM) Commodity (COTS) Consultant Services Services Low Bid Negotiated Sole Source Phased Task Order Purchase Order Fixed Price Cost Reimbursable Incentive Time and Materials Terms and Conditions (payment, cancellation, disputes, etc.) Best Value Figure 4. Four dimensions of procurement.

The Decision Model 13 Package No. Work Distribution (Package Name) Method of Award Contract Form Contract Type Comments 1 Supplier Low-bid selection of prequalified packages Single phase or purchase order Fixed Price procurements 2 Low-Bid Contractor with Design Consultant Low-bid selection for contractor Phased / task order Fixed price for contractor; incentives optional Consultant performs 100% of design. May provide additional services during implementation. 3 Manager Quality-based selection (negotiated procurement) Phased cost reimbursable, or time & materials; incentives optional Field equipment procured by agency using low-bid process. 4 Design-Build Contractor with Design Consultant Best-value selection (based on consideration of price and quality) Phased Usually fixed price, cost reimbursable, or time & materials; incentives optional Consultant provides 30% design. Phased / Task Order Fixed price, cost reimbursable, or time & materials incentives optional Used for system design and many other consultant services. 6 Outsourcing Agency Activity Low-bid selection may be based on rates Usually single phase Fixed price or time & materials; incentives optional Typical activities include maintenance, operations, signal timing, etc. Outsourcing Agency Function Best-value or low-bid selection Single phase cost reimbursable, or time & material; incentives optional Typical functions include traveler information and toll collection. May be public- private partnership. Commodity Systems 5 7 Consultant Negotiated Fixed price, Fixed price, Used for COTS Table 1. Procurement packages.

14 Guide to Contracting ITS Projects Step 1—Make Initial Decisions Now you are ready to get started with the first step of the Decision Model. This first step actu- ally involves a series of substeps designed to help make some initial decisions about the funda- mental project characteristics that differentiate a system development, a consultant contract, and an outsourcing contract. These subjects have been discussed earlier during the project planning activities. The logic for Step 1, diagrammed in Figure 5, leads to four possible outcomes; one of which involves moving on to Step 2 of the Decision Model. Most system developments will take this path. 3 21 Does the agency intend to outsource an existing activity or function? No Other services being procured. Not covered by Decision Model. Use consulting process (procurement package 5)* Start No Yes Yes Are traditional consulting services being procured? Yes * Following the identification of a procurement package, go directly to Step 7 of the Decision Model. No Does the project include a system development? Use outsourcing process (procurement package 6 or 7)* Go To Step 2 Figure 5. Initial project-planning decision process. Three other outcomes to the initial decision process are possible. These outcomes are identi- fied by the bracketed numerals 1 through 3 in Figure 5 and in the following descriptions. [1] This outcome indicates you are planning to outsource an existing agency activity or agency function. Select procurement package 6 or 7 and go directly to Step 7 of the Decision Model process. [2] This outcome indicates a focus on the use of traditional consulting procurement processes as associated with procurement package 5. Select procurement package 5, and go directly to Step 7 of the Decision Model process. [3] This outcome indicates that you are procuring services not addressed by any of the pro- curement packages covered within this guide. For example, procurement packages specific to public-private partnership contracts are not covered. Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send individual projects through the Decision Model. START

Step 2—Determine Work Distribution You’ve determined that you are moving forward with the steps required for identifying an appropriate procurement package for your systems development project. You’ve already done a significant amount of work to get to this point, and the Decision Model process will guide you the rest of the way. The second step in the Decision Model determines whether the procurement should be per- formed as a single contract or multiple contracts. Step 2 occurs early in the process to enable each specific contract resulting from this step to go through the Decision Model process and to be exe- cuted using a contracting process and associated procurement package that best addresses the nature of work to be performed. For example, one contract may include the central system (in- cluding software) implementation, while another contract may consist of only field equipment installations. Many ITS procurements involve multiple contractors who have been selected using different procurement packages. Thus, this step of the Decision Model distributes the total work associated with a project to multiple subprojects and their related contracts. It may very well be that only a single contract is required for the entire project. However, even if all of the project work can be performed by a single contractor (i.e., none of the reasons listed below apply), there may be a need for support- ing contractors who might be performing such tasks as general advisory support, site inspection, systems design, website design, or IV&V of the contractor’s work. The reasons to distribute work to multiple contracts as opposed to performing all work under a single contract may include the following: • Although a significant amount of software and systems development is needed, the largest dol- lar amount is in construction (i.e., the systems contractor will not be prime unless separate contracts are issued for the systems contractor and the construction contractor). • The likelihood of selecting a satisfactory prime contractor for the overall project is uncertain (i.e., not putting all of “one’s eggs in the same basket” would be prudent). • “Politics” require the work to be spread around (which might be particularly true if the proj- ect involves a significant amount of field construction). Unless there are compelling reasons to do otherwise, software development and systems inte- gration work should be performed by the prime contractor, to ensure a single point of respon- sibility and to minimize the complexities of managing the development environment. The Decision Model 15 Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send Remember ... NOT all work has to be done under a single project and associated contract. The goal is to apply the best procurement package based on the nature of work to be performed. individual projects through the Decision Model. START

Step 3—Define Project Category(ies) Now that the work has been distributed to a single project or multiple projects, the third step of the Decision Model involves categorizing each project in terms of its overall complexity and risk. Six factors have been selected to help define complexity and risk: level of new development, scope and breadth of technologies, interfaces to other systems, technology evolution, require- ments fluidity, and institutional issues. Table 2 shows how each factor contributes to the definitions of the four ITS project categories. The worksheet in Appendix A has been developed to help guide project catego- rization. The worksheet identifies the characteristics of each factor and assigns these fac- tors to the following categories of overall complexity and risk: • Category 1: Straightforward in terms of complexity and low overall risk • Category 2: Moderately complex and moderate overall risk • Category 3: Complex with high overall risk • Category 4: Extremely complex with a very high overall risk This step and all subsequent steps must be executed for each of the projects defined during Step 2. It is unlikely that the project will fit all of the descriptors within a single category of Table 2. Thus the challenge of this step is to find the overall set of descriptors that best matches the proj- ect’s characteristics. This process is not an exact science; therefore, some degree of judgment must be used. As a general rule, the higher categories entail a greater development risk because these categories contain more unknowns, expressed using such factors as the level of new development entailed and the requirements fluidity. These two factors should receive the highest priority when evaluating the project category. While the worksheet in Appendix A will identify an ITS project category range, in the event that the project appears to be equally suited to two different cate- gories, the higher category should be selected. Don’t forget the ITS project category once you’ve decided upon it. It will be used along with your defined agency capability level (Step 4) to select an appropriate systems engineering process and initial procurement package(s) (Step 5). 16 Guide to Contracting ITS Projects Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send Use the Project Category Worksheet in Appendix A to help define the category. individual projects through the Decision Model. START Once you have selected the project category, don’t forget your answer.

The Decision Model 17 Factors Category 1 Straightforward Low Risk Category 2 Moderately Complex Moderate Risk Category 3 Complex High Risk Category 4 Extremely Complex Very High Risk Level of New Development Little to no new software development / exclusively based on COTS software and hardware or based on existing, proven software and hardware. Primarily COTS software / hardware or existing software / hardware based with some new software development or new functionality added to existing software - evolutionary development. New software development for new system, replacement system, or major system expansion including use of COTS software. Implementation of new COTS hardware. Revolutionary development - entirely new software development including integration with COTS or existing legacy system software. Implementation of new COTS hardware or even prototype hardware. Scope & Breadth of Technologies Application of proven, well-known, and commercially available technology. Small scope in terms of technology implementation (e.g., only CCTV or DMS system). Typically implemented under a single stand-alone project, which may or may not be part of a larger multiple-phase implementation effort. Primarily application of proven, well-known, and commercially available technology. May include non- traditional use of existing technology(ies). Moderate scope in terms of technology implementation (e.g., multiple technologies implemented, but typically no more than two or three). May be single stand-alone project, or may be part of multiple-phase implementation effort. Application of new software / hardware along with some implementation of cutting-edge software, hardware, or communication technology. Wide scope in terms of technologies to be implemented. Projects are implemented in multiple phases (which may be Category 1 or 2 projects). New software development combined with new hardware configurations/ components, use of cutting-edge hardware and/or communications technology. Very broad scope of technologies to be implemented. Projects are implemented in multiple phases (phases may be Category 1 or 2 projects). Interfaces to Other Systems Single system or small expansion of existing system deployment. No interfaces to external systems or system interfaces are well known (duplication of existing interfaces). System implementation includes one or two major subsystems. May involve significant expansion of existing system. System interfaces are well known and based primarily on duplicating existing interfaces. System implementation includes three or more major subsystems. System interfaces are largely well known but includes one or more interfaces to new and/or existing systems / databases. System implementation includes three or more major subsystems. System requires two or more interfaces to new and/or existing internal/external systems and plans for interfaces to "future" systems. (continued on next page) Table 2. ITS project categories and associated characteristics.

18 Guide to Contracting ITS Projects Factors Category 1 Straightforward Low Risk Category 2 Moderately Complex Moderate Risk Category 3 Complex High Risk Category 4 Extremely Complex Very High Risk Technology Evolution Need to account for technology evolution perceived as minor. Example would be to deploy hardware and software that is entirely compatible with an existing COTS-based system. Ramifications of not paying particular attention to standards considered minor. System implemented expected to have moderate to long useful life. Need to account for technology evolution perceived as an issue to address. Example includes desire for interoperable hardware from multiple vendors. Ramifications of not paying particular attention to standards may be an issue, as an agency may get locked into a proprietary solution. Field devices expected to have moderate to long useful life. Center hardware life expectancy is short to moderate. Control software is expected to have moderate to long life. Need to account for technology evolution perceived as a significant issue. Examples might include implementation of software that can accommodate new hardware with minimal to no modification and interoperable hardware. Ramifications of not using standards based technology are considerable (costs for upgrades, new functions, etc.) Field devices expected to have moderate to long useful life. Center hardware life expectancy is short to moderate. Control software is expected to have an extendable useful life. Need to account for technology evolution perceived as major issue. Examples include software that can easily accommodate new functionality and/or changes in hardware and hardware that can be easily expanded (e.g., add peripherals), maintained, and are interoperable. Ramifications of not using standards-based technology are considerable (costs for upgrades, new functions, etc.). Field devices expected to have moderate to long useful life. Center hardware life expectancy is short to moderate. Control software is expected to have an extendable useful life. Requirements Fluidity System requirements are very well defined, understood, and unlikely to change over time. Formal requirements management a good idea, but not a necessity. System requirements are largely well defined and understood. Addition of new system functionality may require more attention to requirements management. New system functionality includes a mix of well-defined, somewhat-defined, and fuzzy requirements. System implementation requires adherence to formal requirements management processes. System requirements not well defined, understood, and very likely to change over time. Requires strict adherence to formal requirements management processes. Institutional Issues Minimal—Project implementation involves one agency and is typically internal to a particular department within the agency. Minor—May involve coordination between two agencies. Formal agreements not necessarily required, but if so, agreements are already in place. Significant—Involves coordination among multiple agencies and/or multiple departments within an agency or amongst agencies. Formal agreements for implementing project may be required. Major—Involves coordination among multiple agencies, departments, and disciplines. Requires new formal agreements. May require new multi- agency project oversight organization. Table 2. (Continued).

Step 4—Determine Agency Capability Level Selection of a procurement package cannot be based solely on a project’s complexity and risk. Equally critical to procurement package selection is an honest assessment of your agency’s resources and capabilities as well as the environment in which your initiative is planned, designed, deployed, and operated. Does your agency have personnel with relevant prior ITS proj- ect experience? Is there management support for dedicating adequate resources throughout your ITS project’s life cycle? What exactly are the expectations of agency management and can these expectations be met (realistically)? The fourth step in the Decision Model is designed to help you answer these questions. This step uses the information in Table 3 and the worksheet in Appendix B to determine the level that best suits your agency’s capability to manage the system acquisition. In essence, this step is used to assess your agency’s organization, experience, and resources relative to ITS procurements. A careful and thorough assessment is important. While the tendency may be to look at your agency’s capabilities in a favorable light, overlooking deficiencies in, for exam- ple, experience and resources is a recipe for failure. Major ITS projects with significant software development, hardware integration, and, perhaps most critical, long-term oper- ations and maintenance support can be challenging for even the most experienced agency. If you and your agency are not quite ready to take on a project, then either don’t do it or reduce the project scope to a manageable size and complexity. It might also be prudent to bring on additional consultant resources. Don’t take on a system that will result in a long-term operations and maintenance commitment if you haven’t identified the resources to maintain it. If pressure “from above” is an issue, use this guide to make a case for performing the additional planning and preparation necessary to acquire the experience, resources, and management support for taking on the challenges of an ITS project and making it a success. As in the previous step where project categories were defined, some degree of uncertainty is likely to exist regarding the capability level of the agency’s organization. In this case, personnel and organizational experience should receive the greatest weight. In the event that you think your agency is described equally well by two levels, be conservative and select the lower one. Now that you’ve figured out your project category(ies) and have done an assessment of your agency’s ITS-related capabilities, you’re ready to move on to the next step, which will begin to reveal some initial results of the Decision Model. The Decision Model 19 Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send Remember... “honesty is the best policy” when it comes to assessing your agency’s true ITS capability level! individual projects through the Decision Model. START Use the Agency Cap- ability Level Worksheet in Appendix B to help define the Level.

20 Guide to Contracting ITS Projects Characteristic Level 1 Level 2 Level 3 Personnel Experience ITS assigned as part-time job to person with no staff and little to no specific ITS experience. ITS assigned as full-time job with no staff or some part-time staff support. Person assigned has some specific ITS experience with Category 2 or 3 projects. Staff support (if it exists) has little to no ITS experience. Full-time ITS manager and staff with significant prior ITS experience. Staff support includes system administration, operations, and maintenance responsibilities. Organizational Experience Little to no experience with the possible exception of Category 1 ITS project(s). Experience with at least one Category 2 or greater project. Experience with at least one Category 3 or greater project. Organizational Structure ITS responsibility not defined. Responsibility housed within organization with other mission or primary responsibility. Responsibility may also be scattered among organizational entities with no clear lines of responsibility. ITS responsibility somewhat, but not adequately defined. Individual organizational units have ITS responsibility and have their own budgets, management, and priorities; however, there is no definitive linkage among these units. An umbrella ITS organizational unit may exist, but may not have the budgetary authority to effectively manage subunits. Established organizational unit with budgetary authority and clear ITS responsibilities. Organizational unit ties all ITS responsibilities together and includes a procurement process that supports ITS acquisition (e.g., personnel, policies, and procedures). Resources Little to none. No identifiable ITS budget categories or identification of specific ITS funding within existing organizational units. Some budget resources (e.g., ITS earmark funding) assigned to one or more existing organizational unit(s). Support for personnel, equipment, office space, and training expected to come from existing budget of organizational unit(s). Identifiable budget category set aside for ITS. Budget includes support for all required personnel, support equipment, office space, training, and (if necessary) consulting support. Management Support Some mid-level management support for ITS/Operations, but little to no interest at top management levels. ITS/Operations not recognized as an agency priority. Strong mid-level management support for ITS/Operations, with some interest/ involvement at top management levels. Top-level management support. ITS/Operations considered an agency priority within its overall mission. Expectations Not defined or limited to a lower category ITS project under consideration for deployment, expansion, or replacement. Expectations exist for a few “special” ITS-related projects. Expectations may or may not be realistic depending on whether they have been managed properly. ITS/Operations is part of both short- and long-range planning. Expectations are well defined with actual performance measures. ITS/Operations expectations focus on improvement and not on status quo. Table 3. Agency capability levels as a function of characteristics.

Step 5—Select Applicable Systems Engineering Process(es) and Procurement Package(s) At the completion of Step 5, you will have identified at least one systems engineering process and contracting package appropriate for your systems development project. In all likelihood, this step will result in a number of candidate process and package alternatives. Subsequent steps will help you decide between them. Before executing this step, let’s review the alternative systems engineering processes that could be applied to your situation. The alternative processes (also known as models) are the waterfall model, the evolutionary model, and the spiral model, all of which are explained in detail in NCHRP Web-Only Document 85. The waterfall model is representative of typical highway design and construction processes in which steps of planning, design, and implementation are performed sequentially. This model is used for less complex ITS projects and can be applied under all agency capability levels. The evolutionary model defines a repetitive sequence of phased planning, requirements, design, and implementation stages resulting in the deployment of phased versions of a system such that each version is closer to the ultimate system vision. It is applicable to all but the sim- plest ITS projects or projects that require the development of new, unproven technologies. It should be used by all agency levels for most systems development projects. The idea behind this model is to divide complex systems development into relatively simple implementation stages that will ultimately result in the successful deployment of the complete system by the end of the final phase. However, remember that an ITS project will never truly end as the deployed system will always require ongoing operations and maintenance support. The spiral model is appropriate for the development of new applications involving previously untested capabilities that require a lot of planning, prototyping, and evaluation. This model is rarely used by the ITS community, because its application is expensive and time consuming. It is most commonly used by the Department of Defense and NASA for the development of new weapons systems or space platforms. It has been used within the ITS community for such advanced developments as the automated highway system and some of the new in-vehicle safety systems. To use the spiral model, a Level 3 agency with an experienced, full-time ITS manager and staff is recommended. The spiral methodology involves multiple cycles of prototyping and feedback requiring significant agency staff time. A Level 2 agency with significant consultant resource support (assuming this can be obtained) could oversee this development model but at greater risk for failure. A Level 1 agency would not have the experience, structure, or resources to appropriately manage and be involved in this development process. The Decision Model 21 Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send individual projects through the Decision Model. START This step is based on work associated with Task 4 of NCHRP Project 3-77, which supported development of this guide. Please refer to NCHRP Web-Only Document 85 for additional detailed information on the systems engineering process models.

22 Guide to Contracting ITS Projects Agency Capability Level Project Category Level 1 Level 2 Level 3 1 – Straightforward • Waterfall • SM* • Waterfall • Low bid*, commodity, or systems manager • Waterfall • Low bid, commodity, or systems manager 2 – Moderately Complex • Evolutionary • Systems manager or design-build* • Waterfall or evolutionary • Low bid*, systems manager, or design- build • Waterfall or evolutionary • Low bid, systems manager, or design- build 3 – Complex • Evolutionary • Systems manager or design-build • Evolutionary or spiral • Systems manager or design-build 4 – Extremely Complex Not recommended • Evolutionary or spiral • Systems manager or design-build • Evolutionary or spiral • Systems manager or design-build Notes: First line is the systems engineering model; second line is the procurement package. * Consulting services should be used while project is under way. Not recommended Now that you’ve completed our review of systems development processes and their relationship to project categories and agency levels, let’s actually execute Step 5. Use the columns (agency capabil- ity) and rows (project category) of the matrix in Table 4 to locate the cell that identifies the applica- ble procurement package or packages. The commodity entries in this table indicate that a simple system based entirely on a COTS product should be acquired using the commodity procurement package. When COTS products are part of a larger system, other procurement packages may be used (i.e., the product may be part of a proposal for low-bid, systems manager, or design-build procurements). A design-build contractor or a systems manager may decide to acquire a COTS product during the system imple- mentation. If this is the case, the product may be acquired by the contractor or in some cases, the agency will procure the COTS product for the contractor using a commodity procurement. Many of the cells in the matrix provide multiple procurement packages and systems engi- neering models. Step 6 will provide you with information that can be used to decide between multiple solutions. If a cell indicates that the project is not recommended, the agency should either seek more experienced staff support or redefine and simplify the project. Remember, as with the previous step, no amount of optimism can be used to overcome fundamental shortcomings in experience or resources! Table 4. The decision matrix for Step 5.

Step 6—Apply Differentiators Step 6 should be used when more than one type of procurement package is identified by Table 4 in Step 5. Step 6 uses the following criteria to help you reduce the number of alternatives: • Systems manager is preferred to design-build when a significant amount of new soft- ware development is required. • Design-build is preferred over systems manager only for major projects when signif- icant amounts of field construction are involved and there is a desire to reduce imple- mentation delays associated with having to administer multiple procurement contracts. The schedule constraints input into this step (as depicted in the Decision Model diagram) highlights the time constraint of implementing a complex system, which makes design-build a potentially attractive alternative. • The evolutionary systems engineering model is generally preferred over the spiral model because it is less costly and easier to apply. The spiral model should only be used in the event that complex, untested, new developments are required. • If a project includes both new software and field construction, consider splitting it into multiple contracts. • Low-bid contracting should be used only – In the unlikely event that it is required by agency policy, or – If projects are limited to field construction and supply of off-the-shelf equipment. • Commodity procurement is applicable if an existing ITS package is available that does not require any modification to meet agency’s requirements except for – New drivers for interface with communications and field equipment, – A new database reflecting system configuration, and – New map graphics. If, after considering these differentiators, you still find yourself with multiple solutions, work with your agency’s procurement officials to select the preferred alternative (Step 7). Before moving on to Step 7, you may need to re-assess the need for consulting assistance and/or provision of field construction and field equipment supply. In Step 1, this assessment was based on overall considerations of the extent and type of work to be performed. During Step 6, the needs of the contracting package for consulting assistance should be reviewed. Other approaches also might require consulting assistance as defined by procurement package 5. For example, the following contracting packages may require consulting assistance: • A design consultant must prepare the 100% design and a package of plans, specifications, and estimates (PS&E) to be used during the low-bid process. Therefore, two contracts will be required: one for the design consultant and a second for the low-bid implementation contractor. • A systems manager contractor is, in effect, a consultant. For this reason, major items of field construction and the furnishing of field equipment must be performed by contractors selected on a low-bid basis. Therefore, two or more contracts will be required: one for the systems man- ager and additional contracts for construction, electrical contracting, and equipment supply. These additional contracts will all be low bid. All of this work (construction, electrical contracting, and equipment supply) may be combined into a single contract for field device implementation. • A design consultant must prepare a 30% design to be used for the selection and negotiations with a design-build contractor. Therefore, two contracts are required: one for the design con- sultant and a second for the design-build contractor. Note that some agencies with significant ITS expertise and design personnel on staff (Level 3) could prepare 30% design plans in-house. Commodity procurements often require the services of a systems integrator, systems manager, or design-build contractor to implement the COTS product being acquired. The Decision Model 23 Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send individual projects through the Decision Model. START Take another look at the need for consultant assistance before moving on to the next step. Schedule constraints for complex ITS projects may make design-build an appropriate alternative. Low bid is NOT appropriate for projects involving software development.

Step 7—Assess Package and Make Final Selections Step 7 must be performed for all procurements. If you have not already done so, at this point it is imperative to discuss procurement package selection with agency procurement personnel. You may also want to include legal personnel to discuss intellectual property rights, as well as contract terms and conditions of Step 8. In the event that multiple procurement alternatives exist at the conclusion of Step 6, make the final selection of the preferred alternative cooperatively with your procurement staff. This deci- sion must consider your agency policies and should possibly give preference to alternatives with which your agency has had prior experience. However, prior experience should not be limited to your agency’s experience with highway construction. You may very well be able to take advantage of the expertise of information technology (IT) personnel that already exists either within or outside your procurement department. This expertise can take the form of technical expertise (e.g., hardware, software, and communications) or even IT procurement expertise. While coordination with IT staff is encouraged, relinquishing authority for technology procurements (e.g., moving responsibil- ity for procuring ITS-related hardware, software, and communications from the DOT to another state department responsible for IT) is not recommended. 24 Guide to Contracting ITS Projects Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send individual projects through the Decision Model. START Take advantage of the expertise from your agency’s IT department.

Step 8—Define Contract Scope and Terms and Conditions The final step in the Decision Model involves the selection of the terms and conditions to be included in the contract.As with Step 6, you’ll want to do this step in close collaboration with your agency’s procurement personnel. Although some terms and conditions are required for all types of contracts, others are only suitable for certain types of contracts (i.e., commodity supplier, low bid with design consultant, systems manager, and design-build contractor). The following list of mandatory contract terms and conditions should be considered regardless of procurement pack- age used: • Parties to the contract • Scope of the contract • Compensation and method of payment • Extras • Assignment of claims • Agency-furnished property • Order of precedence • Commercial warranty • Patent rights • Multi-year contracts contingent upon appropriations • Termination for default • Termination for convenience • Execution and commencement of work • Delays and extensions of time • Modifications • Multiple contract awards • Liquidated damages • Variations in estimated quantities • Suspension of work • Incorporation by reference • Specifications • Delivery and acceptance • Intellectual property • Contractor’s invoices • Conflicting terms Table 5 identifies terms and conditions that are most appropriate to specific procurement packages. The section following Table 5 provides definitions for all of the terms and conditions in both the above list and Table 5. Your agency is likely to have standard sets of terms and conditions that are to be incorporated in the request for proposals and resulting contract. In the unlikely event that standard terms and conditions are not available within your agency, or if you are looking for guidance on a specific term and condition not typically used by your agency, the Federal Acquisition Regulations (FAR) is a good source of information. The FAR, which governs the majority of federal procurements, includes language for myriad terms and conditions including those appropriate to ITS projects. The Decision Model 25 Use consulting process (procure- ment package 5) Other services being procured. Not covered by this Model. STEP 6 APPLY DIFFERENTIATORS Schedule Constraints No Yes STEP 2 WORK DISTRIBUTION STEP 1 INITIAL DECISIONS STEP 3 DEFINE PROJECT CATEGORY(IES) STEP 4 DETERMINE AGENCY CAPABILITY LEVEL STEP 5 SELECT APPLICABLE SYSTEMS ENGINEERING PROCESS(ES) & CANDIDATE PROCUREMENT PACKAGE(S) STEP 7 PACKAGE ASSESSMENT AND FINAL SELECTIONS STEP 8 DEFINE CONTRACT SCOPE AND TERMS & CONDITIONS END Use outsourc- ing process (procure- ment package 6 or 7) Send individual projects through the Decision Model. START ITS is not explic- itly referenced in the FAR. Relevant information can be found in sections referencing IT.

26 Guide to Contracting ITS Projects Procurement Package Terms and Conditions Commodity Supplier Inspection of Supplies Option for Increased Quantity Ordering Definite Quantity Indefinite Quantity Brand Name of Equal Performance/Payment Bond Low-Bid Contractor with Design Consultant Design within Funding Limitation Redesign Responsibility for Design Errors or Deficiencies Deficiencies Fixed Price Incentive Fee Performance/Payment Bond Systems Manager Commercial Computer Software Restricted Rights Fixed Fee Incentive Fee Rights in Data Allowable Costs and Payment Performance-Based Payments Delivery Orders (Task Orders) Specifications Delays and Extensions of Time Modifications Delivery and Acceptance Conflicting Terms Patent Infringement Indemnification Federal Grant Flow-Down Provisions Performance/Payment Bond Design-Build Contractor with Negotiation Design within Funding Limitations Redesign Responsibility for Design Errors Work Oversight Suspension of Work Fixed Fee Incentive Fee Execution and Commencement of Work Performance/Payment Bond Specifications and Drawings Consultant Notice of Cost Comparison Allowable Costs and Payment Fixed Fee Incentive Fee Performance-Based Payments Deliver Orders (Task Orders) Specifications Delays and Extensions of Time Modifications Delivery and Acceptance Disputes Retention of Records Indemnification Outsourcing Agency Activity Negotiation Fixed Fee Incentive Fee Work Oversight Execution and Commencement of Work Performance/Payment Bond Allowable Costs and Payment Performance-Based Payments Modifications Rights in Data Outsourcing Agency Function Negotiation Fixed Fee Incentive Fee Work Oversight Execution and Commencement of Work Performance/Payment Bond Allowable Costs and Payment Modifications Rights in Data Contractor Inspection Requirements Negotiation Design Consultant Negotiation Table 5. Procurement packages and their associated terms and conditions.

Next: Contract Terms and Conditions Definitions »
Guide to Contracting ITS Projects Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s National Cooperative Highway Research Program (NCHRP) Report 560: Guide to Contracting ITS Projects provides guidance on the procurement of intelligent transportation systems (ITS), including variable message signs, traffic detectors, signal controllers, and a variety of other hardware and software that entails applications of advanced electronics and information management to regulate and facilitate traffic flow. The report highlights best practices and recommends contracting strategies and contract types, terms, and conditions for ITS development, integration, system acceptance, warranty, maintenance, and upgrade.

The research team that produced NCHRP Report 560 has also prepared NCHRP Web-Only Document 85: Considerations for a Guide to Contracting ITS Projects that describes their work and many interim results that may be of value to other researchers and professionals facing ITS procurement issues. In addition, the researchers developed an on-line tool that applies the NCHRP Report 560's decision-making process.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!