**Transcript of ICIS Millennia Partners Conference**

August 1, 2008

1:00pm

EPA East Building, Room 1153

[Lin Pinskey: Welcome]{.underline}

Okay. So if you'd have a seat, I think we will get started. We may have
some other people who show up later.

I want to thank you for coming today. We're very excited about this
program and about this conference.

We really have a great opportunity here for an open exchange of
information, to give you as much information as we can so that we really
have a full and open, really good, competition among the Millennia
partners. And we'll have a Q&A session. First, though, we'll have some
presentations from various speakers, who are sitting up here behind me.
And then we'll open it up for questions and answers.

You see the people up here on the podium, from the program office,
because they want to make sure that you understand that the intention
here is to have a completely open, fair opportunity under the Millennia
task order. Obviously, my name is Lin Pinskey, and I'm a contracting
officer, and I'm the one who, probably, you sent your emails to, to come
and register, and you'll be hearing from me more.

As happens in the summer, both our service center manager, Jennifer
Cranford (who may be doing some things on this, and who may show up in
some emails) is on vacation -- she comes back on Monday -- and the
person acting for her also had to take off this afternoon, Dave Fuller.
You see his name for the Introduction on the agenda, so ... just call me
Dave.

The only thing I'm really here for, pretty much, is to lay out the
ground rules; that I'm sure all of you already know\... just to make
sure we have a completely open, fair process. You know there are certain
things... we're going to be as open as we can, and provide as much
information as we can to you, but because of the rules and the way
Congress writes them we have to give the same information to everyone,
and there may be things that we cannot touch on. You may ask a question
that we say, well...that's really something we can't get into. And I'm
sure you understand that.

Once the individuals finish their presentations, I will talk again a
little bit about our plans for how we will structure the task order. We
are recording this, and we will be putting the transcript up on the Web.
We will put the list of the attendees up on the Web. We'll put the slide
presentation up on the Web. You have copies of everything that people
will be talking about, so you don't have to copiously copy down
everything that's on the screen. Because of the sunshine, that's a
little hard to see anyway, so it's a good thing we have the handout.

That's pretty much what I have to say here. I want to welcome you for
coming here today, and I'm going to turn it over to Lisa Lund, who is
the Director of the Office of Compliance, and she is going to give you
the executive overview of the ICIS program.

[Lisa Lund: Executive Overview]{.underline}

Thanks, Lin. First of all, I do want to welcome you all personally to
this ICIS Millennia Partners Conference. Thank you very much for coming
today. We are very interested in getting a full and robust competition.
So we're really glad that you're interested in being here. Our hope is
that, by the end of today, you'll have a better understanding of OECA's
mission and how ICIS supports that mission and what is entailed in this
requirement so that you will be better able to respond to the
solicitation.

So what I want to do today is to tell you a little bit about OECA, and
our mission, and how ICIS supports that mission. About how it supports
both our strategic plan goal, goal 5, compliance and environmental
stewardship, as well as the Office of Water's goal, clean and safe
water. And ICIS nationally supports those two programs, so it's really a
critical system for us.

And to also give you some indication about the array and breadth of the
stakeholders that the system has. It makes it, sometimes, a bit more
difficult to get things done, but it's also something that makes it a
much stronger and more robust system, so it's an important factor in the
system itself.

So, let me start with the Office of Enforcement and Compliance
Assurance, OECA. Obviously, our mission is to ensure compliance with
environmental statutes and laws and regulations. We work with state,
tribes, and other co-regulators, local agencies, to make that happen. We
also work closely in conjunction with the other program offices in the
Agency and our Regional offices as well. OECA as an organization
encompasses both headquarters and regional staff, so it's an
organization that has both regional components and headquarters
components.

We enforce and ensure compliance using a number of tools. We use
compliance assistance to give fair notice in terms of our laws and
regulations and to educate the regulated community as to what is
required in terms of compliance. We use compliance incentives to
encourage self-auditing and self-disclosure. We use compliance
monitoring to collect, analyze and utilize the information to determine
compliance which then leads, sometimes, to both civil and criminal
enforcement. All those tools are really important, and all those tools
are supported by our main data system, ICIS.

We have several databases within the Office of Compliance that support
the enforcement and compliance program. ICIS is the primary one. It is a
multimedia data system. And it has two components. One a federal
component, which really collects compliance and enforcement activities
and outputs and outcomes from the whole compliance and enforcement
program at both headquarters and regions, and it also, collects
information from states. It also supports the water program, in the
National Pollution Discharge Elimination System program and it not only
serves the compliance and enforcement program but it also supports all
the permitting information from that program. As such it encloses the
Discharge Monitoring Reports, which are a huge reporting burden on the
regulated community. They report that directly into either PCS or
ICIS-NPDES, in this case.

So, it is a very important system to us. We use that system to not only
collect that information, but we use it to plan, to target, to look at
our results, to evaluate our program, to really bring about a
performance-based management system within the compliance and
enforcement program. So that information is utilized on a daily basis.
It is something that gets intense scrutiny at the regional and state and
federal levels, and therefore, not surprisingly, it's a system that has
a lot of interest from a lot of groups. We work very, very closely with
our state partners. We are now in the process, in the NPDES program,
working with the states to figure out what the required data elements
are going to be for ICIS-NPDES. That is an ongoing process; we're doing
a rule, currently, to address that. So there's a lot of interest in what
information is going to be going into that system. We work closely with
tribal governments, with local governments, and also, especially, with
our regional offices, on the system, and they are very, very involved in
its day to day management.

We also get a lot of scrutiny from Congress, from our overseers, the IG,
the GAO. The public also looks at that data through our ECHO public
website, so it is a system that has a lot of interest across the board.
Because of that, it sometimes makes it a very complex and interesting
system to manage. Right now, currently, 21 states use ICIS-NPDES as
their current database for running their program, as well as the federal
government using it to input their own data. And that number will be
increasing over the next couple of years. We are building components of
that system as we go.

So today, I hope what you'll hear from the various speakers, and, one
thing we'll do when I finish speaking is I think it would be helpful to
go around the room and introduce everybody -- we can introduce ourselves
-- is to understand the components of the system, to understand how the
system is used to manage the program, and understand where we are going
technically with the system. So, hopefully, you'll leave with that good
understanding today.

**[Introductions]{.underline}**

Lisa Lund, Director of the Office of Compliance...

Lucy Reed, Branch Chief for DSIMB, where ICIS is managed and operated

Glendora Spinelli, project manager for Phase II of ICIS, and team lead
for O&M and

Development for ICIS

Betsy Smidinger, acting Director of ETDD, where ICIS is housed

Mike Mundell, in Lucy Reed's branch, Chief of the ICIS section, and
project manager for

ICIS

Steve Hufford, with same branch

Paul Buellesbach ERG

John Carroll ERG

Kate Thomas CGI Federal

Kenyon Wells CGI Federal

Andrea Myslicki SRA

Liz Phillips, with the ICIS team

Kathy Dockery, DSIMB

Annie Norgren-Salfi... BAH

Will Schmidt BAH

Paolo Dell\'anno BAH

Dave Carnes TRC environmental

Maya Melhern BAH

Dennis Pelehach BAH

Denny Daniel Raytheon

Frank Ceasar Raytheon

Geoffrey McDermott DRT Strategies

Bruce Harvey UNISYS

Shaf Mohebbi UNISYS

Susan Bethke Northrop Grumman

Jim King CSC

William Savage CSC

Gary Lennon Akamai

Thanks everybody, that was helpful.

I'm going to pass it over to Betsy Smidinger, who is going to give you
an ICIS programmatic overview.

[Betsy Smidinger: ICIS Programmatic Overview]{.underline}

I'm glad everyone could attend today. Some of the things I'm going to
touch on are an ICIS background perspective, how we got to where we are
today with the system, some of the history, why we need the system (a
little bit more detail than Lisa went into), and then also I want to
finish up with some of our current and future challenges.

Can everyone hear me okay? Okay.

EPA's vision for ICIS is to build a single system that will support our
federal enforcement and compliance activities and program management
needs, as well as the unique needs of the NPDES program for the Clean
Water Act, both from the permitting and the enforcement and compliance
perspective. And also for the Clean Air Act, stationary sources, for a
system that we now call the Air Facility System. We want a system that
will provide the capability to allow for data sharing with the states
and other partners, other government agencies, using the Central Data
Exchange within EPA, and also our National Environmental Information
Exchange Network.

We also want to use modern Web technologies. As I continue to talk,
you'll come to understand that many of our systems have been in
existence for a long time and they're very out of date technology-wise.
So we really want to move our technology up to more modern formats and
platforms. And we also want to be in step with the Agency's enterprise
architecture, and allow for greater use of integration of the
information.

