# Presentation: 273027

## ITS Procurement Workshop

- Module 2: ITS Procurement Characteristics and Challenges

**Notes:**
Delivery:

##  Horror Stories

- “Burying the Software Contractor”
- “A Risky Proposition”

**Notes:**
Delivery:
What happens when we follow traditional procurement approaches when we procure ITS? We will review two real life ITS horror stories of ITS procurement.  
 See horror stories, next two pages...
 Read them aloud to class.

Notes: 
The students have the full text in their guidebooks.

## “Burying the Software Contractor”

- VDOT disaster – project folded
- WSDOT – one year late, $$$$ lost

**Notes:**
Delivery:
This is a typical approach for many State DOTs new to ITS. They want to have their freeway management system “installed complete” like we do most things. Do any of you use those words in your traffic signal system or other project specifications? So, it seemed to make sense to bundle the work together. 
Because so much of the work involved field construction, and so little (by dollar value) was software or systems, the work had to be let as a construction contract. What does this mean? Low bid.
The prime electrical did not want to directly manage the software work because it was outside of their area of expertise. So, the software contractor ended up as a subcontractor to the building remodeling contractor. 
The agency had almost no accessibility to the software contractor. Contractors do not like having the agency “manage” their subs. It was very difficult to work interactively as is needed for software and system development. Plus every request was interpreted as a change by the prime, who immediately asked for additional money. 
Last, the software was done as a low bid. So, in fact, everything was a change to the original bid. Also, the software developer had few qualifications related to the work. 
 The Virginia Department of Transportation notes that this scenario was the cause of two “disastrous” freeway management system projects. In fact the project didn’t ever finish.  
The Washington DOT had a similar experience: their system’s software was one year late, and the vendor lost a great deal of money on the project.

## “A Risky Proposition” 

- Project delayed 6 months.

- ITS Division got a black eye in the view of the Commissioner

- System Integrator bore all costs of testing.

- System Integrator went out of business.

**Notes:**
Delivery:
In this story, both the agency and the contractor wished to remain anonymous. A contractor was hired by an agency as a “system integrator,” after the agency had accepted the communications network and field devices installed by a previous contractor. The system integrator could not get the system to function. The problem manifested in such a way that it was impossible to tell if the problem was the software developed by the system integrator or the communications system without extensive testing. This is a typical problem, by the way. 
The system integrator ended up demonstrating that it was the communications network that was causing the malfunction. The contractor ended up bearing all the testing costs, eroding any profits. Ultimately, the system integrator went out of business. The project was delayed by six months during the problem resolution. This caused a black mark on the ITS division’s record in the eyes of the commissioner.
ITS is not like building roads. ITS components don’t connect the way roads connect with one another. In addition to the physical dimensions, there are the software and systems dimensions. The problems in systems and software are usually fairly subtle, and often difficult to track down. 
By shifting the risk for the communications system onto the contractor, the agency thought things would be easy to manage. But nobody wins. Need a partnering approach! 

## Horror Stories:Lessons Learned

- Don’t “bury” your software developer!
- Select software developer based on qualifications.
- Don’t shift all the risk to a system integrator.

**Notes:**
Delivery
 Don’t bury your software developer!
 The agency couldn’t effectively manage the software development, because it was “buried” so deep with other sub-contractors.
 Select software developer based on qualifications.
 Since the contract was let as “construction,” method of award was low-bid.  There was no way to assess or select the software developer based on qualifications. 
 Don’t shift all the risk to a contractor like a system integrator.
 Shifting risk might appear to make it easy on the agency, but nobody wins. The system integrator took on the risk of testing that system and making it work, but at great expense and lost time.  A partnership--with shared risk--is more appropriate. Ask yourself - whose risk is it really? How should we handle it?
 Another tip: once that communications system was accepted by the agency, the communications contractor “walked away.”  There was no way for the agency or system integrator to contact them for help in tracking down the problem (at no cost).

## Workshop Terminology

- Acquisition
- Procurement
- Work Structure
- Method of Award
- Contract Type

**Notes:**
Delivery:
We hate to torture you with arcane definitions, but the subject matter in this workshop has some very specific definitions that might be new to you.  

We will first discuss the definitions, then provide a review.  I would suggest that you mark the review page in some way, so that if you forget a certain term you can easily flip back for reference.  

## Workshop Terminology

- Acquisition
- Comprises the complete cycle from concept to installation and (sometimes) maintenance and operations.

- Procurement
- A step in acquisition. Includes the work and contract “structures”, contractor selection and payment structure.

**Notes:**
Delivery:
For this Workshop, we have made a distinction between “Acquisition” and “Procurement,” as there is another NHI course on ITS “Acquisition.”
Therefore:
Acquisition is the “whole enchilada” from concept through operations
We have defined procurement for this workshop narrowly - there are many other issues related to contracting. We will touch on these and provide resources for you to access. However, these are the key items that contribute to ITS project success or failure.

