![](media/image1.wmf){width="0.7145833333333333in"
height="0.7201388888888889in"}

**Memorandum**

U.S. Department

of Transportation

**Federal Highway**

**Administration**

Subject: **[ACTION]{.underline}:** Procuring ITS Projects Date: October
6, 1999

From: Anthony R. Kane Reply to\
Executive Director Attn. of: HOIT-1

To: Resource Center Directors

> Division Administrators
>
> State Directors of Motor Carriers
>
> Federal Lands Highway Division Engineers

We continue to hear many comments from both the public and private
sectors on the difficulty in procuring ITS projects under Federal-aid
procedures. These comments, and the recent article, "Death by Low Bid"
(attachment 1), are the direct result of the perception that ITS
projects must always use the same procurement approach required for
construction projects as defined by 23 USC 101 and the related FHWA
regulations. This perception has resulted in numerous procurement
disasters where the "normal" low-bid procurement process has been
inappropriately used for ITS projects. We must be more proactive in
dispelling this perception and your help is crucial to this endeavor.

Often, ITS work is included within a larger construction project.
Experience has shown that this may be inadvisable, and that the ITS work
may be better accomplished as a separate procurement. Work is often
bundled into one procurement to "save time", which is quickly lost later
as implementation problems arise and change orders and claims are
processed to overcome them.

Many stand-alone ITS projects ***do not*** have to be procured under the
rules for construction projects, since they do not meet the FHWA
definition of construction. If field devices or communications
infrastructure is being installed, then this work usually meets the
definition of construction. However, if the project largely involves the
development of software to integrate field devices with a transportation
management center (TMC) or telecommunications system, then it clearly
does **not** meet the definition of construction. Software should never
be procured using the "normal" low bid process, rather it should be
treated as engineering or design services to be provided only by
qualified and experienced firms.

Another option available is the use of a State or local agency's own
procurement process, which is permitted under 47 CFR 18. While some
States have procurement regulations more stringent than FHWA
regulations, many states have adopted special procurement regulations
that are specifically designed for high technology projects, such as
information technology, which could be advantageous in ITS procurements.

Even where an ITS project meets the definition of construction, many
options other than traditional "low bid" exist. Under Special
Experimental Project 14, several alternative procurement techniques,
such as design-build, may be approved, so long as cost is one of the
factors used in the award. Traditional low bid procurement is **never**
absolutely required if it is not appropriate to the project or
circumstances. Attachment 2 summarizes the available alternative
procurement options for ITS projects.

There are numerous resources available to assist your staff in providing
advice to our partners in selecting an appropriate procurement method
for planned ITS work. Attachment 3 is a list of informational resources
available through the ITS Home Page (www.its.dot.gov) and free training
that may be requested. Technical assistance is also available through
the Peer-to-Peer program and from Resource Center technical specialists.

We recognize that many transportation agencies are not accustomed to
using innovative procurement methods, and are therefore not experienced
in their execution. That is why it is essential that you elevate this
issue with our partners. With the rapidly expanding deployment of ITS
technologies, we urge you to make this a priority in your personal
discussions with your management counterparts, as well as at the staff
level, and help ensure that our partners are taking full advantage of
the available flexibility within the Federal-aid process to use
appropriate procurement techniques for these deployment projects.

Thank you for your help on this critical issue. For additional
information or to raise questions about this guidance, please contact
William S. Jones in the ITS Joint Program Office (HOIT­-1) at (202)
366-2128.

Attachment

Procurement Options for Federal-aid ITS Projects

ITS Procurement Information Resources

cc: Core Business Unit Program Managers

Service Business Unit Directors

**PROCUREMENT RESOURCES**

> **Documentation**
>
> • ITS Procurement Resource Guide, ITS Joint Program Office
>
> • FHWA Memorandum: Procurement Information for ITS Projects *Discusses
> types of ITS projects and the alternatives available under federal
> aid*
>
> • Virginia Department of Transportation Public-Private Procurement
> Issues and Accomplishments \-- *A lessons learned discussion of
> public- private partnerships*

-   Innovative Contracting Practices for ITS