These are things that are driving ICIS. There's really two main business
needs. As I mentioned, there's the technology side, and there's also the
program side. From the technology perspective, as I mentioned, we have
old systems that have been in existence, some of them, for over 20
years. They haven't been able to keep up with the evolution of the
programs they support, particularly NPDES, and we'll talk about that as
I go through here, how the program has moved along and we haven't been
able to keep the system in synch. Also these old legacy systems have
been under scrutiny by the Inspector General, the GAO, and our Permits
and Compliance System, that originally supported the NPDES program, has
been identified as an Agency FMFIA weakness. So we are watched carefully
on how we proceed and how we manage our funds for modernizing PCS.

From the program perspective, the data that supports these programs is
very important to us, and the ability to have all the data that covers
the entire program. We really need a system that allows us to document
and evaluate our program performance. We have several projects where we
really do pool the information from the system and use it to look at
what's going on in our programs. It helps us provide national statistics
-- these can support press releases, and end of year announcements. It
helps us determine priorities and helps us determine our targets for
setting those priorities. And this oftentimes drives where we will
invest our resources. It helps us to evaluate the appropriateness of
requests for program withdrawals and these come in as petitions to
withdraw state programs, and we use the data to help evaluate the status
of the state's program. It allows us to provide information in
responding to lawsuits, particularly for the Clean Water Act. We also
use the data in the systems to help us develop our guidance and our
policies. Again, it goes toward that concept of being able to analyze
the information on our program and understand where we need to be
focusing.

The information also helps support, particularly, the Clean Water Act in
developing our regulations.

As a way for us to be able to do these things, we needed a system, and
we're using ICIS as that system, to modernize some of the existing
systems that we had. And we'll talk about how we've been doing this.

The first system was the Civil Enforcement Docket System. I'm happy to
say this is long gone now! We had that as the original system for
tracking our federal enforcement information. We're in the process of
modernizing the Permit Compliance System which supports the Clean Water
Act, NPDES. And then part of the plan is also to modernize AFS as part
of ICIS.

So, a history of how we got to where we are today...we've really taken a
phased approach in doing this, and it really made sense to break this up
in to pieces. It's a big project. This allowed us, by putting it into
pieces, to be able to better manage it and to focus on one area at a
time. It also allows us to better manage our funding, and the resources
from the EPA side as well, to be able to do this in smaller pieces.

So the phases of the system are: ICIS Phase I \-- that is the phase that
supports the federal enforcement and compliance information; Phase II is
the modernization of the Permit Compliance System, and this is what
we're calling ICIS-NPDES; and then Phase III will be the modernization
of AFS that supports the Clean Air Act, stationary source area.

Here's a diagram that we're going to rely a lot on today. If you look at
the bottom of the diagram, the phases that I just mentioned are along
the bottom, every time you see this chart. Along the top is just some
language explaining the phases, the federal enforcement and compliance
-- we often call this FE&C. NPDES is in the middle, and then AFS is in
the right-hand column. Looking at what we've completed in the darker
green, the FE&C area, we completed in 2002, and we've been using that
ever since. It replaced three national systems that were outdated and
several regional tracking systems that were being used. Really our
concept is that we want this to be the system where our federal
enforcement and compliance information is managed across all the regions
and at headquarters. It supports much of our public reporting when we do
our end of year press releases, when we talk about different kinds of
enforcement actions we're taking. It allows us to talk about our
compliance assistance activities. One of the big things we also use this
information for is reporting GPRA measures, Government Performance and
Results Act measures, and one of the examples given here is pounds of
pollutants reduced from our enforcement actions.

Going into the second phase, we've also completed the direct user phase.
If you go to slide 11, there's more information there. This phase we
implemented on June 23, 2006 and we called this ICIS 2.0. Really what
this did, it gave a new 'look and feel' to the federal enforcement and
compliance users when we added in the NPDES piece. It brought in more
functionality to allow the tracking of areas that PCS didn't allow for
the NPDES program, and these are areas like the combined sewer
overflows, the sanitary sewer overflows, concentrated animal feeding
operations, storm water areas. In PCS we could track some of that
information, but not to the full degree that we needed to and wanted to.

We have 21 direct user states for the system, 2 tribes, and 9
territories, and they're fully using ICIS-NPDES, they're no longer using
PCS. When I talk about direct users, and we'll get into more detail on
them later, this is their main system for managing their CWA NPDES
program. And when we say states, it could be a region that is
implementing the program for the state - where the state is not
authorized to run the program. They are using the system to manage
directly, they don't have any other system. Some of the states, and
we'll get into this, have their own system, but these are states that
are purely using ICIS-NPDES. And again, we still have our ICIS FE&C
users in there.

In 2007, we used that as a year to catch up on things. We had 4
quarterly releases where we fixed bugs and made corrections, and made
some additional enhancements to the system. As we progress across the
chart, we now have three more columns lit up -- two are a little darker
green -- what we did was for our batch states -- these are states that
have some portion of the information in a system they maintain, that
they need to send to us electronically, and we broke this up into pieces
to make it more manageable.

How we talk about these three parts, is we talk about Hybrid states,
NetDMR, and Full Batch states. And when we talk about hybrid states,
these are states that primarily use ICIS-NPDES as the system to manage
their program, but they have some kind of state-owned system that
they're managing their DMRs with, their discharge monitoring report
information. That information they need to batch into ICIS-NPDES. So
part one brought in the ability for states to mostly manually enter the
information into ICIS-NPDES and batch their DMRs. And the batches come
through CDX into the system.

Part II, the NetDMR flow: NetDMR is a tool that we're developing. Texas
and 11 other states have a grant under which they're developing a tool
that will allow facilities to directly report their DMR information
electronically into the Agency. This is a big step. Right now, most of
the states are manually entering all the DMRs. It is a lot of
information that comes in. We expect to have 20-30 states use this type
of tool. It's not a requirement for the facilities to electronically
report so it will be totally on a voluntary basis. We'll be doing a lot
of marketing to get facilities and the states to be interested in using
this tool, and it would be a big burden reduction, we believe, both on
the state side and the facility side.

The last part is the full batch states. There are about 20-22 of these
states. These are states that have their own state system, and they
batch all of the information they need to, to EPA. So we'll talk about
these a little bit more. One thing I didn't mention -- for those flows
that are being batched to us, we are relying on XML schemas that we are
developing, and working with the states on developing.

Just a few more details on each of these different parts -- Part 1 we
just recently implemented. We brought our first hybrid state in, in May
of 2008. We are bringing in an additional 4-6 states by the end of this
month, August. In 2009 we will also be bringing in 2-4 additional states
that are the hybrid states. For the NetDMR tool, we are expecting to get
a demonstratable product from the grant, in the August-September
timeframe, and then we'll begin testing that tool, and we want to start
using that tool in 2009, probably end of the first quarter or beginning
of the second quarter. We'll begin work on the full batch in 2009. As I
mentioned, we have about 22 states and one of the things that's going on
now for the full batch is we do have an alternative analysis as part of
our CPIC. We have to do an alternative analysis this year. So right now,
we don't know exactly what our approach is going to be for the full
batch states. We will have our alternative analysis done in September.

A few things from the programmatic side -- challenges that we are facing
now, and into the future: we need to keep the system in synch with new
and evolving program management needs. The programs change year to year
-- there's different things they want to measure, different things they
want to be able to track, so we never hit a static system. As I
mentioned, part of the problem with PCS was that we really weren't able
to keep up with the program as it evolved. One of our challenges is
building a system that we can keep up to date with what the program
needs as well as keeping the system in synch with new and evolving
technology. Some of our systems are very old -- they are on old software
and hardware platforms - and this creates problems for the regions, and
makes it hard for them to be able to access the information, and for the
states to be able to send information into the systems.

Managing expectations of a large and diverse universe of users: one of
our challenges with this system is that we have, right now, two very
different groups of people/stakeholders in the system. We have the
federal enforcement and compliance users, and we have the CWA/NPDES
users which are both federal and state. One of the things that we're
beginning to get going is a governance process, and we're really trying
to figure out how do we make decisions, using the funding we have, to
make sure everybody's needs are met, and when there's enhancements to be
done, making sure we're prioritizing them, taking into account
everyone's needs.

That leads into obtaining input from stakeholders and addressing their
needs. We do work closely with all the users, both from the federal and
state perspective. When we do go to make enhancements, we pull in all
the different stakeholders to make sure we're changing the system in a
way that will meet their needs.

The last thing here is managing the NPDES program using two systems. One
of our challenges has been that we have half of our states using PCS and
half of our states in ICIS-NPDES. One of the good things, or bad things
depending on how you look at it, is ICIS-NPDES now gives us much more
capability to report on areas that we don't have in PCS, so we often
find ourselves, especially from the federal perspective, wanting to go
to ICIS-NPDES and use that as our area to be pulling information but
many of our Regions are still primarily in PCS. So we've had some issues
with how do we manage this in a way that we can get what we want using
the new technology, while still maintaining some balance and not
creating undue burdens on folks.

I'll turn it over now to Glen, and Mike Mundell.