Notes:

## Workshop Terminology

- Work Structure
- How is the work allocated to contracts. Are multiple contracts used?
- Method of Award
- How the contractor is selected.
- Qualifications, cost, combined qualifications and cost.

**Notes:**
Delivery:
 Work Structure: refers to how the ITS project is broken down for procurement.  One vendor/contractor for the whole thing? Separate vendor/contractors for different phases?
 Method of Award: How the vendor/contractor is selected.  Is it based on “lowest responsible bid?” Is it based on qualifications? Or a combination of qualifications and cost? Those are the three main approaches, but there are some variations.

## Workshop Terminology

- Contract Type
- How the contractor is paid.
- Fixed Price, Cost Reimbursement, Incentive

**Notes:**
Delivery:
Contract Type: this definition of “contract type” comes from government procurement professionals.  Two common types:
 Firm Fixed Price: self explanatory--the vendor/contractor agrees to provide service or goods at a fixed price over the term of the agreement.
 Cost Reimbursement: where the level of effort may not be well known, these contracts reimburse costs at an agreed-upon rate.  Most familiar is “Cost plus fixed fee,” where vendor/contractor is negotiate a fixed fee at the inception of the contract, and reimburse allowable costs (usually up to a stated ceiling).
One Uncommon type is incentive, which allows additional payment for exceptional or specific performance.
Legal Framework (FARs): the different contract classifications of the Federal Acquisition Regulations. If your project uses Federal Funds, you must consider the FARs.

## Federal Contract Terminology

**Notes:**
Delivery:

These are the types of procurement and contracting methods in the FARs.

## Federal Contract Terminology

**Notes:**
Delivery:

These are the types of procurement and contracting methods in the FARs.

## Federal Contract Terminology

**Notes:**
Delivery:

These are the types of procurement and contracting methods in the FARs.

## Federal Contract Terminology

**Notes:**
Delivery:

These are the types of procurement and contracting methods in the FARs.

## Procuring ITS Projects

- FHWA determined that many ITS projects are not considered Construction (10-6-99 Memo)
- If it is not Construction, then method of contract award does not have to be low-bid

**Notes:**
Delivery:
Your Guide, in the appendix, includes a letter written to the FHWA field offices that says “ITS is not construction”. Most ITS contains software and software is very difficult to develop, integrate and test. FHWA has determined that software need not be considered construction. If a project is not construction, then you can use Engineering and Design services or the Common Rule to procure. 

 Method of award does not have to be low bid!

The key message here is - low bid and software do not mix!!! We hope to demonstrate this in the workshop today, and introduce more effective procurement methods.

More appropriate methods exist for ITS procurement.  We will present those alternative methods in the following modules.

## Terminology Review

- Acquisition
- Procurement
- Work Structure
- Method of Award
- Contract Type

- Legal Framework
- Construction
- Engineering and Design Services
- Common Rule
- SEP 14

**Notes:**
Delivery:
The terms are reviewed below.  The student guidebook has terms listed without the definitions.  Go through the terms and ask the participants to define each team.  Prompt if necessary.
 Acquisition: Acquisition covers the entire ITS project
 Procurement: One step in the acquisition process.
 Work Structure: e.g., phased? Multiple contractors?
Method of Award: How the vendor/contractor is selected.  
 Contract type: e.g., cost plus fixed fee
Legal Framework (FARs): construction, engineering and design services, common rule, SEP 14. 
FAR: Federal Acquisition Regulations
 Construction: all activities related to a construction project
 Engineering and Design Services: planning, design, specification, etc.
 SEP 14: federal project to encourage innovative contracting methods.
 Common Rule: allows state and local agencies to use their own procurement procedures for projects that are not construction.

## Exercise 1: Traditional Vs. ITS Projects

- Maturity of the Technology
- Design Criteria
- How Described
- Design Life
- Client vs. Vendor Knowledge
- Progress Visibility
- Procurement Process

**Notes:**
Delivery:
Refer to Matrix on the next page.  Students do not have the third column filled out...for each characteristic, explain the “traditional” example, and then ask for examples from ITS projects. Explain that ITS projects in this exercise are those with software/systems work or rapidly changing technology.  If students do not have answers, prompt them from the matrix. 

Notes:

Don’t rush, but don’t dwell on any one topic too long.  The entire exercise should take about 15 minutes.

## Lessons Learned

- ITS is different from traditional projects.
- Different nature implies a different approach to:
- project management
- procurement

**Notes:**
Delivery:

So, the Lessons Learned from all this is:
ITS is different. 
What are the differences that imply a new approach to project management? The knowledge issue, design criteria issue, and progress. What would that approach be? A team-based approach with heavy involvement.

What does this imply about procurement? Typically we first design, then construct a road. Do we "design" then "construct" software and computer systems? So do we have procurement processes designed for ITS? No.

## Exercise 2

- If Architects Had to Work like Programmers

