By Stephen Kuhr and Brian Reed
The combined sewer systems typically found in older U.S. cities were designed to collect stormwater runoff, domestic sewage, and industrial wastewater in the same pipe. Modern system design uses one pipe to convey stormwater runoff to nearby water bodies and a separate pipe to convey domestic and industrial sewage to a treatment plant. Most of the time, combined sewer systems convey all of their wastewater to a treatment plant; however, during periods of heavy precipitation the volume of stormwater runoff plus the wastewater going into the pipes can exceed the capacity. The excess untreated wastewater empties directly into nearby water bodies. These events are known as Combined Sewer Overflows (CSOs).
Over the last 10 years the District of Columbia Water and Sewer Authority faced a series of challenges to prepare for the implementation of $2.2 billion in federally mandated improvements to its 100+ year old wastewater collection system to reduce CSOs into the water bodies of the District of Columbia. First the Authority needed to develop a program and rate schedule that its customers could afford while still addressing other critical capital needs. Second, the Authority needed to determine how to allocate the program costs. Lastly, the Authority needed to develop the policies, systems, and work processes to implement the rate structure and collect revenue.
|Figure 1: Equivalent Residential Unit|
Parsons Brinckerhoff (PB) helped the Authority to navigate each of these challenges by offering financial advisory support in negotiations with the federal government, researching rate structure options, and developing an innovative system for billing customers on the basis of their property’s impervious area.
What Can Customers Afford?
The Authority’s discussions with the Environmental Protection Agency regarding ways to mitigate the effects of CSOs began in the late 1990s. In the planning phase, the Authority drafted a long-term control plan (LTCP) to implement a program of improvements, principally tunnels, to reduce CSO events. It was imperative to determine the shortest delivery period that could be reasonably affordable to Washington, DC, residents. Working closely with the Authority’s finance and engineering executives, PB developed scenarios to evaluate the impacts of the proposed options on the Authority’s customers. With this, the Authority negotiated a 20-year delivery schedule with federal regulators, 33 percent longer than other cities. A longer delivery schedule resulted in a reduced rate impact on customers and gave the Authority greater flexibility in its capital program.
Who Should Pay the Cost of the CSO Program?
In parallel with the regulatory negotiations, an evaluation was done on how best to recover the costs of the CSO program. To the maximum degree possible, the Authority’s Board of Directors sought to assign the CSO program costs to those customers driving the program costs. Once this principle was articulated, the challenge became determining how best to accomplish this goal.
CSOs occur during heavy periods of precipitation when the stormwater runoff overwhelms the capacity of the system. Properties with large amounts of impervious surfaces (buildings, paved areas, parking lots, etc.) will contribute more runoff to the drainage infrastructure than a park or properties with grass, which allow stormwater runoff to percolate through the soil. The Authority desired a rate structure that would capture this cause-and-effect relationship.
A comprehensive cost recovery study reviewed rate structures in practice in addition to providing benchmarking information on CSO LTCPs in other communities. The review showed the extensive use of cost allocation based on the amount of impervious surface on properties for stormwater programs. Although this was a proven approach in stormwater programs, it was a new approach for a CSO program.
|Figure 2: Vee Systems Engineering Methodology Diagram|
Similar to many other utilities, the Authority charged customers water and sewer rates based on the volume of water passing through the customer’s meter. Using this structure for the CSO program was an option but it implied the more water a customer consumed the more a customer would pay towards the CSO program; a poor fit to the proposed cause-and-effect rate structure.
An important consideration for any change from volumetric rates to land-based rates was the profile of the Authority’s customers, specifically the water consumption and land ownership characteristics. Table 1 presents data from Authority billing records on water consumption versus total impervious area on individual properties by customer category.
|Table 1. Water Consumption vs. Percent of Impervious Area on Property|
Table 1 demonstrates that switching to an impervious area-based rate would meet the Authority’s objective of having the cost-causer pay more of the costs of the program. It also shows that switching rate structures would result in higher bills for some customer categories and lower bills for others. Multi-family properties (high-rise residential buildings) occupy a relatively small footprint but consume higher volumes of water for domestic uses such as dish and clothes washing. So, when an impervious area-based rate becomes effective, multi-family properties would typically have a lower bill because they have a relatively smaller share of the total impervious area compared to their share of total water consumption. On the other hand, the municipal properties would typically pay more in this rate structure since they have the opposite characteristics — a large impervious area footprint compared to their relative share of water consumption.
How Should Customers Be Billed?
Part of the implementation phase was ensuring that the Authority possessed the legal authority to create a new rate structure. The Authority’s enabling legislation gave it the ability to bill and collect for volumetric water and sewer fees and other related charges such as hook-up fees. A modification to the city’s code was recommended and adopted to allow for the use of an Impervious Area Charge (IAC). The IAC was called a service charge and not a tax as the Federal government, an important Authority customer, cannot be taxed but can be assessed a service charge.
Implementing a new rate structure would require altering the Authority’s databases and customer bills for the estimated 120,000-plus customer accounts. The Authority’s Customer Information System (CIS) was set up to bill customers for water and sewer volumetric fees. The CIS and the customer bills needed to be updated to include the new IAC billing fields. The rate structure needed to be transparent and easily understood by staff and customers.
The research showed that a methodology commonly employed by stormwater utilities to simplify billing is the use of the Equivalent Residential Unit (ERU). The ERU represents either the mean or median impervious area of all residential properties. Figure 1 depicts an example ERU calculation.
Under the ERU methodology, residential customers are charged one ERU per month and the other categories (commercial, federal, etc.) are charged in multiples of ERUs. An advantage of the ERU approach is that billing of the approximate 105,000 residential customers is greatly simplified for Authority staff since they will all be charged the same amount each month (1 ERU).
Implementing the IAC required capturing data from many sources and integrating it into the Authority’s billing procedures. The District of Columbia government maintains property data layers on a Geographic Information System (GIS) platform for public use. This data includes information on individual properties such as: address, owner, land features (buildings, sidewalks, roads), and property type (residential, commercial, etc.).
To create the IAC system, the district government’s property-based data and the Authority’s customer-based data in its CIS needed to be linked and managed in a GIS platform. A new IT system was created to handle the billing of the IAC: the Impervious Area Information System (IAIS). A central objective of the IAIS was to allow the Authority to synchronize tabular information such as property ownership data (owner’s name, address, etc.) with the respective property’s physical attributes, such as the spatial location (coordinates) and boundaries of impervious area (buildings, driveways, sidewalks, etc.), in one database. The CIS contained tabular data (owner name, address, etc.) and the District Office of the Chief Technology Officer (OCTO) GIS data contained tabular data plus spatial information (real world coordinates/location). The IAIS would also give the Authority a powerful tool for spatial analysis and reporting.
What Does a New Billing System Require?
As part of the initial work effort to design the IAIS, Authority stakeholders were interviewed to determine the conceptual framework of the system and to outline the technical requirements needed to bill customers for the IAC. The IAIS system design was accomplished by using the Systems Engineering VEE Methodology (see Fig. 2).
A Concept of Operation document was devised along with a functional requirements matrix to assist in the development of the data warehouse, system and application. A decision was made early in the project development that the Authority would utilize existing data from the district government to build the system since its data contained the best property information. The software development process was a combination of rapid-prototype and iterative development methods that required close coordination with Authority staff as an ESRI ArcGIS application. The application was designed to interface and work in conjunction with the Authority enterprise Oracle data warehouse.
|Figure 3: System Architecture|
How Good Is the Data?
Developing the data to support the IAIS was done in conjunction with multiple district government agencies, including the Office of the Architect of the Capitol, and Office of the Surveyor. Data sources were evaluated, catalogued and analyzed for quality, thoroughness, gaps, and update frequencies/methods. Once assessed, a multi-faceted approach was applied to clean and prepare the data for implementation into the IAIS.
The customer data was a core component of the system. It was necessary to update and validate customer locations (spatially), address (tabular data including mailing and service), ownership, status, type and relationship to other customer locations on single properties, as well as impervious area information (square feet, type of feature, and original feature source/version).
A rigid QA and evaluation process was implemented to ensure the integrity of the data. The process involved a review of existing data, gap analysis, identification and prioritization of issues, and risk/benefit analysis to determine recommendations for data processing. Options and risks were presented in a series of workshops with the Authority oversight committees. A significant effort in the data analysis was creating geometry for the “missing” properties and correcting anomalies in the GIS since the property records for the District did not include most federal properties. All of the data was then incorporated into a newly designed Oracle 10G data warehouse schema.
How Does the Authority Use the System?
A series of interview workshops were performed to assist in determining the system architecture, components and how it needed to function within the Authority. As part of this process, a master list of requirements was created and weighted priorities were assigned to each. Once the initial prioritizations were complete, a weighted risk factor was established for each and a high-level risk mitigation plan was created.
Figure 4: IAIS Data Flow Diagram
As a result of interviews with stakeholders, business process improvements were developed, including a series of step-by-step procedures that staff needed to follow in order to process information within the Authority. A business process and function manual was created that provided a detailed training program for the Authority technical and management staff.
After a lengthy process of setting strategy and policy and then developing the tools to implement them, the Authority rolled out the system in May 2009 and started collecting the IAC. Starting more than one year before the IAC went live, the Authority initiated an aggressive campaign to inform its customers and the public of the change on their bills through a series of meetings with Advisory Neighbor Commissions, the City Council, and major customers. The public information campaign was deemed successful, in part because of the lower than expected calls to Customer Service after the first bills were mailed.
Over time the Authority anticipates revenues to reach up to $150 million each year to pay for the $2.2 billion CSO program.
About the Authors
Stephen Kuhr is a Management Consultant and Brian Reed a Senior System Engineer with Parsons Brinckerhoff, a global infrastructure strategic consulting, engineering and program/construction management organization.