[Steve Hufford]{.underline} -- I'd like to make one logistical note
first. A bunch of you were handed little 3x5 cards. We're trying to keep
this firehose of information coming your way, without interrupting it as
we go, so please jot questions down on those cards. At the start of the
Q&A session we'll collect those. It offers you another way, if you want
to submit questions in a way that won't have attribution, during the
Q&A, you can use those cards. If you want to have attributed questions,
just speak up during the Q&A. So we're offering that as another option,
to toss questions into the hopper. When you do fill out the card, please
put your name on it, so we can get back to you if needed, but we won't
announce it during the Q&A. I wanted to mention that as we're about to
launch into a lot more information, to supplement the information Betsy
already gave us. Thanks. Anybody need more cards? Kathy has them if you
do.

[Lin Pinskey]{.underline} -- also I just wanted to mention the slides
that you have seen will be put on the Web. They are a little bit
different from today's handout, but you'll have the final version that
you see on screen on the Website.

[Glendora Spinelli: ICIS Overview]{.underline}

Let me know if you can't hear me. I'm known for talking softly, so I'll
do my best here. We're going to go through the system evolution. This is
going to be from the system level, not the programmatic side, which
Betsy just covered. Hopefully, it will give you enough background
information about what we've done, where we're currently at, and a
little bit about what we see the future being... Then we'll talk about
our major activities, and this really relates to the PWS, and the
content of that, and the work that we expect to get done over the next 5
years. Then we'll talk about current and future IT challenges -- again
this is going to be from the system side.

I'm going to start back with Betsy's picture. I'm going to keep
referring to this, from the perspective of the evolution of the system
as opposed to the program. And we'll start with the beginning, which was
Phase I, what we call now federal enforcement and compliance. To start
off with the functionality, I'll try not to repeat too much of what
Betsy said...this is really there to support our federal users --
enforcement and compliance, targeting, tracking of information, and
reporting needs, and I want to emphasize that this is across media. It's
not specific to one medium. By medium, I mean air, water, hazardous
waste. It provides real-time data entry from a desktop. That's been a
goal and a requirement from the very beginning, that people can sit at
their desk and enter data and immediately be able to view it or retrieve
it. It replaced one of our major legacy systems, but also several
regional systems. Again, one of the goals that we've had is to
consolidate systems that were really doing very similar things, maybe
for a different media, or for a different purpose, and to bring that all
together into one system.

This fourth bullet, incorporating functionality to support relating
various enforcement and compliance activities, what we mean here is that
we implemented the capability to be able to link these activities
together. For instance, if we have a regulated facility, and we do an
inspection against that facility, and end up taking an enforcement
action as a result of that inspection, we want to be able to see that
from beginning to end. As we add permitting, it's the same thing -- we
want to be able to link that permit to that facility. We want to be able
to look at a facility and see everything that's going on at that
facility and what the results of activities have been.

It was used to manage our enforcement program at both the regional and
headquarters level and it is the primary tool that's used to report the
results of its activities to Congress and the public. I think Betsy
touched a lot on that. On specific functionality, and I'm not going to
go through all of this, these are specific to the data and functionality
that were in Phase I, the federal enforcement and compliance component.
As a system, it has other functionality associated with it; a lot of
system administration functions, and things like that. It does have a
reporting capability. We implemented what we call standard reports, or
national reports, that were built for anyone to use. There are some
management reports, but our users also have the capability to do ad hoc
reporting, and this is against the operational database.

The Phase I architecture was only accessible via EPA's intranet. It was
not available outside of that. It used a three-tier architecture. We had
an application server, web server, database server, portal server, but
they were all on a single physical server at the NCC, EPA's National
Computing Center. Back in the days when we had one physical server that
supported this, it was developed primarily using Oracle and Java
technology. We did integrate an off the shelf reporting package, called
Business Objects. At that time, it was version 5.2. Business Objects is
the reporting tool that is used by ICIS users to retrieve data. It is
the only way that they can retrieve data, and the retrievals are done
against the operational database. We implemented an exchange of
information with the Agency's facility registry system, which is the
Agency's system for all regulated facilities. It has information on all
our regulated facilities, so we exchange information with them on a
regular basis.

I threw in a few metrics here. At that time, ICIS supported about 1200
users at EPA headquarters and all ten regions. We pulled in all
facilities from FRS, so we had about 1.5M facilities. (These are
approximate numbers) The rest of the data really was in the hundreds of
thousands of records. The point here is that at this time, we were still
pretty small, though that was going to change\...

Back to our picture. As Betsy said, with Phase II, or ICIS-NPDES for PCS
modernization, we broke that up into four parts. We actually tried to
break it up even further, but found it wasn't possible. The Direct User
part to Phase II was very large, so it was a fairly big undertaking. We
call this our Direct User phase. Let me talk about the functionality at
this point. We expanded to include our State users, and that was a
fairly big step. We replaced ICIS Phase I -- I say replaced because we
found that when looking at the functionality coming onboard, the number
of users and really the amount of data that we had to start really from
scratch so the screens and the navigation where we designed the database
was completely redesigned. We incorporated what we could from Phase I
\-- a lot of the ideas and some of the internals, especially a lot of
the enforcement actions \-- but we really ended up having to build it
out from the ground up, for the most part. I want to emphasize that we
retained Phase I functionality. That was always a requirement. We could
not lose any of the functionality that our federal enforcement and
compliance users had. A goal was always, and is still today, to
integrate where we could. If we can look across our enforcement and
compliance functionality and data, the challenge is how we can integrate
this so that we're not being repetitious as we pull in these different
media. We'll talk more about that in Challenges, but I think we've done
a good job at that with Phase II. I think we've integrated these pretty
well. It'll be another challenge with Phase III, as we begin to look at
AFS.

We integrated part of this functionality with the new and evolving
requirements of the NPDES program. PCS had not been modified in decades.
Part of the goal was not only to incorporate those requirements, but to
make the system flexible enough to add new requirements in future years.
And, I can tell you that's going to continue to happen. That was a big
goal of ours. As I said we integrated enforcement and compliance data
with the federal data that was there. We added NPDES-specific
functionality. These are just some examples, not to be inclusive. We
added the permit tracking capability. If any of you have seen the NPDES
permit, they tend to be fairly big. It includes a lot of data. We enter
data for permits and track it, like... discharge monitoring reports,
which aren't touched on here, but it's really a self-monitoring tool. As
we look across the other dashes here, this is where we talk about the
added complexity that was brought into ICIS because it really has to,
based on the data entered on a daily basis, it looks across and
calculates violations. Depending on enforcement actions entered, it
resolves violations, and it does this sometimes real-time, and some of
this is done on overnight activities. The logic is fairly complex. There
are a lot of rules that it has to go to, and that determines whether a
facility, a permit, is in compliance or not. So this kind of capability
was added.

Additionally, the generation of the quarterly non-compliance report,
which gives a quarterly picture in time of a permit and whether it's in
compliance or not.

I say this is a picture in time -- we actually run this report, take a
picture, and post it. Then it doesn't change.

We kept the Business Objects reporting tool. It's just been upgraded,
twice, to version XI. At this point we built a data warehouse for the
NPDES data. The reason for that is, given the amount of data that was
coming in to the system; we no longer could go against the operational
database for retrievals without impacting our online users. We refresh
this nightly from our database. We have a procedure that runs nightly to
refresh this data, and all retrievals of NPDES data must go against this
warehouse.

At this point, too, we no longer get all our work done during the day,
so we implemented some nightly processes. These run every night, seven
days a week. We have three of them. It's a nightly process that does
several things. It looks at a permit, and its dates, determines whether
its status needs to be changed, it generates non-received violations, it
detects RNC, reportable non-compliance, for that permit, it evaluates
schedules, and the events in those schedules, to see whether it needs to
generate schedule violations. The unofficial QNCR, run nightly,
evaluates the permits, the violations and the enforcement actions to
determine if that permit meets the criteria for inclusion on the QNCR.
This is really there to give our uses a picture on a daily basis, based
on the work that they've done during that day, of what that permit looks
like.

We had to implement a schedule -- we do this on a yearly basis -- for
work that has to be done, like the quarterly noncompliance report that
comes out every quarter on a specific day of a month. We have to synch
that up with the Permit Compliance System so that we treat all states
the same. We're running that quarterly noncompliance report the same in
PCS and ICIS -- both on the same weekend. So, some of these run weekly,
some of these run monthly, some run quarterly. That was actually put
into place, and those are scheduled and run without any intervention. We
do quarterly data exchanges with FRS as we did with Phase I but we added
some periodic data loads from a couple of OW data systems. We also do
extracts to feed into our IDEA system, Integrated Data for Enforcement
Analysis. That is our public face to ICIS. They take this data, along
with data from other systems across the Agency, and they do some
analysis against it and provide that information to the public, so we
extract data from ICIS for that as well.

