BY BILL MANNING
Collecting and using uniform fire department incident reports and other critical data at the national, state, and local levels may be the single most important opportunity for fire service development and fire department success in the next few years and beyond.
Statistics are what drive the government funding mechanism, but the fire service drives a Model T. The fire service fights for its causes with sketchy data and colorful fire patriotism. There’s no horsepower to it.
The new National Fire Incident Reporting System, NFIRS 5.0, is supposed to change that. It is supposed to deliver the breadth of information that translates into more political horsepower and, just as important, a greater understanding of what we do and what we need to do. Many claim that is, or will be, the case.
But there is a lengthening shadow growing over the NFIRS project. And, in the broad sense, that should concern us just as much as any fire on Main Street.
In the Fire Prevention and Control Act of 1974, Congress tasked the United States Fire Administration with operating a comprehensive national fire incident reporting system. Many would characterize the process toward that goal as difficult, at best. Others would be more inclined to call it a debacle. All would agree that attempts prior to NFIRS 5.0 fell short of fire service needs.
The USFA contracted the National Fire Protection Association to write the earliest versions of NFIRS. Unfortunately, the feds did not purchase the rights to subsequent revisions to the software programs. It was to use these first-generation programs virtually without alteration for the next 25 years of NFIRS. That’s not because the programs were 20 years ahead of their time, but because the history of NFIRS is a history of stumbles.
In the early 1980s, the USFA converted its programs so they could be run on personal computers. It was during this period that the Administration made its first forays into the software business. It offered its software, NFIRS 3.0, or “Polaris” and, subsequently, NFIRS 4.0, or “MicroNFIRS,” “free” to individual fire departments. But the software couldn’t compete in the marketplace against the private software vendors. It didn’t even do that well with state agencies, many of which opted to create their own nonconforming reporting systems.
The USFA was not deterred. In the mid-1980s, despite the dismal response to MicroNFIRS and over the objections of the software vendors, the USFA restated its intention to make software for fire departments.
In 1989, the USFA began its development of NFIRS 5.0. The National Fire Information Council (NFIC), a not-for-profit group comprised primarily of state fire service representatives, was and continues to be a strategic player in the process. The USFA has paid the NFIC between $200,000 and $550,000 a year to help sustain the group in its efforts. It only made sense that the fire service, represented by NFIC, should have a large hand in specifying and implementing data collection. Unfortunately, other key players would be minimized, with serious consequences.
Some four years later, FireSoft, then the largest fire service software vendor, successfully pitched the USFA to produce the computer code for the new NFIRS 5.0. The USFA hired a minority firm as the primary contractor, thereby circumventing the competitive bidding process. The total contract was for $500,000. Former FireSoft Chief Executive Officer Wayne Bennett stated his company agreed to subcontract the job for about one-fifth of that amount, provided FireSoft controlled the design process and retained the copyright to the software code, terms to which he said the USFA agreed.
Unfortunately for FireSoft, its bid to corner the market ended in disaster. Bennett claims that he produced a software design and most of the computer code. But the primary contractor billed for and received payment in full, ending the contract. FireSoft did not receive another USFA contract to finish the job.
FireSoft closed its doors in 1997. In his parting shot, Bennett accused the USFA of stealing FireSoft’s work and making it available to the public. Computer industry sources contend that elements of FireSoft’s design are obvious in today’s NFIRS 5.0.
This brief history is not provided here merely as a refresher. As the evolution of NFIRS 5.0 seems to bear out, the USFA would adopt a strategy that includes three tactics: First, it would create software for the fire departments. Second, it would control and protect the programming codes to its software. Third, it would seek to ensure the success of its software products by restricting its competition, the commercial vendor interests.
Immediately following the FireSoft fiasco, the USFA handed the NFIRS 5.0 project to Bell Atlantic (now Verizon). Bell Atlantic already had a large information technology services contract with the Federal Emergency Management Agency, boss agency to the USFA. Simply and quietly, the change was made, without competitive bidding, under the existing Bell Atlantic contract. “It was perfectly legal,” says Alexis Furr, director of the USFA’s National Fire Data Center. And it cut fire software vendors out of any significant involvement in the design process.
The USFA has refused to release the figures on exactly how much it has paid Bell Atlantic and how much it intends to pay Verizon. The NFIRS 5.0 project does not appear as a line item in the FEMA budget. Certain records, however, indicate that Bell Atlantic/Verizon has received somewhere in the vicinity of $5 million or possibly more. And with the release and implementation of all or parts of NFIRS delayed in most cases by two years or more, the Verizon cash register will keep ringing, as will that of a company called Eye Street Software, which has subcontracted to Verizon to perform NFIRS 5.0 programming. Eye Street’s involvement was kept a secret by the USFA-not even NFIC knew about it-until fire software vendors discovered its Web site describing its work on the project. Ch-ching, ch-ching.
“The users have driven this all the way, not the federal government,” says Assistant Chief Steve Worley of the San Antonio Fire Department and past president of NFIC. “We knew we could do better. We were not going to be bound by anything.”
Thanks in large measure to NFIC representatives, the NFIRS 5.0 design specifications contain some fine new features. It has been expanded; incident reports are now far more detailed than before. It includes “plus one” codes so that fields can be expanded if states and fire departments want more detailed data on specific topics. And it now includes, in addition to a fire reporting system, EMS, wildland fire, and arson modules.
In addition, says Worley, NFIC encouraged the USFA to develop basic reporting software especially for fire departments that can’t afford vendor software. It’s called the Federal Client Tool (FCT), which contains a very basic no-bells-or-whistles incident reporting package offered to fire departments on the condition that states provide support for its use. The FTC originally was designed for departments with less than 3,000 incidents a year-meaning its storage capacity is quite limited.
“I like it,” says Texas State Fire Marshal Mike Davis. “I think the feds should provide the software, especially when $200 or $300 for some departments is the difference between having apparatus fuel or not.”
“Firefighters around the country are saying things should have been like this all along,” says Worley. “It’s firefighter friendly. It takes a department that’s on paper and moves them into the computer age. It’s a stepping stone to vendor software.”
And many others agree that the “bare bones” FCT satisfies an important function yet takes little away from fire service software vendors, whose programs have many more fire department applications beyond incident reporting. “The vendor programs are user-friendlier systems,” says Andy Fritz, division supervisor of New Jersey’s Fire Incident Reporting Section and member of NFIC. He says the contention made by some that the USFA is entering the software business “couldn’t be further from the truth.”
“It is not our intent [to enter the software business],” says the USFA’s Alexis Furr. “We encourage people to work with the local vendors. We don’t have the technical support capability to go into the software business.”
However, there is reason to believe the USFA’s intention with regard to software development may be otherwise.
“The USFA told us up front that participants will get a copy of the software,” says Worley. There are currently some 44 states and more than 14,000 fire departments participating in NFIRS 5.0 in some fashion.
More notably, in 1998 or earlier, the USFA developed a plan to create four separate end-user software programs for fire departments and states, based on the number of annual incidents. If your annual runs were less than 3,000, you would receive one program; less than 10,000, another; and so on. The USFA provided minimal and recommended hardware requirements for each program.
And that plan, should the USFA follow through, would have a huge impact on fire service software vendors. There’s no reason to believe it won’t follow through, since the USFA has not announced otherwise. Furthermore, NFIC and the USFA plan many more modules in the future, in the areas of rescue, fire inspections, ARFF, and building code compliance, to name a few. The list could go on, diminishing one of the vendors’ primary advantages, multiple functionality.
So the questions arise, naturally. What is the role of the federal government in our national incident reporting system? Is it to compete with private businesses in the free enterprise system, using tax dollars? Is that what we want from our USFA? What would you say if the federal government devised a plan such that it would design and build fire apparatus and then place restrictive incentives for you to purchase its plain-Jane line of trucks? Did you know the feds tried to do just that a couple of years back? Is it déjà vu all over again?
It seems the only reason the USFA didn’t carry out its four-tiered software plan is that in 10 years it only produced the FCT. Furr says the FCT was the USFA’s all-purpose software all along, for states and for fire departments. But why would the USFA purposely construct such a small-capacity program that lacked the storage capability required by many states and cities? It wouldn’t unless it had to, of course. It was past its deadlines, states were getting antsy, and it made do with what it had-the FCT, which has an upload capability.
The USFA rules dictate that no matter whose software a department or state uses, any participating entity must forward collected data to the USFA using its approved software-that is the FCT, and only the FCT, the “3,000 annual incidents or less” software, which for reasons of expediency, it seems, has become the USFA’s “software of choice.”
One of the ways a state can use the FCT is to upload fire department data directly through the USFA server. With today’s technology, data specialists and even regular folks the world over are uploading googolplexes of bytes to databases in one shot. But the FCT restricts you to uploading only one file at a time-that is, the USFA program will recognize and accept only one fire department at a time. It can take an hour to upload between 20 and 1,000 incidents in this system, depending on file size and server traffic. Think about what that means for Josephine, the state fire data manager. For a state with, say, 500 departments reporting, how many computer operators will she need to upload the files each month, assuming that each spends 100 percent of their work life uploading files?
One manager of a state fire data system put it succinctly. “The Federal Tool is way too slow for a professional data entry operator,” she said, off the record. (“Off the record” are words that were repeated numerous times by many of those I interviewed for this piece. Why is everyone so skittish? Is the emperor naked again?)
Another individual with a bird’s-eye view of the development process said, “There were people in the process who thought the FCT was insufficient. I knew it would not work for [my city].”
There have been numerous other complaints. Reports that “the system got hung up for 1:45 hours before it would even process 100 incidents.” That “for the past month it has taken forever to import the smallest amount of incidents.” That state operators can’t even get into the FCT without their computers locking up. That the system went down during scheduled fire department NFIRS training sessions. And so on. One data manager complained that “the darn thing doesn’t work.”
In the past, vendors could upload statewide or department incident data directly to the USFA using what was known as the file transfer protocol. No longer. The USFA has done away with the procedure, it says, for security purposes. It’s FCT or nothing. Either it is afraid of hackers, or it is afraid of vendors. “If nobody knows how it works, then nobody can hack it,” says Joe Zeigler, president of FirePrograms software. “But if you don’t know how it works, then how could a vendor upload to it? That’s why they need the Federal Client Tool.”
Either way, big data uploads from vendors make too much sense and save too much time. The USFA has warned constituents that vendor uploads would be considered “nonsensitive.” It’s their way of saying the data came from an “outsider” and they’re not going to recognize it.
The USFA is in full control, one tedious fire department upload at a time.
Technically, the FCT was designed to support, at most, a small local MicroSoft Access database, hence its original billing as the 3,000-runs-or-less software. In releasing the FCT as the upload mechanism, the USFA has cheated the state, in a sense. States that recognize the FCT’s database limitations are most likely to upload fire department data directly through the USFA server. So the state uploads its data (one department at a time) to the USFA, and there it stays for as long as it takes the understaffed USFA National Data Center to turn it around in a usable fashion-a “usable fashion” as determined by, you guessed it, the USFA. (The fire data analysts, like the vendors, were discouraged from participating in the spec design process.) Mary Nemeth, who manages Michigan’s state fire data reporting, says, “The frustration is getting data back off [the USFA system]. The feds aren’t ready for it yet.”
The USFA admits there is a lag in data turnaround of as much as two years. “This would be the first year for ’99 data,” says Furr. “We’re still waiting on some states. We’re still dealing with two systems [NFIRS 4.1, the previous system, and NFIRS 5.0]. And it is the states’ data to begin with-they may not have released it officially to us.”
The “official release” proposition is indeed a curious one. The only data the USFA will officially recognize is that which comes to it via its official software, the FCT. By definition, then, any data uploaded in conformance with USFA rules has to be “official.” Why does the USFA need official release when, by its very nature, the data is official?
It’s ironic that the USFA is “waiting on some states.” First, the USFA’s own timetables and press releases betrayed it. It couldn’t deliver on its own promises. “They were trying to create a product that served everyone; that’s why it took so long,” says Peter Tom, president of Emergency Management Solutions and member of the NFIC. “But it got too big. Then they didn’t test it because they were in a hurry to make their [reissued] deadlines. Some of the states threatened to build their own [systems] if the USFA didn’t get their system up in a hurry.”
Second, the wait has been caused in many cases by the USFA’s program glitches. For example, the USFA included a tool in its FCT software for converting NFIRS 4.1 to NFIRS 5.0. Apparently, that’s not working too well in some cases. Despite assurances from one state fire marshal that all was going well in his jurisdiction with the exception of a few minor setbacks, Fire Engineering has learned that the state actually lost thousands of incidents using the USFA conversion tool. Because the legislature was in session and reports were due, it had to convert its data back to NFIRS 4.1, salvaging what it could-in this case, only the fire incidents.
“When we try to promote a program that compiles data that no one will ever see or use, what are we really doing?” lamented an individual involved in the exercise in futility. “Who are we really helping? The efforts of all those departments submitting data seem like nothing more than a waste of time, energy, and resources.” The individual sent the data to the USFA for conversion. She still hadn’t heard anything back from the USFA more than a month later.
But the USFA cheated the states-and outsmarted itself-in another way. Individual fire departments, regardless of size, can upload directly to the USFA themselves. They don’t need the state. The USFA says it will deliver the FCT to a fire department at the state’s request, and only if the state will support the fire department’s use of the FCT. So if fire departments upload directly across the USFA server or, in the future, directly via the USFA Web site, the state has gained nothing-actually, it has lost a fire department’s data for two years or so, until the USFA regurgitates it in some form. This probably is not the kind of support the states are looking for.
The FCT software is connected to the USFA server. Any changes that are made to the specifications coding are automatically updated-that is to say, the FCT is always up to date with itself.
The “final” NFIRS 5.0 design specifications were made available to fire software vendors in January 1999. The vendors designed their software packages based on the FCT specs issued. The vendors then self-tested their software using a validation tool supplied by the USFA. Passing the test means the vendor has written a program that meets USFA requirements and will result in software that fire departments can use and upload to the states. A vendor that wants to sell software to the fire service must perform this process if it wants to receive the USFA’s “conditional certification.” The USFA has issued strict warnings to states and fire departments that using nonconditionally certified vendors preempts them from participation in NFIRS 5.0. The conditional certification is the vendor’s ticket to the USFA’s fire software dance.
Soon all hell broke loose. Vendors that were passing the USFA validation tests found that their software wasn’t working in the field. The reason? According to vendors and others, the USFA (or its programmer) was making unscheduled and unannounced changes to the FCT design specs-basically, when it felt like it. So, in effect, Wednesday’s spec changes made Tuesday’s vendor software inoperable in some cases. The fire department data would not upload to the FCT without error.
The USFA issued and announced 193 changes to the spec at irregular intervals over a period of about a year. But the vendors claim that more than 120 changes to the FCT were never even announced-they just “happened.”
Vendors scrambled. Disks were scrapped, new software reengineered and revalidated, and products redistributed, with the sickening feeling that their products could once again be obsolete the moment they hit the mail if more spec changes (don’t call them “changes”-the USFA prefers the word “clarifications”) were to rain from Mount Olympus. There is no “backward compatibility” written into the FCT, even though it is a common programming feature. Everything depended on when the USFA made the changes and when the fire department received the software.
Vendors began spending more and more time and manpower on support issues, on “Operation USFA Spec Watch,” and on retooling. The little guys did the best they could. The bigger guys were able to dedicate employees to Operation Spec Watch.
Survival took precedence over product innovation; if you didn’t keep up with the USFA’s design changes, you would lose conditional certification and be banished from the dance hall.
The USFA’s response, at least in some cases? It was the vendors’ fault. And probably in some cases, it was. But suddenly, many fire software vendors that had been operating successfully and with integrity for years were being challenged and even maligned. One vendor was taken to task in a newsletter published by a state organization taking its lead from the USFA (the newsletter article never mentioned the company’s name, but everyone in the state knew who it was talking about). The FCT is always up to the minute. There’s no trouble with the federal software. What’s wrong with those vendors?
“In the midst of ‘specification chaos,’ there was a perception that vendor software is not as good as the federal software,” says Michael Fay, president of Advanced Command Systems, producer of FirePoint software, whose resume includes service as deputy superintendent of the National Fire Academy and president of the Fire Software Vendors Association, a group established to help facilitate NFIRS 5.0 but that has since been deflated in the process. “The federal software was set up as the standard, and because no clear specs were given to the vendors, we were always behind,” he adds.
Software vendors started dropping out of the fire industry in alarming numbers.
In a letter to Zeigler, Robert Wagner of Crossfire Software writes, “Software vendors… operating on a shoestring budget were looking at poorly written specs ….released at random, that were changed frequently …. It was soon apparent that the specs being turned out by [the USFA] were not going to improve, nor was the fact that [the USFA] appeared to want to control the software vendors, their actions, and their systems [going to change] …. We got out just in time, before CrossFire went under as did ….others.”
Michael Seip, Sr., of Fire Service Software, wrote to Zeigler, “My company was most likely one of the smallest developers to close up shop due in part to the NFIRS fiasco …. It seemed like I received more changes than there were fields to start with …. I decided it just wasn’t worth the trouble for a two-person operation to try to keep up with … NFIRS.”
In another letter, Lee E. Elliott, principal, the Elliott Company, wrote, “Yes, [my company] is closing its doors. This is due in no small part to the fiasco called NFIRS 5.0 as perpetrated on an unsuspecting fire service by a federal government agency that is obviously out of control and completely over its head when it comes to data processing and the orderly generation of updates …. Without resorting to legal means, there is no way to win. Incompetence is one of the hardest things to get corrected, and this 5.0 effort has been replete with it.”
One vendor, still in business and close to the NFIRS 5.0 development process, said, on the condition of anonymity, “The USFA is in a position to put any one of us out of business. We have a good case for a lawsuit. They control everything, they control the system, and they do it in a vacuum, making changes without sitting down with vendor groups.”
“I don’t think I’d be in business without income from other sources,” says Fay. “Our sales dropped about 40 percent [after the NFIRS 5.0 conversion], I think because of uncertainty in the marketplace. The cost of servicing existing clients has risen at least by 400 percent …. The USFA is beta testing NFIRS 5.0 on the entire country. There have been changes every six or eight weeks, different, subtle changes, both announced and unannounced…. On January 17, 2000, I made all their latest spec changes to my software and then I started distributing CD-ROMs to my customers. On February 17, 2000, the USFA released ‘the rest’ of the January changes. All the CDs I sent out were no good.”
(Speaking of beta testing, the USFA did conduct one such exercise involving six fire departments from Pennsylvania in 1998. “The results were less than satisfactory,” says Kent Leid, manager of fire data for the Pennsylvania State Fire Commissioner’s Officer. Pennsylvania is not yet on line with NFIRS 5.0 but plans to participate.)
And there were other vendors who quit, either in part or in whole, because of the USFA’s tactics. But the saddest story of all is that of Herb Clark, who for 11 years operated FireFile, a small company with some 800 accounts, all in Texas. For most of those years, FireFile had a staff of one-himself. Later, he was joined by his son. Clark recounts, “I downloaded all the [spec] changes [they issued]. There were 193 changes. On October 28, 2000, we passed USFA’s test program and distributed the software. There were no errors on October 28. Then they started bouncing data at the state level ….
“So again I ran our software against the validation test and started getting failures. I said, ‘Son, you must have screwed up!’ But he didn’t. I found many more changes to the spec than what showed up on October 28. They never changed the date and time on the test program, but there were changes. Come January, I expect to see there’s over 350 changes on that list.
“[The USFA] says if you have data problems and don’t resolve them, you can get decertified …. Someone [from the USFA] starting pushing local NFIC people to get the state to pressure the USFA to decertify FireFile.
“So I left the business, voluntarily, but I was getting all that pressure and I didn’t have the money to devote to the battle and continue to write programs. I closed the doors in November 2000 ….
“Eleven years of your life …. We put a lot into it, hours of support, 9 a.m. to 11 p.m., and two of us to do it, but when a fire department calls and they have a question, that’s not an imposition-I respect the hell out of the firefighters. You do get an emotional attachment. And I have always been in favor of NFIRS 5. It helps fire departments, it’s good for the country. I’m so pro NFIRS 5.0.
“Emotionally, you’re hurting …. I stopped collecting technical support money from my users for 11 months because I didn’t think it was right. Maybe it wasn’t the smartest thing to do because it sure hurt me financially, but like I said, I respect the hell out of the firefighters.”
To be continued next month.