**Notes:**
Delivery:
 Have students read aloud the text of the exercise, provided in the next five pages. Have a short discussion after each section, based on the questions provided.
Request or assign volunteers; alternate different paragraphs among different students.
Note that we are assuming that the design and installation process are the same for a house as they are for systems and software. First, most of the design requirements will rely on written description. Are parts of the design requirements unclear? Missing?Second, think about the house design - when is it difficult to make change orders? What are the types of issues that add to cost?

## Architects as Programmers

- Part 1 Discussion
- Can you identify any missing requirements?
- Is there enough information to correct  deficiencies of the existing house?
- What are the main functions for the new house?

**Notes:**
Conflicting requirements examples:
Concept design versus detailed design
Cost is not an issue, but the house must cost less that the existing house.

Missing requirements examples:
Many!  Living room, dining room, kitchen, etc. etc. If these things are missing, what might be the delivered design? Why are they missing? In Seattle, the staff had a hard time listing their requirements because they were based on the existing system that they built themselves, and they thought the requirements were obvious. Of course they are not obvious to someone new to the system, and new to the DOTs practices.

Deficiencies list:
Squeaking floors can either be a problem either because it is a nuisance or because it means there are structural deficiencies. Insulation can be either noise, drafts or cold. What is really needed? A strong floor? A quiet floor? A warm house?A cold house?

## Architects as Programmers

- Part 2 Discussion
- What are the implications to designing for the 1952 Gibson refrigerator?
- How could siding specification (aluminum, vinyl, composite) be improved?
- Who makes decisions on design?

**Notes:**
ITS Analogy:
Use our 386 PCs. Pull data from our Brand X proprietary system. These approaches could cost more than replacing the old equipment.Also, this virtually ensures that the old stuff will live even longer! Also, many new technologies are not backward compatible.

The siding conflict:
Aluminum is not the latest in siding. They probably want aluminum because they are used to it and like the features. Isn’t aluminum the most costly? (Yes) Why does it matter on the new house? How could this be better described?

## Review Questions

- Given that the specifications for this house are problematic, how should the contractor and client work together?
- Should this be a low bid selection?
- How would this affect procurement?

**Notes:**
Delivery:
 How should they work together?
Need to work together closely, making several small decisions that lead to the overall house design. Begin with critical decisions, move on. There may be some backtracking, but no final designs will be tossed out and restarted from scratch. 
Maybe some styles will be shown to the owner. This is sort of like how a GUI is designed. 
Is it wrong or bad to have unclear specifications? Or is it the nature of the beast? It is not wrong or bad. There is a discovery process in requirements development that is iterative.

Low bid?
Can’t really tell how much work is involved here. With no fixed outcome, a fixed price is hard to come by. A low bid would be the minimum to meet the minimum spec. There would be lots of conflicts as changes arise.

How does this affect procurements?
Well, not low bid. And, you would want a selection that looks at the quals, and the process used by the architect to help reveal the design requirements. Might also think about an procurement that allows dividing the work up into small pieces.

## What’s The Point?

- We would never try to design a house like this. But this is how we have been procuring ITS.
- And, you cannot specify ITS as readily as you can a house.

## Lessons Learned

- It is difficult to describe things completely using words - there are often things missing, misinterpretations and conflicts.
- Need a process that allows iterative approach to complex requirements development. More iterative than traditional approach - why?

**Notes:**
Delivery:
ITS iterative process is different from a traditional road job iterative process. Look back at the matrix we developed. We must work more closely and have much more back and forth interaction because of the differences between ITS and Traditional projects. 
In traditional projects, interim decisions between the 30%, 60%, 90% and final are controlled by design standards and manuals, and because the client and contractor are usually equally as informed.  Also, technology can change quickly during design of ITS, while technology is much more stable during road design. When was the last time that river-run gravel changed?
Do you think everything could ever be described by the written word? No, of course not. This is why not only is development/design but in implementation of complex software and systems projects we work interactively, taking small steps, checking, and moving forward.
Most importantly, let’s talk about outcome. Is there a fixed outcome to this project that you can point out like you can point to a product at the department store? No. Without a fixed outcome, how can you fix the price? Think about this and remember this concept as we move forward.

## Virginia DOT-Video

## Virginia DOT-Lessons Learned

- One impetus for change is FAILURE
- Definition of a “construction” project
- Wireless  construction
- Fiber = construction
- Separate the ITS Work
- Look at other department’s or agency’s IT procurement process

**Notes:**
Delivery:
 One impetus for change was FAILURE...do you remember what caused the failure?
 Including software in a low-bid construction contract
 Fog Warning System: definition of a “construction” project...why was this  definition important?
 Wireless, not construction, procure through RFP/qualifications-based process
 Fiber, equals construction, means method of award must be low bid
 Separating the work...why?
 So you can break out the software, procure it through qualifications
 Look at other agency’s IT procurement process

## Break - 15 Minutes