For the architecture, we went from intranet to internet, and that was a
fairly big step. We had to take into account additional security
requirements. We found that it really takes a different look at how you
design your software, and then how you develop it. As you're moving huge
amounts of data from your database and system to the internet, to the
users, you have to look at your design for that, and the performance. We
found additional points of failure and some performance degradation
that's probably not going to go away. We can fix our system to perform
the best that it can. We can continue buying hardware, and will, that
allows for good performance, and continue to tune that hardware. However
what we found is our users in our states may be experiencing very poor
performance because of the state network that they're tied in to. We've
actually had to go out to a few states and sit with their IT folks and
say, "Okay, what's going on here?" And see what can be done to get their
network in shape to provide their users with good performance. That came
with going to the internet.

We replaced the hardware. We bought new, dedicated hardware to support
ICIS. We have, at this point in time, four environments that we support.
We have a production environment, we have three test ones because we
have ongoing activities -- we have ongoing O&M, we have ongoing
modernization, and we have the NetDMR project. So these are all
concurrent activities, and we can't let them bump up against each other
so just maintaining these four environments can be time-consuming. ICIS
operates and is supported by our national computing center. The software
is developed primarily in Java SQL and JSP and we're up to Oracle 10G at
this point.

The next page, and you have it in your handout so I'm not going to talk
through it too much at this point, is a picture of what our production
hardware environment looks like today.

[\[Steve Hufford -- Interjection]{.underline} -- there is a large
version of the picture at the very last page of the handout.\]

See the very last page of your handout, and you can take this with you.
So this is a look at what our production hardware environment looks like
today. We name all our servers, so you can see that -- which one is the
web app report database server. We use a SAN for storage. Up at the top
here, you'll see the CDX node. That didn't come in with direct users;
that came in with hybrid users, and we'll talk a little bit about that.
But it's there today, so you see it in the picture. We have our
development environments that have similar configurations; different
servers.

Here are some user metrics for this direct user release. As of this
week, there are over two thousand users, and we found it interesting
ourselves to see the breakout between headquarters, regional, and state.
I want to highlight that. What we have found -- the federal users are a
bit ahead of our state users. A lot of them have decentralized their
data entry. Some of our states are going that way, too. The days of one
or two data entry folks being tasked with entering everything is slowly
going away, and we've found that even some of our states are going to
decentralizing data entry, so that number of users is just going to
climb -- both because of that and as we add more states.

The next page is software metrics, and this is to give you an idea of
sizing. We currently have over 1.7 million lines of code, and you can
read this for yourself as to the breakout. This includes, and we haven't
mentioned it yet and Mike will discuss it in his presentation, that we
do have a whole data migration component to this project. We have had to
migrate data from our legacy permit compliance system, PCS, to ICIS as a
state comes in. That's been a fairly huge effort, all by itself. That
set of code is included in those 1.7 million lines, but it is kind of a
separate package of code in itself.

For volume metrics, you can read through this. The idea that I'm trying
to get across here is that our volume of data is increasing pretty
dramatically. We have several files that are in the tens of millions of
records, and that's just going to increase as we bring on more states.
Some of our larger states have yet to be migrated, and it's something
that we have to continually plan for as we go through the next five
years.

Next we'll talk about our hybrid users, as Betsy mentioned. These are
the states that will use ICIS to manage their program, and input most of
their data online, but want to batch or electronically submit their DMR
data. We implemented a DMR data flow which allows states to do that. We
have a node on the Central Data Exchange sitting on our National
Environmental Information Network. We use XML schema technology for
transmittal of that data. A state has to extract that data into a
predefined XML schema, and send that to CDX. We used web services to
pass and receive that data and messages, and we had to go back to ICIS
and build out the capability to accept that XML data and put it through
our business rules and move it into the database. We provide reports to
our users telling us how that data went into the system -- what went in,
what was rejected.

The third part is the NetDMR tool. This tool allows permittees to log on
to CDX, in to the NetDMR tool, enter their DMR data, electronically sign
it, and send it to ICIS-NPDES. The transmittal of that data uses the
existing hybrid DMR data flow to go into ICIS. But the additional
functionality of the NetDMR tools is that they have to pre-populate the
DMR on the CDX form or the NetDMR tool form before they \[the users\]
enter the data so they \[the tools\] actually request information, and
then they \[the users\] enter it, and then they hit the button to send
it. Additionally, any errors that are generated from this dataflow will
be sent back to them in a file in XML format.

States will have the capability to take this tool and deploy it on their
network. Currently we are not planning to support state instances, but
they have the capability to do that. They will of course, be interfacing
with CDX and ICIS to send that data to us. The federal instance will
reside in CDX, and once it's deployed and operational it will become a
component of ICIS and fall under the operation and maintenance task that
is in our current PWS.

The last part of Phase II is our full batch states, and I think Betsy
hit this pretty well. These are states that have a pretty robust state
system. They want to batch all NPDES data families to ICIS
electronically. There are about 40 data families, and we've implemented
it only for DMRs. Just so you know, there's a big chunk here left that
we have to do. As Betsy said, there's an alternative analysis currently
going on. Until that is completed, and an option approved by our
management here, we really can't proceed with design, but we expect that
to happen in September sometime -- in the fall timeframe.

Regardless of that, we do know that we'll be flowing that data through
CDX in some fashion using XML technology.

Back to our picture. We've gone through the four releases. I want to say
that we've learned a lot as we've gone through these releases. The
direct user state was a fairly big effort. We learned a lot from that,
and we're getting better as we go. One of the things I'll say, and I
think you'll hear this theme again, is that to carry the people that
know the business through the process of development and testing has
been critical. To team up business analysts with developers, and even
make them part of the testing team, has been really important. We find
that not only do things go smoother, but they end up coming to us in
better shape because they've been vetted through that process.

Let me go on to Phase III functionality. We expect this to happen in the
next 5 years. As we get closer to completing Phase II we'll be starting
this. As Betsy said, it's used to track clean air enforcement and
compliance activities for major stationary sources of air pollution. We
truly hope this time to use as much of the current ICIS system and data
structures as we can. We'll be initiating work on that \-- closeness of
fit analysis, data mapping \-- some of that's in progress today, or may
be in progress before we get there. So hopefully we'll be able to draw
from work that's going to be done while they're waiting for us to get to
them. We know that they're going to have some air-specific functionality
to be added. We fully expect that. We also know that we're not only
going to have an online component, but we're going to also have the
capability to batch data from user communities. And our user community
will expand to include local government entities, so we'll be looking at
security and other things that go along with that.

At this point, I'm going to turn it over to Mike Mundell, to talk about
major activities.

[Michael Mundell: ICIS Overview (continued)]{.underline}

\[short tape gap...\] and with ICIS, and there's a lot more detail in
the performance work statement, but I want to talk about some of the
major things and hopefully give you an overall feel, and build on some
of the information that Betsy and Glen have provided.

The two areas that we want to talk about are the two major aspects of
the system; one is keeping our current operational system running as we
go forward, and the other one, as Glen mentioned, is continuing to build
out the modernization of PCS, as well as the future phase with the
modernization of AFS.

First, taking a look at operations and maintenance; one of the things
that we focus on with O&M is addressing issues that are affecting the
system overall. We find that in order to support the various aspects of
ICIS and fix the problems, whether it be in the data entry screens or
issues with reports, or the database itself, it requires a lot of
expertise in a variety of different areas. That's kind of the nature of
systems today. There are database components, reporting components; so
one of the things we do as part of O&M is a lot of analysis and a lot of
evaluating what the issues are, when we look at problems to resolve
them.

The next thing is we have found, in order to most efficiently fix the
problems with the system, we've scheduled the deployments. Right now,
we're releasing operations and maintenance changes about four times a
year; it's about a quarterly release, and a lot of the changes that we
have in those releases are fixes to problems that have been reported,
but we also include with it, enhancements or changes to the system. And
I'll talk more about that in just a minute.

One of the important aspects to scheduling these deployments is looking
across the variety of things that you're changing, making sure that a
change in one area doesn't affect something else -- like the reports --
something that touches the database, how does that affect reports? So a
lot of the analysis and work that goes into it as we prepare the
quarterly releases is to make sure that these can smoothly be
implemented as a collective unit. In addition to that, as part of O&M,
occasionally we do run into issues that require emergency deployments --
things that come up that are unexpected -- maybe a change within or
outside of ICIS. One of the most important things as part of that is to
minimize the impact on the user community - to minimize any downtime -
to get as much information out as we can, as part of that. But it does
happen occasionally, as we're maintaining the system.

Also, this is a system, as Glen described, that really runs around the
clock, though the users don't have access all the time. They're only
able to access the system until 11 in the evening. There's a lot of
activities that have to happen overnight. We don't have to have somebody
monitoring it constantly, although occasionally there are issues that
come up and they have to be addressed quickly so that it minimizes the
impact on the users so during the day folks are able to continue to
enter their information and to retrieve -- to get information out.