> Executive Summary & Final Report \-- *A detailed compendium of state
> and federal procurement laws and options*
>
> • FHWA Federal-Aid ITS Procurement Regulations and Contracting
> Practices
>
> • The Road to Successful ITS Software Acquisition, ITS Joint Program
> Office
>
> Executive Summary; Vol. I; Overview and Themes; Vol. II; Software
> Acquisition Process Reference Guide \-- *A discussion of the key
> issues and approaches to responding to those issues.*
>
> • ITS Software: Effective Acquisition Practices, NCHRP \-- *This
> report will be available from AASHTO by the end of the year.*
>
> • Successful ITS Procurement Case Studies *(Available 1/1/2000)* (All
> DOT documents available via the ITS web site
> [www.its.dot.gov]{.underline})
>
> **Training** (See NHI course listing)
>
> • ITS Software Acquisition; *A two day course for project managers and
> engineers based upon "The Road to Successful Software Acquisition."*

• ITS Procurement Using Federal Aid; *(Available 1/1/2000) This one day
workshop, aimed at project managers and procurement officials, will
concentrate on the use of various contracting approaches allowed by
federal aid for ITS projects.*

Workshop References

*AASHTO Task Force On Software Procurement Action Plan.* AASHTO,
Washington, D.C., 1997.

*Assessment and Control of Software Risks*. Jones, Capers. Yourdon
Press, Englewood Cliffs, New Jersey, 1994.

*Atlanta Navigator Case Study*, US Department of Transportation, Pub.
No. FHWA-RD-98-099, November 1998.

*Buying Smart: State Procurement Reform Saves Millions.* National
Association of State Purchasing Officials and National Association of
State Information Resource Executives, September 1996.

*California Assembly Bill 1727,* effective October 1993.

*Executive Guide: Improving Mission Performance through Strategic
Information Management and Technology, Learning from Leading
Organizations*. GAO/AIMD-94-115. Washington, D.C.: US GAO, May 1994.

*FHWA Federal-Aid ITS Procurement Regulations and Contracting Options*,
US Department of Transportation, FHWA, Pub. No. FHWA-RD-97-145, October
1997.

*Information Technology and Government Procurement: Priorities for
Reform*. Mechling, Jerry. Report from the Program on Strategic Computing
and Telecommunications in the Public Sector, Harvard University, John F.
Kennedy School of Government, 1995.

*Information Technology Procurement for the New Millennium*, American
Bar Association, 1996.

*Innovative Contracting Practices for ITS*, US Department of
Transportation, FHWA, Pub. No. FHWA-JPO-98-015, April 1997.

*ITS Procurement Resource Guide*, US Department of Transportation, FHWA,
Pub. No. FHWA-JPO-97-0025.

*ITS Software Acquisition Effective Practices*, publication pending,
National Highway Cooperative Research Program.

*The Program Manager's Guide to Software Acquisition Best Practices,
Version 2.0*, Software Program Managers Network, April 1997.

*The Road to Successful ITS Software Acquisition, Volume I: Overview and
Themes*, US Department of Transportation, Report \# FHWA-JPO-98-035,
July 1998.

*The Road to Successful ITS Software Acquisition, Volume II: Software
Acquisition Process Reference Guide.* US Department of Transportation,
Report \# FHWA-JPO-036, July 1998.

*Virginia Department of Transportation Public Private Procurement,
Issues and Accomplishments Interim Report.* Booz-Allen & Hamilton.

**Other Resources:**