Another area is supporting, maybe not changes or fixes within ICIS, but
maintaining the environments themselves. We talked about not only is
there production, but we have three test environments. As part of that,
there's constantly things we have to do to make sure that we're using
the most current version of the database or of Java or of Business
Objects. In fact, some of the largest changes that we've been working
with recently had to do not so much with changes to ICIS but with
upgrades to the software that ICIS uses, like Business Objects
specifically. It was a lot of effort that we needed to focus on, to get
this release out and available to our users. And then another area is
performance tuning. This is really critical because of our users'
expectations. They expect the data entry screens to come up in a few
seconds. They expect, when they run reports, that they get their
information back in just a few minutes. One of the characteristics of
ICIS is there's a lot of flexibility in the reporting, and a lot of
power in what people can do as part of the data entry screens, whether
it's reissuing a permit, or moving lots of information around, so it's
important that we constantly monitor how the system's performing.
There's a lot of effort and focus that's given to that to keep the
system performing smoothly.

We talked a little bit before about our interfaces with other systems.
The largest that we have is our interface with the Facility Registry
System, or FRS. We're one of the few systems in the Agency that actually
has a complete copy of FRS -- within ICIS -- to provide to our users, as
we're relating the various activities to a facility, and that gives you
that overall picture for the enforcement and compliance community of
what's going on at a facility. But in order to do that, we need to
maintain regular exchanges with FRS. That's a whole separate set of
software that maintains that connection, as we send information over to
the Office of Environmental Information for updating into FRS, and then
as we receive that information back. Part of our regular operations and
maintenance is to make sure that those exchanges go smoothly, that our
users count on. In addition to that, as we're expanding our electronic
exchange of information, ICIS is a node on the overall network that EPA
has, and another area that we have to maintain -- occasionally if node
software is modified, then that may be a change that we have to make to
ICIS itself. In addition to the nightly processing that we have to
monitor, there are special processes that run each weekend, and that
requires scheduling, as well as notifying our users because occasionally
it requires some downtime and some maintenance that occurs over the
weekend.

ICIS has extensive system documentation that provides information on all
the software as well as the processes that we use, so maintaining system
documentation is an area that we need to constantly keep up with as we
make changes. Even fixing problems, or as we add enhancements, the
documentation is modified.

In addition to that, there is a lot of ongoing training that we do for
ICIS. As you've heard there are new states being brought on, and those
are people that need to know the details of how to use ICIS. Currently
the majority of the training has been in-house, but it's something, as
we go forward on our planning, we want to consider the possibility of
also doing that outside of the in-house staff as well. So, training is
something that we'll be looking at.

And, then finally, outreach and communication: one of the main things
that we do in this area is that we host national meetings annually, and
we have two different major communities of users that we work with
yearly to have a conference -- that we include training, we include
information, and this is a critical area that we rely on to get
information out to our users.

Moving on -- another area in the overall operation and maintenance of
our current system is the area of enhancements, and we have a very
formal process that we go through to ensure that enhancements go
smoothly, that we really understand what the requirements of the user
community are, before we make any changes. One of the important things
that we do as part of an enhancement is do an overall analysis- an
assessment of what the impact of this change is going to be -- it may
change a specific set of screens, but how is that going to impact other
screens within the system? Other sets of users, as well as reports?
Before we plan what the scope of it is, we need to look at the overall
effect that it has.

We also have a process of working with the user community, and I'll talk
more about that in a minute. We bring together as many people as we can
to make sure that we fully understand the detailed requirements at all
different levels, whether it's the folks doing data entry, or the
overall managers that are responsible for the information. The next step
in this process is to flesh out the specifics of the design, again
focusing both on data entry, impacts on reports, as well as impacts to
the states that are submitting information electronically. The software
is then modified -- it might be Java code, it might be scripts that
affect the database, it might involve data cleanup or modifications to
the data, in order to make this overall change to the system.

And then, moving on, one of the really critical areas that we focus on
is a series of testing, to involve first the developers, then the
analysts that were familiar with what the change was, and then bringing
our user community in, to make sure that it's tested both in a formal,
and in a less formal way to make sure that we minimize any impacts.
Finally, throughout the whole process it's critical to update all the
specifications that we have for the software.

Okay, the other aspect of ICIS is really developing the ongoing system.
As both Betsy and Glen talked about, we're moving forward with bringing
other states on, to complete the hybrid states, then we are expanding
the capability for facilities to enter information into ICIS, and
finally, the full batch capability. So these are some of the specific
things that we're going forward with. In addition, farther out, we're
looking at Phase III, which brings in a whole new community of users to
support the air program. One of the things that we've talked about, as
we look ahead, is how to break this up into phases. It's important that
we continue to show progress; that ICIS continues to grow, because we
don't want to wait years and years before any changes are made to the
system. So, part of looking at overall modernization is how best do we
phase this; what makes the most sense for our user community, and for
managing the system? Betsy alluded to the alternatives analysis, which
is something else we'll be looking at as we go forward in how to finish
the PCS modernization and move into the next phase of ICIS. This also is
a very formal process, as we get into modernizing the system and
expanding it. One of the first things that you do in that process,
particularly as we're looking down the road at bringing in the air
requirements, is to look at the existing legacy systems. That brings up
all kinds of challenges -- to understand how the other system was used,
where the data quality issues are, and to address those and to move
forward with the new system to address some of the challenges that were
in the old one. So there's a formal process to map what information was
in the legacy system and how is that going to be migrated over. The
migration, which I'll talk more about in a minute, is a critical piece
because our users do rely on historical information - and that it's
available to have the overall history of the permits, the history of the
monitoring and reporting data, to support the program.

Moving on through the process, the next step is to develop detailed
designs which cover all aspects of the system, and integrate what the
new functionality is; again not only for the data entry screens but also
for how the user submitting electronic information to ICIS will be
affected. And sometimes that's a little different challenge than folks
sitting in front of a screen - how is it electronically exchanged
between state systems and our system? Into more detail, the technical
specifications are an area where pairing analysts with the developers to
make sure everyone understands what the detailed requirements are has
been very, very successful. We're also looking at the overall impact on
the architecture. As we bring new users in, is new hardware required? Do
we need to make some adjustments to what's currently there? It also
helps to plan and to set the expectations for what kind of response time
we can expect, and that's very useful later when we get into testing and
making sure that we're using the equipment efficiently.

Moving through revising the software -- and then moving into a series of
different types of testing, including load testing. The load testing is
an area that is extremely important in our separate test environments to
minimize any disruption as we add these new users and very, very large
volumes of data into the system. The load testing has been very
successful in coordinating with the National Computer Center, which
operates the hardware, to learn as much, in advance, as we can before we
implement the new releases.

Again, maintaining the documentation is just a normal part as we move
forward on these major releases. The area of user acceptance testing is
a very formal process that we have to establish a workgroup -- usually
the people that were involved in the design earlier in the process --
working with these groups of people who are most familiar with what the
changes are -- to fully test out the system, make sure that it meets all
their expectations, and then as part of the planning, make those
modifications before we release, to minimize any impact, once we go into
production, on the users.

The implementation itself is a major task, and one of the reasons is
it's critical that we fully lay out each of the steps as we go through
the process, and the various roles and responsibilities of who's
involved in that deployment, whether it be our own staff, or whether it
be folks in North Carolina who are supporting the environment. We work
through a very detailed process and plan that implementation way in
advance to make sure that it goes smoothly, and that we can address any
contingencies, also trying to minimize any impact on the users - any
downtime as we go through the process.

Another step is the actual implementation itself. Again, a lot of that
is the coordination between the various parties. We talked a bit about
data migration. Data migration is an area that's been extremely
successful as we've brought new states on, and the approach that we've
had is to involve these users each step of the way. In the beginning of
a migration, we start with an overall plan based on the kind of data,
the challenges that we have, and what the process is going to be to
migrate this data. Elaborate software is developed, independent of the
application, to move this information into ICIS. And then we have a
formal process of working with the users that are going to be coming
into ICIS where they are able to access data in the legacy system, in
PCS, or in the future, AFS, and they'll be able to modify that
information or modify the data that they have.

We then take the data, go through the migration software, and run
reports to see how close it is to what needs to be done to go into ICIS.
We've established thresholds, certain points that this data needs to be
at, in order to successfully migrate it to the system. We've actually
gone through, with each of these sets of users coming in, it's an
iterative process -- we go through the whole process of extracting data
from the legacy system, converting it, generating the threshold reports,
and providing it to the users three, or as many as six, times. Each time
the data gets progressively better, so that when we're ready to
implement them formally into production, we know and they know that the
data is going to successfully go into ICIS, and they'll be able to
access it once it's there. We'll do the same kind of thing in the future
with AFS that will involve, because there's new kinds of information
coming in, going back and revising the plan, looking at the information,
modifying the software, and then working with that community of users.
On average it takes about a year as we bring new sets of users in, to
move through this process, and to make sure that the data's going to be
where it needs to be.

That's a little bit about some of the major tasks and activities that
we're going to be involved with on ICIS as we go forward. I want to take
a minute to highlight some of the stakeholders that are involved as we
go through ICIS because that's been critical to the success, and it will
be, especially going forward as we bring new users in. We work
constantly, not only with the day to day users of ICIS, but also the
managers in the regions and the states, as well as the technical staff
here and there to make sure that the quarterly releases, the unexpected
emergency releases, as well as the planned changes to the system, go
smoothly. We also work with the Office of Wastewater Management, who's
responsible for the NPDES program. They are users of the permitting
parts of the system, and other parts of the system that support the
NPDES program. One of our very valuable partners is the Office of
Environmental Information, and we're in constant communication with
them, both on the operational side for the database, for the servers,
and also for Central Data Exchange, as we're planning for future
releases, and now as we have people electronically submitting
information we're constantly in communication with their support staff
as well as their management.

A couple of other areas: data standards. ICIS needs to adhere to the
data standards that the Agency has for exchanging information with
States, as well as enterprise architecture, the standards that EPA is
setting, going forward, for its data. Looking to the future, one of the
areas that's growing will be working with permittees, or the regulated
facilities. That is, users of the NetDMR component that we talked about.
And then a new area will be local government offices. For the Air
program, not only do they work with the States, but a city or
municipality may have the authority to issue permits, and they in the
future would become users of ICIS as well. So that's another new
community that we need to be aware of and plan for and reach out to.

How do we communicate with these various users? It's through a lot of
the groups that we've already talked about, whether it's these data
migration workgroups that we work with in that year as we're bringing
new States on, or integrated project teams where we make sure that we've
got all the various players -- the State staff, their contractors, as
well as the technical staff here -- involved in the planning as we go
through the process, or requirements gathering workgroups. We found that
it's very valuable; and one example that comes to mind is, recently, we
completely redesigned how inspections are entered into ICIS and that was
an area that we looked at where there were reported problems \--but we
went to the users -- the people in the states and the regions that are
responsible for entering those inspections so that they could give us
ideas, both initially at the high-level design and then as we went into
the details of the testing, to make sure that they were involved in that
and that it met all their expectations. So, it's very critical to have
them involved, \-- and they are throughout the enhancement process.

Let's talk a little bit about designs, and also again the user
acceptance testing. Having them involved, we've found, has made a very
significant difference, when we implement into production, of minimizing
any downtime. Steering committees and governance groups, as Betsy
alluded to, is a new area that's very critical, particularly with the
diversity of user communities that we have, to make sure as we plan
where we're going to change ICIS in the future that if we make a change
to the NPDES portion that it's coordinated with other parts of the
program. And there're decisions that have to be made, and the governance
process formalizes that. So it's something, as we plan how we're going
to modernize ICIS, and add enhancements, that there's a process we'll be
working with. We talk to NCC all the time, and then finally the national
meetings, which ... allow us to meet face to face with many of our
users.

Let me take just a minute on some of the challenges that we have. One,
as you can imagine, is keeping in step with the technology as it
evolves. Because this is a long, multi-year process, we need to
constantly look at how best to keep ICIS moving forward and take
advantage of some of the newest changes to IT. Another area of challenge
is to look across our various user communities. Even within the federal
enforcement and compliance area, we look for the common types of
information across the air program, the water program, and being able to
create that standard is a challenge. But then beyond where we have
common information within the enforcement and compliance community,
there are the unique needs in Water and, in the future, within Air. And
we need to make sure, as we plan changes to the system, and as we go
forward, that a change that we might make to Water doesn't affect other
parts of the system. And many times the needs are different between the
program and the federal view.

Another one is the challenges of our different sets of users, whether
they're federal users or state users. The data that they are responsible
for, required to be entered, is different -- whether they're federal or
state. There're different views of the system that they come in and look
at. The rules that they have to meet are different. And meeting the
needs and requirements of both of those sets of users is something that
we need to be constantly aware of.

There're a lot of ongoing activities in parallel. Maintaining the system
and trying to minimize impacts of changes to the system at the same
time; making sure that versions are maintained, and that we can test
quarterly releases, as well as moving forward on the overall
modernization of ICIS; as well as specific events, like the end-of-year
reporting. This is a big deal. Or, the quarterly noncompliance report
that NPDES has - this requires special processing; and to make sure, as
we work with those different communities of users, that we're not
affecting the other group unintentionally.

Finally, there are a lot of different groups, a lot of formal
relationships that we have; and they're listed there. There are, not
only within ICIS and our user community, but a lot of broader
initiatives that are coming forward, whether it's e-Gov, electronic
reporting. There're things we need to be aware of. Also, within the
federal funding process, we need to look 3-5 years out to plan where
ICIS is moving. Also, within the current budget year, the actual budget
we receive may not be the same that we planned for, so we have to stay
flexible as we move forward on releasing ICIS. Whether it's continuing
resolutions or other challenges, it's something that we need to be aware
of.

Next, we want to talk a little bit about what EPA is looking for, and
I'll hand it over to Lucy Reed.

[Lucy Reed: What is EPA Looking For?]{.underline}

You have been listening for the last hour and a half to Betsy Smidinger,
Lisa Lund, Glendora and Mike talking about ICIS -- the programmatic
overview, the ICIS system overview, as well as the executive overview.
Now, I want to talk a little bit about what we're looking for from a
company that would actually get this award, starting with strength in
project/program management, requirements analysis, change management and
risk management.

We're looking for a commitment not only from the project management
level but also from the corporate level. We would hope that there is
support and commitment from the corporate level - one of the examples
that we would expect support at that level from -- would be leveraging
resources across the company to support the ICIS project. If there is a
need in the ICIS project for a technical person that is not currently on
the project, we would expect that at the corporate level, you would be
able to find the resources to support the project.

We're looking for strong project management that would provide for
manageable deadlines, early identification of problems, ongoing
identification of risks, impact of risks, and proposed resolution of
risks. We're looking for proactive versus reactive project management.
We're looking for adaptability to change -- as you know if you've worked
for the government before, there are times when the budget we expect to
get, we don't get, so we have to re-look at project scope as well as
funding for the activities that are to be performed in a given year. We
would hope that the company would be able to adapt to change. We need
strong analysis skills. We need strong technical skills. That's all
under strong project management, requirements analysis, change
management and risk management.

Going to the next "what we're looking for" slide -- we're looking for a
holistic approach that integrates environmental programmatic subject
matter expertise with the information technology expertise. What I mean
by that is we would expect the company to look at the system as a whole;
look at the environments across ICIS; look across applications; for
example Business Objects versus the applications; look across components
of the system. As Mike and Betsy and Glen have talked to you about
previously, we are supporting the NPDES program, the federal enforcement
and compliance program, we're supporting in the future the air
enforcement and compliance program and everything we do on each of those
components could potentially impact the others. So in looking at the
system and in looking at the work that needs to be done on the system as
a whole; you have to look across the system to address the work that has
to be done.

We're looking for someone that could perform continuing impact analysis
across the ICIS application, from the user as well as the system
perspective. Again, we have different users, and they expect us to make
changes to the system that would be done from their perspective versus
just the technical \[perspective\]. And one of the things that we've
experienced that has worked in the current contract, and Glendora has
alluded to this, is putting the analyst together with the actual
technical programmer in doing enhancements and changes to the system,
really helps. It helps in that the product that you end up getting will
support the user needs as well as the technical needs, if they work
together from the beginning to the end, in making changes to the system.

We want a contractor or a company to think innovatively in coming up
with solutions, have strong programmatic knowledge (for example the
enforcement and compliance program, versus the NPDES program and the air
program and the solid waste program). We would expect and want the
contractor or company to have strong experience in those areas in our
program. We would hope that the contractor would be able to think
proactively in support of the business as well as the technical needs of
the system. Again going back to having a system that supports different
organizations, different programs, and knowing the business of those
different programs helps in the development of the system and in the
operation and maintenance of the ICIS system.

Going to the next area; use of defined software engineering practices,
tools, and methods to deliver high-quality services in a
performance-based contracting environment. EPA is looking for a company
that would stay abreast of the best IT practices. For example, how would
we continue to build out the system and maintain the operational system
in a practical manner? We would be looking for use of new methodologies
and tools to design the system and maintain the system, at the same
time, meeting deadlines and delivering quality products. When you're
doing this, take into consideration EPA's system lifecycle methodology
when you're performing the work. EPA does have system lifecycle
methodologies that we have to adhere to, and we would expect the work to
be done under those lifecycle methodologies.

The next one would be successful past performance on contracts of
similar scope, magnitude, relevance, and complexity to the requirement
described in the PWS. EPA is looking for appropriate, experienced staff
\-- staffing that could support our needs for supporting our large and
complex ICIS system. We want experience working on contracts that have
the same scope and size of the ICIS system. We would want that in a
contractor that's going to be working on the system. And, again, EPA
environmental and programmatic and contract experience. We would be
looking for someone that has experience working on environmental
contracts, and working on EPA contracts in the past. We would be looking
for that as well.