*The National Association of State Procurement Officials
(<http://www.naspo.org/>)*

The National Association of State Procurement Officials (NASPO) was
formally established on January 29, 1947, in Chicago Illinois. NASPO is
a non-profit organization through which member purchasing officials
provide leadership in professional public purchasing, improve the
quality of purchasing and procurement, exchange information, and
cooperate to attain greater efficiency, economy, and customer
satisfaction. The organization has taken a pro-active stance on
electronic commerce, procurement reform and information technology
procurement. The association is also part of the National Electronic
Commerce Coordinating Council, a coalition of state government officials
dedicated to advancing the use of electronic commerce in the states.

*The Software Engineering Institute (<http://www.sei.cmu.edu/>)*

The Software Engineering Institute (SEI) is a federally funded research
and development center established in 1984 by the U.S. Department of
Defense with a broad charter to address the transition of software
engineering technology. The SEI is an integral component of Carnegie
Mellon University and is sponsored by the Office of the Under Secretary
of Defense for Acquisition, Technology, and Logistics.

**ITS Procurement Workshop**

**Interview Transcript**

**Interview 1:**

**Mike Zezeski**

# Maryland State Highway Administration

Howard Wood: We're here today with Mike Zezeski, from the Maryland State
Highway Administration. Thanks for being with us today. I just want to
talk about procurement issues, and how Maryland went about changing its
procurement process to accommodate ITS projects. Tell me about
Maryland's first attempt at developing CHART, the freeway management
system for Maryland.

Mr. Zezeski: The first step was to sit down and determine how we wanted
to approach the development of our systems, the implementation of our
centers, the systems integration, and all of the hardware and software
to control, the variable message signs, traveler advisory radio systems,
and things that we had in the field. There was nothing to go by in terms
of experience in other areas, so, like many other transportation
agencies at that time, we had to rely on those mechanisms that we were
most familiar with.

We started with an A&E (architecture/engineering) contractor. We picked
a consultant that had substantial experience in the ITS arena. The
problem was, we were working under a contractual mechanism that was
established more for normal engineering and preliminary planning type
work, and in this case we were actually having software and systems
developed, which was outside the realm and scope of that particular
contract. It was a very difficult situation because it was a fixed fee
contract---it had caps in it---and we found that the kind of service
that was needed for systems integration was not very well-suited for
that type of an agreement. So we had a lot of stumbling blocks in trying
to accomplish the kind of things we wanted to accomplish.

Next we had to spend time with the consultants trying to first coming to
an understanding of what our business needs were; and then them telling
us the kind of things we could use to meet those business needs. That
again did not work very well with the type of contractual arrangements
that we had.

**Howard Wood: Okay, what other options were available in Maryland for
contracting?**

Mr. Zezeski: Later on we found out that there were other contractual
mechanisms that were actually better suited for the type of work we
wanted. Particularly when you want to have code written---software
developed, things like that---those types of agreements were in our
general services areas, in our IT areas, and so we decided to start to
explore those other types of agreements, and they were task order-based
contracts---services-type contracts.

Again, we were a bunch of Civil Engineers trying to do ITS systems
development, which was very hardware and software intensive, and we knew
very little about that particular area. So we started looking into these
other (contract) mechanisms, and other types of contracts that were
specially developed for information technology services. We found them
to be better suited to meet our needs.

Howard Wood: You told me that you have to look at how the business
process affects ITS and the system you're developing. Can you speak a
little about the business process and how the specifications evolved
during the building of an ITS system?

Mr. Zezeski: Yes, in a lot of these civil engineering contracts that we
are more knowledgeable of---like (contracts for) building highways and
putting up traffic signals and things like that---a lot of
specifications have been defined over the years, so we have very
detailed specifications that have been developed, which we can go to a
contractor with and say, "Here, build us this system."

But with ITS we found that these kinds of specifications don't exist. We
basically had to develop them by looking at what our business needs are,
and then working with a contractor who would sit down with us and be
part of the process of developing those specifications. So, it is a team
work approach, not knowing exactly what the spec will be to meet a
particular business need at the time when you develop the contracts or
put together the task order. But rather to develop the specifications as
you explore together---what our business needs are, doing modeling,
things like that---to develop the systems.

Howard Wood: We talked about thinking outside the box as far as when you
try to find a procurement mechanism that is not the "traditional,"
low-bid award. Tell me how you thought outside the box, and what did you
find as far as alternatives for Maryland to pursue in a different way to
procure these systems?

Mr. Zezeski: We started to investigate other types of service contracts
that were available with other agencies, particularly in the area of
software development and hardware architecture. We started to look into
procurement laws, seeing what flexibility we had in using those kinds of
services, and we basically found that those types of vehicles were
better suited to meeting our business needs. And once we started
investigating with our Board of Public Works and getting special
approvals, it was actually not as difficult as we first thought it to
be. And again that is the change: thinking outside of the box. You start
exploring what other avenues you have to meet your goals and accomplish
what you want to get done.

Howard Wood: Did these other procurement methods already exist within
the DOT, or within your State?

Mr. Zezeski: It was within our State. We really didn't have these IT
services agreements within the Maryland Department of Transportation. We
started working closely with our Department of Budget and Management,
and our Department of General Services, and that's where we found these
task order-type IT contracts.

Howard Wood: How about the Federal Highway Administration specifically?
What support or encouragement did they offer in this process?

Mr. Zezeski: The Federal Highway Administration was extremely supportive
of what we wanted to do and with working with these new procurement
methods and thinking outside the box. We found that---when we did have
to explore going to these other avenues that we weren't used to or
didn't understand---they were very encouraging in saying, "we will work
with you and we will try to make sure that there's no stumbling blocks
within the procedures that Federal Highway has in letting out
contracts."

I think more of the stumbling blocks were within our own procurement
laws, and that's what we were working with. But by working with the
Board of Public Works and senior management, we were able to easily
convince them that this was the proper way to proceed for the services
we wanted.

Howard Wood: I want to focus a minute on all the people that you worked
with to get this process to change. You mentioned the Board of Public
Works; I assume the Attorney General was involved...perhaps you could
list all the players in this change.

Mr. Zezeski: Oh, it's a large list starting with our own operational and
technical staff. It was like a paradigm shift, and what we had to do was
work together as a team all the way up to the Attorney General's office
and legal staff; procurement staff; and other outside agencies that we
were not normally used to dealing with.

We had to develop a team approach and we had to all understand the big
picture---get a clear understanding of what our objectives and goals
were---and work very closely with one another to accomplish those goals.
The key, in my opinion, was understanding the big picture, and working
together in developing those business goals, and then finding ways in
which we could meet those business goals most effectively.

Howard Wood: Just as a final question, our audience would like to know
your best tips for going about changing the procurement process in their
agencies. If you could, just give as a final analysis, the best
practices or the lessons you've learned for changing the procurement
process.

Mr. Zezeski: Well, as I said earlier, you need to think outside the box.
You have to overcome the fear of change. Look at all your resources
within your State. You will be amazed at the kind of resources you have
within your State, outside the transportation department.

Most importantly, you have to get everybody involved in the process.
They should be right there when you are developing the mission and goals
envisioned for your ITS system, and then let them be a part of the
development of that system, through the entire process. I think that is
the best tip I can give when you want to develop these sophisticated,
complex systems.

Howard Wood: Well, very good. Thanks for being with us today.

Mr. Zezeski: You're welcome.

**Interview #2:**

**J.R. Robinson**

**Director, ITS Programs**

**Virginia Department of Transportation**

Howard Wood: Okay, we are here with J.R. Robinson, the Director of ITS
Programs for the Virginia Department of Transportation. Thanks for being
with us today. J.R., if you could tell me about a project that is
indicative of some of the problems you faced in procuring ITS software.

Mr. Robinson: A couple of the biggest projects were traditional freeway
management projects, changeable message signs and other things. In the
Hampton Roads area, software was a bid item in the original (low-bid,
construction) contract. After the contract was finished, the system just
wasn't adequate---we just didn't get what we needed---so we had to do
something.

We actually let another contract to upgrade that original software.
Since there was another 120 plus miles of new ITS field hardware being
installed, we decided to integrate the software for the new hardware
with the upgrade of the existing system. So, we basically ended up with
an area-wide system integration contract.

We have done that also in Richmond, and we're working on an RFP to do
the same thing in Northern Virginia. So, we are separating software from
construction projects.

# Howard Wood: Can you tell us what other procurement options were available to VDOT?

Mr. Robinson: Virginia Procurement law has, of course, construction,
which is low-bid award, then two basic options: professional services
and non-professional services. Professional services are those that
generally require a license, such as architecture, engineering, even
hairdressing. Non-professional services are actually defined in the law
as anything that is not professional services. So, it's wide open. It's
everything else.

Under professional services, our process is pretty much the traditional
Federal-Aid, engineering and design services process. Under
non-professional services, we have a choice between an RFP (Request for
Proposal) and an Invitation for Bid (IFB). With an Invitation for Bid,
cost is a major factor but not the only factor, and it's used where you
have a really good idea of the product or service that you want to buy,
and you can define it in the procurement vehicle.

Our RFPs of course are the traditional RFPs---I think most everybody is
familiar with those. Cost is one of the factors, but there are a lot of
other factors in the selection process. We actually establish the
selection criteria for each RFP and, therefore, we can vary the cost
factor depending on the kind of work it is.

Howard Wood: As we know, changing a procurement process or any agency's
process can be difficult. How did Virginia DOT go about affecting
change?

Mr. Robinson: I have to admit that when you have a couple of major
failures, it is easier. We included software on a low bid, construction
project---basically a construction project---which resulted in a failure
if you will...an unacceptable outcome.

So, in looking at the options, our chief engineer, our construction
engineer, and the other people involved were readily agreeable to
changing the way we had done the traditional approach. And, we haven't
completed a software project, but things are going really well, and it
looks like the new process is going to be a considerable improvement.

Howard Wood: Was the Federal Highway Administration helpful in looking
for new procurement methods?

Mr. Robinson: When we did the Hampton Roads project, with the software
in a separate agreement, they were helpful. We discussed it with the
FHWA Division Office, and they had agreed to it. About that time though
an FHWA report came out that defined ITS software as engineering design.
But we weren't following the professional services---we were going to
use an RFP.

So the Division Office ran it through the FHWA Region to FHWA in
Washington to get a final determination. They actually came back and
said, "no---it should be a local option based on the specific
situation." And at that point we went ahead with the RFP for the
software contract. So, yes, they were helpful, and they were flexible.
But the written word got in the way, and we had to go through some
hassle. there are some situations now where we're agonizing over the
Federal Highway procurement regulations. They are not exactly getting in
the way, but it's not easy to work around the wording sometimes. "

# Howard Wood: What else is Virginia DOT doing in terms of ITS Procurement?

Mr. Robinson: On the larger projects, one of the things that we're
trying to do is shorten the time between the design and construction.,
It often has taken two to three years for design, another year to
procure the construction, and then you're trying to buy something that
was specified two, three, or even four years before.

Using functional specifications is one of my personal crusades, although
I will admit I haven't had much progress yet for the construction-type
projects. But I think it is essential to use a functional specification
rather than a detailed design to give us more flexibility. This will
present some problems for the contractors in bidding the project, but I
don't think it is a major issue; I think we can work through it.

We also need a common understanding of "construction." Virginia
procurement law has a definition of construction, and so does the
Federal Highway regulations, but they are not the same. We have a
smaller project, for example, a fog and wind warning system in a very
rural area. It is basically weather sensors and large changeable message
signs. As long as we had wireless communications, solar power, and we
were not doing a lot of digging (i.e., trenching for power and
communications), FHWA went along with the interpretation that it was not
a construction project and that we could use an RFP.

When we talked to the FHWA Division office, and to Federal Highway in
Washington, basically, it came down to the sensors. We went with the
large changeable message signs. They were actually in another contract,
so that wasn't an issue.

But when we got right down to the final design decision, there was not
adequate wireless communications capacity, so we had to install
fiberoptics---eight miles of fiber cable---and that required excavation.
Because of this excavation work, FHWA now classifies the project as
"construction."

So we are still debating on whether it is a construction project or a
systems project. We want to pursue it through the RFP because we are
buying a system and that is the end product: a warning system. We think
that would be the preferable way to go.

Howard Wood: It is obvious that Virginia DOT has a lot of experience in
procuring ITS systems. Since there are other agencies out there with
less experience, what advice would you give them on procuring ITS
software and systems?

Mr. Robinson: Look at your own agency; look at what your options are.
Don't just assume that it has to be done a certain way, the way you've
always done it.

Separate the work to the extent you can. Our early freeway management
projects---buildings, changeable message signs, loop detectors, fiber
optics, and software---Separate these types of work if possible. I
realize that creates other problems with management, but it still may be
better than the problems created by including them all in a single
contract.

Look at how your agency procures information technology systems. Look at
the other options available to you, and match what you're trying to
accomplish with the most appropriate procurement method.

The other thing, though, is that even the best procurement method can
yield a failed product, and the worse ITS procurement method---low bid,
and there are examples of this all over the country---can yield an
exceptional product. So the relationship between the contractor and the
State, and the way the projects are managed, have as much or more
influence over the success of the project than does the procurement
method. They're both important, but you can't do one without the other.

# Howard Wood: There are no silver bullets, then?

Mr. Robinson: No silver bullets.

Howard Wood: Thanks very much for being with us today.

Mr. Robinson: My pleasure.