The last one is comprehensive, realistic staffing plan and transition
plan that are responsive to our requirements. EPA is looking for
comprehensive, realistic staffing plans that would support the work
described in the performance work statement. For example, appropriate
experienced staff that could support both the ICIS system as well as the
business needs of the ICIS system. You've been hearing this as a
recurring theme -- the business need versus the technical need. That is
very important in working on the ICIS system because of our diverse
universe of users and how one thing can impact the other. It's important
to us that our users are satisfied with the system as well as satisfied
with us going forward in developing and modernizing the system to
address their needs as well as the EPA need.

\[We want...\] A realistic transition plan that demonstrates to EPA an
approach to getting up to speed on the system environment, getting up to
speed on the business of the system, getting up to speed on the work
entailed in operating and maintaining and enhancing and modernizing the
system a transition plan that would provide your ideas on how best to
get up to speed on the system. And a plan that would demonstrate to EPA
that you know what has to be done, and that your plan for doing it is
reasonable and achievable.

That's what we're looking for. Those are five things that we're looking
for in a company, in doing the work for ICIS. Now, I'll turn it over to
Lin, and Lin can take questions and go from there...

[Lin Pinskey: Structure of the Task Order]{.underline}

Before we get into the Q&A, I just wanted to give you a picture of how
we plan to set up this task order since it won't be a separate contract
but will be a task order under an existing Government-Wide Acquisition
contract. The program and I have talked about the various ways we could
accomplish the recompete. You've heard various speakers allude to the
funding crunch that we have in Federal government meaning that we have
to do more with less. The Agency has to deal with unfunded mandates and
things like that. A program office has to get something done or write a
report, but has fewer dollars to accomplish it. Therefore it's important
to have a company that is innovative, flexible, etc. Our discussions
centered on ways of pricing the effort so that we incentivize a
contractor but we also allow for flexibility. So we felt that using a
cost-type of pricing arrangement would be a good way. In fact, what
we're planning on doing is breaking it up into two incentives. There
will be an incentive fee that we're going to ask you, the contractor, to
propose in your proposal. We haven't talked about a minimum. Of course,
it can't go above the maximum -- the statutory maximum of 10 percent. So
it can be up to ten percent, and we're going to be tying the incentive
to the quality assurance surveillance plan. I have a slide to show you
as an example. In this way we hope to ensure , essentially, good
month-to-month, week-to-week performance.

That is part of the incentive. We also plan to include another broader
incentive, by including award terms. The task order will start with a
base period of two years, and then, based upon the contractor's overall
performance, the contractor can earn additional periods of performance.
So, we will have awards of additional years for Award Term Years 3, 4
and 5 to make it a potentially five-year task order. Of course, no task
order can go five years beyond the end of the Millennia contract, which
right now is October 27^th^ 2009. So that's our plan - a short-term
incentive for you and your subcontractors to meet performance, and then
the overall picture of an award term incentive.

I have a slide of one of the potential QASP standards. The incentive fee
will be tied to the total number of hours in your proposal to create a
fee per hour. We will take the incentive fee we approve and divide it by
the number of hours in your proposal. The inventive fee will be paid per
hour delivered each month. On your monthly invoice, you would include an
amount for the incentive fee that is based upon the hours you deliver.
The purpose is to prevent a contractor from receiving all of the fee
before you deliver all of the effort that you proposed and that we
agreed to.

But we're also going to, as soon as we can, put this QASP up on the
website, because we'd also like to get feedback from you. I mean, maybe
we've got a standard in there that isn't maybe the normal industry
standard. So if you can provide some feedback to us on, you know, there
may be a better way to describe that, we'll look at it. We'll make the
ultimate decision; we always do, we're the 800 pound gorilla in the
room, that's government. But if you have some suggestions, once you see
the QASP, please provide those to me. Obviously, I'm your point of
contact, as is Jennifer Pohedra. I will feed that to the program office,
and we'll take a look at it. We'll also be looking at your comments just
to make sure that you're not skewing it toward yourselves

Because we're just going to have one task order -- we can\'t have
multiple task orders \-- We will operate it in a similar fashion to the
way I am currently operating the Central Data Exchange Task Order. Some
of you may be familiar with it, and some of you are not. On this task
order, as with CDX, we will have individual statements of work that I
will issue that will probably include more than one of the 15 Task
Areas. The contractor will have a 10-business day turnaround to come
back with a response. If necessary, the TOCOr and I will have to
negotiate it with the contractor. We may accept it as submitted. The
contractor will start to perform. We could have more than one SOW for
one or more Task Areas.

The Task Order will have one Task Order Contracting Officer\'s
Representative, however the Task Order likely could have other COR\'s.
Glendora Spinelli will be the ICIS TOCOR. But there will be other people
coordinating with her as well. So there will be individuals that we will
call Subtask Area CORs to whom I will delegate authority for technical
direction.

I\'d like to now open it up for discussion....

[Question & Answer Session]{.underline}

[Steve Hufford]{.underline} -- if you wrote anything on the 3x5 cards,
I'll be glad to collect those. I'm also happy to pass this microphone
around the room. We're certainly open for questions, and you can ask any
of the speakers, except Lisa Lund who had to leave for another
appointment. So if you have strategic questions, we'll just take a stab
at it... -- any cards? I'll wander along here...any cards... how about
any questions? There we go...

[Dave Carnes]{.underline} - My name's Dave Carnes. I'm with TRC
Environmental. You talked about a holistic view and you mentioned about
the scope and the bounds of the project. And with the compliance and
enforcement components, especially with air, where they're delegated
programs and the state writes their own regulations, so a lot of the
requirements that come in are specific to what the state wrote \-- I was
wondering if you saw within the bounds of the system whether you'd be
able to see what those requirements were for a facility, so you'd have
perhaps a better definition of what the regulated community was being
held accountable for. So that when you came in with compliance... okay,
let me try again. The question is, with the compliance community you're
looking at the compliance relative to the air programs. And that with
Title V a lot of the states have a delegated program and they write
their own requirements in response to their own laws. The question I had
was to the extent they define these requirements and then they do their
own enforcement, do you envision the bounds of the system including a
definition of what those requirements are?

[Lin Pinskey]{.underline}: I forgot to mention one thing - that we have
copies of DVDs of the technical library. Kathy Dockery in the back of
the room has one copy for each of the prime contractors in attendance
today, but we will have other copies available on the 6^th^ floor of the
Ronald Reagan Buidling in the Bid and Proposal room as well.

[Betsy Smidinger]{.underline} -- Just to clarify. Are you asking what
the requirements will be when we go to modernize AFS?

[Dave Carnes]{.underline} -- Well, in AFS we know what programs a
facility is subject to, and we know their compliance and we know when
there's been an inspection, you know when there's a violation relative
to an air program, but you really don't know what the facility has been
asked to do under the permit. For instance, you don't know what the
permit looks like. You don't know how many conditions in the permit
require them to do quarterly reporting or semiannual reporting, or
what's to be included in the annual compliance cert., per se. I wanted
to know if you envisioned the bounds of the system trying to understand
what the states were including in these permits.

[Betsy Smidinger]{.underline} -- I have two things on that, 1) As we're
going along, we're doing as much of the work, early work, that we can,
in getting ready for AFS modernization. We're doing some business case
analysis now. We'll be doing some requirements analysis. 2) For AFS --
currently, there is an ICR, an information collection request, for AFS
that we just received final approval on. That will go along with this as
well. As we get to a point where we're in a more modern system with AFS,
we will be looking to expand the requirements that we can collect from
the states for the air information on the enforcement side. There have
been discussions. Right now the states have been reluctant to expand the
amount of data, because it's difficult to get the data into AFS right
now, and there are difficulties with that. Once we modernize, we're
hoping to expand on some of the information we're getting. Does that
answer your question?

[Dave Carnes]{.underline} -- Yes, actually that leads into my next
question, if I could ask... because you talked about the regulated
community potentially submitting data to the system, I think it was on
one of your slides.

[Betsy Smidinger]{.underline} -- The regulated community for AFS?

[Dave Carnes]{.underline} -- No, for ICIS. The question I had was, would
you envision a facility directly reporting to the system? Like with the
annual compliance certification, where they'll be submitting it as an
electronic submittal to many states, would you see that submission
coming to the system directly? Or do you still see that coming to the
state, and a summary of that data coming up to ICIS?

[Betsy Smidinger]{.underline} -- For the NPDES portion, as we mentioned
as we were going along, the NetDMR information is the first part of the
information that we'll be receiving directly from a facility. We haven't
even gotten to the point, with the air part, to investigate which
requirements the facilities or the regulated community could directly
report to us. That will be something we'll need to do as we go along in
our analysis of how we're going to modernize AFS.

[Steve Hufford]{.underline} -- Other questions? They can be more AFS
questions, or other topics as well...

[John Carroll]{.underline} \-- You were mentioning the AFS requirements.
Are those part of task area 3, coming up with those requirements? Or
would those already be done, in terms of IT requirements? The AFS
requirements...Is task area 3, which is the detailed design, is that
going to include gathering requirements for AFS, or will that have
already been done?

[Glendora Spinelli]{.underline} -- Task area 3, the detailed design, is
that what you were saying?

[John Carroll]{.underline} \-- Yes

[Glendora Spinelli]{.underline} -- I anticipate that that will not be
done yet. I think that they're going to try to do bits and pieces of
this -- I think they're talking, maybe, doing a data mapping, like data
requirements but they can't really get into detailed design until we're
ready to start working with them because we have to integrate that in
with the design of ICIS overall. So, no, that will be outstanding. At
least we anticipate that today as being an outstanding issue.

[Lucy Reed]{.underline} -- Outstanding in that we won't do it. It would
be done under this contract.

[Steve Hufford]{.underline} -- Next question?

[Andrea Myslicki]{.underline} - I just wanted to know where the current
development environment is located, and if it's owned by the Government.

[Lucy Reed]{.underline} -- Could you tell us who you are and what
company you're from?.

[Andrea Myslicki]{.underline} -- sorry, Andrea Myslicki, SRA.

[Glendora Spinelli]{.underline} -- I\'m sorry, could you repeat your
question?

[Lucy Reed]{.underline} -- She\'s asking where our the current
development environment is located.

[Glendora Spinelli]{.underline} -- Our current development environment
-- we own it -- the servers -- we purchased them, they're specifically
used for ICIS. There's one exception to that but it's going to be going
away before this contract starts. It is currently housed down at our
national computer center in Research Triangle Park, NC. And it is
maintained by the staff down there, with support from us. Does that
answer your question?

[Steve Hufford]{.underline} -- Other questions? IT or programmatic or
anything.

[Maya Melhern]{.underline} -- This is Maya Melhern, with Booz Allen.
Lin, this is a question for you. Can you share with us the acquisition
schedule?

[Lin Pinskey]{.underline} -- What I can tell you is that the intent is
to have this awarded no later than, the middle of December at the
latest. Where we can compress some of the schedule, we will. Some of it
will depend on how many proposals we get. I can tell you that the
schedule will be compressed where we can do so. We will not be doing
oral proposals, by the way. We plan on receiving written proposals. So
we can give you the end date, where things will be. My plan is to get
the task order request out in the next couple weeks. That's driven by
the levels of review that have to happen at the Agency, and the review
levels are driven by the total dollar value. There will be a certain
period of time for you to come back with technical questions. We will
need to amend the task order request to address any technical questions
that you have. If we get one outstanding, fantastic technical proposal
with a realistic proposed cost, we can make an award without any further
discussions. If we don\'t, then we have to go through the process of
discussions etc. So part of the driver is whether or not we can make an
award without discussions. That is the preferred method, but sometimes
you can't do that Therefore you have to allow for that in the schedule.
Absolutely it will be awarded before we get to Christmas; preferably
even before the middle of December.

[Steve Hufford]{.underline} -- Did that answer your question?

[Maya Melhern]{.underline} -- Yes

[Steve Hufford]{.underline} -- Any other questions?

[Dave Carnes]{.underline} -- I just wanted to point out when the
migration to CDS to AIRS took place, back in the 80's there was also a
statement, that I heard today, where you were going to take the data
from the existing legacy system and bring it over. And one of the things
I remember from back then is that we ended up bringing a lot of the
information from the CDS system in to AIRS. I just wanted to make a
comment that you could end up -- some of the structures there -- you
could end up bringing CDS forward even one more generation if you just
take a carte blanche effort on that. The other question I had, that was
just a comment really, but the question I had was on data ownership when
you get into this world of integration, with the water community and the
air community. Inevitably you're going to run into a number of tables,
where there's going to be shared data. Probably the primary one might be
the regulated contaminants, where you have HAPS that are regulated by
both air and water. Do you envision committees, or having some sort of
decision on data ownership, from both the perspective of the state
versus EPA, and then air versus water, so that you can truly understand
who's managing what tables?

[Betsy Smidinger]{.underline} -- From a data ownership perspective, we
have, for as long as I've known now, wherever the source of the data is
coming from -- so if the data is coming from the state, the state is the
owner of the data. And EPA will not change a state's data. They're the
data owner. They're the data steward. If something is incorrect with
their data, the state is responsible for correcting it in the system.
EPA won't change their data. We'll work with them, we'll help them,
we'll talk to them, but it's their data. And I think the second part of
your question, if I understood it correctly, was where there may be
overlapping areas in the system between, say, federal enforcement and
compliance and water, say a list of pollutants, are we going to have
specific fields or dropdown lists or tables for each of those areas? I
think it really depends on what the field is. How specific it is to the
particular universe. How we want to set the system up in doing that. As
I mentioned we are getting a governance structure up and running,
hopefully in the beginning of the next fiscal year, for some of those
types of issues -- that's the purpose of that governance structure, to
talk about those types of things, and for the users to figure out how
best they want the system to work for them. It would also, again, need
to be a mix of, not only what the program needs are, but from a
technical aspect, how can we mesh the two things together.

[Glendora Spinelli]{.underline} -- Just to add to that. I would
anticipate, as we've done in the past, that when we get to that point,
we will most likely convene some workgroups with users. Everything we do
is very visible and we've involved our user community and other
stakeholders in everything we do, because the system is supposed to work
for them. So, I anticipate that we will continue to do that, and involve
them every step of the way, so they will have a lot of input into how
the system is integrated into ICIS.

[Dave Carnes]{.underline} -- That's great, thanks. I think the
experience is that if you let something like that go you'll end up with
duplicates or very-similar-sounding values for your tables that will be
confusing to the community. I work a lot in the state of NY and they
took the best people for each component, things like the contaminants
and the regulations, and by having the best person it avoided confusion
with those tables. So you don't have two things that mean almost the
same thing. And I think if you take that \[approach\] with this national
system, you get that best group of people who really know that subject
matter, and you keep all your reference tables clean, then that will
solve that kind of problem.

[Glendora Spinelli]{.underline} -- If you're truly talking about data
migration from another system, or data conversion from another system,
we've actually had a lot of success with that. And again, we would be
involving our user community in that; to do the mapping, the rules, how
data would be migrated to ICIS. I should add that we follow the Agency's
data standards. We have to do that, so a lot of our states do as well.
We've actually had pretty good success in this, regardless of the
program that we've been working with, and I think as long as you involve
these folks at the beginning, and have them have a stake in it, your
chances of success are good, and we will continue to do that.

[Lucy Reed]{.underline} -- Generally what we do when we set up
workgroups to this type of activity we send out memos requesting support
for the effort and we ask for subject matter expertise. So, going into a
workgroup, we have people that know the program, and know the area we're
working on, to help us come up with a solution.

[Lin Pinskey]{.underline} -- As you can probably tell, just from
listening here, the cooperation among other governments, and also with
other contractors is important because the contractor that gets this
task order is going to have to interact and work well with other
contractors. Cooperation among contractors will be an important factor
in the performance standards as well. The systems today are too
integrated and the nothing is accomplished with finger-pointing. We have
to have cooperation among contractors because the systems interact and
have to work together.

[Steve Hufford]{.underline} -- One of the things I was asked to confirm
relates to a tool we're making available to all of you. It's a DVD of
technical documentation. I just want to confirm that all the prime firms
that are in here in the room today, make sure you pick up your copy.
There'll be additional copies available later, when the solicitation
comes out officially, in a room over in the Reagan building, but we do
have copies here today, one for each of the Millennia primes.

[Glendora Spinelli]{.underline} (to Andrea Myslicki) -- it was brought
to my attention that maybe your question was a little bit different,
about the development environment. I was actually referring to our EPA
development environment. Let me just say that what we expect is that the
firm that gets this contract will actually develop this software on an
environment at their facility. So they would have to configure and
develop a hardware environment similar to our test environment. So they
would develop it; then when we think it's ready, we move it to our test
environment to do final testing. Is that more what you were talking
about?

[Andrea Myslicki]{.underline} -- Yes.

[Steve Hufford]{.underline} -- Last call for questions or cards. If you
want to submit any cards, for questions later, we can keep picking away
at the answers. If we don't get them here, they'll get up on the website
that Lin has mentioned.

[Lin Pinskey]{.underline} -- I thank you all for coming today. Keep
checking back on our website. When we get the transcript, I will do two
things. I will post it on our HPOD website and I'll also of course use
the Millennia link to send it out that way . The slide presentations
will also be on the website and I will also transmit them using the link
on the Millennia website. You\'ll have two avenues for information.