Hits, Misses, and Abject Failures

There’s nothing like having a clever name for a system. In this installment of my blog, I’ll take a walk down memory lane and share with you some of the more fanciful system names I’ve run across. Along the way, I’ll also describe some of the more interesting projects I encountered during my career and their outcomes.

So, without further ado, listed in alphabetical order, is my “rogues gallery” of hits, misses, and abject failures.

ADAMS – Agencywide Documents Access and Management System

Whenever I think of ADAMS, I’m reminded of our third president, John Adams, and how he was, as Benjamin Franklin put it, “in some things is quite out of his senses”. Like Ben Franklin working with John Adams in France during the Revolutionary War, NRC users have learned to put up with ADAMS idiosyncrasies.

ADAMS is a content management system developed by the US Nuclear Regulatory Commission (NRC) in the mid-1990s based on a commercial-off the shelf document management system. NRC’s goal with ADAMS was to make the agency a “paper-free” workplace.

Every unclassified paper and electronic document pertinent to NRC business flowing into the agency is profiled, scanned, and and stored as text-searchable portable document files (PDF) in ADAMS. Likewise, all final documents produced by Commission staff are also profiled, converted to PDF, and stored in the ADAMS.

As part of the effort to deploy ADAMS to the NRC staff and the public, many older documents, some predating the Commission, were scanned from microfiche and paper and loaded into ADAMS. The originals were shipped off to the National Archives and Records Administration for final disposition. Shooting for the goal of becoming “paper-free”, NRC greatly reduced the size of the document and microfiche collections held in several “public reading rooms” and began using ADAMS to release documents for public consumption. Members of the public can access the ADAMS “public document library” through web-based ADAMS (WBA – found here).

WBA uses a folder-centric view into the ADAMS document collection organized by document release date. Unless you’re in the business of “hoovering” NRC documents (and there are organizations in that business), the WBA folder structure isn’t going to be the most efficient way to find what you’re looking for. Therefore, WBA provides two search tools: one for searching by document content (“Content Search”), and the other for by document properties (“Advanced Search”).

For NRC staff, ADAMS provides a native windows application, the “ADAMS desktop” similar to WBA, for working with documents in ADAMS. Unlike WBA, the ADAMS desktop has additional capabilities not available to the public. For example, NRC Staff can add documents to ADAMS and use it as a way to share and edit documents instead of using shared network drives. ADAMS maintains the version history of documents and allow users to set document attributes.

NRC staff can also use the ADAMS desktop to designate a document as publicly available and launch the process for publishing a document, which makes the document available in WBA and accessible to the public. The process is triggered when a staff member using the ADAMS desktop drags the icon for a document to a special publishing folder. Upon detecting that a new document had been placed in the folder, ADAMS generates a message to the document processing staff to check the document for accessibility, ensure that sensitive information is not in the document, verify document profile attributes, and then copy the document to the ADAMS public library where it is released to WBA for public access.

What I’ve just described appears to be an effective way to greatly reduce, or even eliminate, paper documents. But if you found yourself in the NRC office space back in 2005, you might have thought differently judging from the number of file cabinets gobbling up space in NRC’s offices.

Having participated in writing a business case for a similar document management system at the Federal Reserve (one of the reasons the NRC hired me), I knew that two cost reduction areas used to justify systems like ADAMS are reducing/eliminating physical space used for storing documents (i.e., file cabinets) and improved staff utilization by freeing them from the burden of searching for paper documents.

It would have been interesting to check the ADAMS business case and see what the anticipated savings were from eliminating paper file storage and paper searches by staff members. Unfortunately, that documentation, much less much of the ADAMS development project documentation, is found in ADAMS.

From conversations with the users, I learned how difficult it was for them to find a document once it was stored in ADAMS. NRC was using a complicated document profiling mechanism (over thirty profile attributes) combined with a poorly designed user interface, making it difficult to define search criteria for retrieving documents. The only sure-fire method for fetching the correct document was to know its system-generated ADAMS accession number. An inside joke amongst the NRC staff was that an ADAMS search would “find everything except what you were looking for.”

When users did find a document in ADAMS, they would print it out and put it in a file cabinet and/or save an electronic copy (downloaded as a PDF) onto a shared network drive or workstation, never having to deal with ADAMS again. This practice was rampant throughout the agency.

Another intriguing utility NRC “bolted” onto ADAMS was an electronic records management system (ERMS). Like ADAMS, the ERMS was based on a commercial off the shelf product, but it came from a different vendor. The thought at the time was the ERMS would, on demand, identify documents in ADAMS that were ready for record disposition to the National Archives and Records Administration (NARA). The ERMS would then “pull” these documents from ADAMS and package them up for transmission to NARA. NRC even won an award from NARA for being the first federal agency with this capability.

Unfortunately, when it came time to pull records from ADAMS, we found out that the ERMS didn’t work because it was never finished. Apparently the developers focused so much on building ADAMS that they forgot (or didn’t have the funding) to finish building the ERMS. NRC found itself between a rock and a hard place because the off the shelf software used to build the ERMS was over ten years and no longer supported by its vendor.

To add insult to injury, the off the shelf software used to build ADAMS was technologically obsolete and would soon be going on extended support. The vendor had come out with a totally new product incorporating some of the custom-developed ADAMS features as standard features in its new offering. ADAMS would have to be modernized, which, as the ADAMS Sr. Project Manager, was supposed to be my job.

Or so everyone in the Division of Information Services, where I worked, thought. However, the Project Management Office (PMO) in our sister division (Business Process Improvement and Application Development Division -BPIAD) had a different idea. Instead of supporting my Division as a customer, the PMO and BPIAD behaved as if it was the ADAMS owner.

I tried to push ADAMS modernization following the best practices I learned with FAS4T (described later) and my work on system acquisition projects while working in PMO at the Board of Governors of the Federal Reserve. But BPIAD and the PMO would have none of that and wanted to do it their own way (following a plan that contradicted their own project methodology). More drag was added when my Division Director proved to be an ineffective project sponsor and did little to get the project going.

After four years of ramming my head against an organizational wall and getting nowhere (and the impression that my real job title was “ADAMS Fall Guy”), I decided that my services could be used better elsewhere. So I left NRC and moved to the Environmental Protection Agency. Nothing regarding ADAMS modernization was resolved. The system remained as it was.

So what happened to ADAMS? About a year after I left for EPA, NRC replaced the then existing ADAMS web based search with the Web-Based ADAMS (WBA) you see now. I heard there were plans to swap-out the legacy off the shelf document management system with a newer, supported version for ADAMS and the ERMS. I don’t know if that task was completed. If ADAMS was modernized, I hope the project team improved its usability and NRC was able to surplus several hundred filing cabinets.

ASAP II – Another Stupid Accounting Program II

Developed by the US District Court for the Middle District of Florida, the original Acquisition System and Accounting Program (ASAP) was a DBase IV application developed by in-house court IT specialists. ASAP was used to track court funding allotments (authorizations to spend appropriations), expenditures, and to generate purchase orders.

The original ASAP was designed to work at the court office level and not at the district level. For example, a Public Defender office might use ASAP to track its office expenses against funding allotments. The Office could then generate financial reports and purchase orders from ASAP and share them up the chain with the Court District’s financial office, which cut the treasury checks to pay the bills within a court district.

By the mid-1990s, DBase IV, and, along with it, ASAP, was getting long in the tooth. Microsoft had bought out FoxPro (a DBase competitor) and released a native Microsoft Windows version of it. Having just ended the Court Financial System 2 (CFS-2) development project (an earlier software development debacle meant to replace a legacy financial system used in the courts), the Branch Chief in the Accounting and Financial Systems Division at the Administrative Office of the US Courts (AOUSC) decided to revamp ASAP by porting it over to FoxPro for Windows. This new iteration was given the uninspired name “ASAP II”.

The Branch immediately ran into problems with ASAP II development. What started out as a simple “port” from DBASE IV to FoxPro for Windows, leveraging the richer Microsoft Windows user experience, became a full-blown reengineering effort. It wasn’t because ASAP needed reengineering because the subject matter experts (SMEs, who were AOUSC system accountants) didn’t have any real problems with the way ASAP functioned.

This is how ASAP II development went: The SMEs would test a new feature and discover that it didn’t function as expected. During test reviews with the developer, they learned their specifications had been changed by the developer without consulting them. There were several cycles of specifications, development, testing, and then discovering the specifications were changed. It was like trying to shoot a moving target.

Along the way, the lead developer alienated the rest of the development team by not sharing work to the point where ASAP II development became a one-person effort and the project the personal purview of the Branch Chief. Soon thereafter the acronym “ASAP” took on a different meaning amongst the SMEs: “Another Stupid Accounting Program”.

Eventually, ASAP II was completed and made available as a download to any court unit that wanted to use it; and several did. It didn’t help matters when ASAP II displayed a message requesting users send a present and a greeting card to the lead developer and the Branch Chief on their birthdays. This triggered another ASAP II release cleansed of the code responsible for the birthday message.

In the meantime, the Accounting Division launched a new project, the “Financial Accounting System for Tomorrow” (FAS4T – see below) that ultimately became the single, standard financial management system used across the federal judiciary. ASAP II disappeared into the mists of history, never to be heard of again (until this article).

BOND – Banking Organization National Desktop

BOND was developed by the Board of Governors of the Federal Reserve System to support bank examination teams responsible for regulatory oversight of large, complex banking organizations (LCBO). LCBOs were, then, the forty or so largest companies operating in the United States providing banking and other financial services to their customers. This designation includes banking organizations that are “too big to fail” (or allowed to grow too large to fail, depending on your point of view).

Back when I was working at the Board of Governors, the Federal Reserve System used Lotus Notes as its email system. Notes was more than email; it also had calendaring, group discussions, document management, and file sharing/versioning features. IBM, the owner of Lotus Notes, was also adding new features for supporting “knowledge management”. Lotus had defined a new genre of software known as “groupware”.

BOND was built on Lotus Notes leveraging Domino.doc to support team sharing of documents, data, and information about LCBOs. To facilitate development, the Board bought the rights to the Lotus Notes source code and added some modifications to help BOND.

While that may have improved the usability of the application, it brought with it some disadvantages. For example, whenever a new version of Lotus Notes came out, the Board had to extensively test it against BOND and, if there were issues, make corrections to its version of the Notes source code. As a result, it usually took months for the Board to upgrade to the latest version of Lotus Notes.

About a year before I left the Board in 2005 (to move to NRC), I was almost “Shanghaied” by the BOND technical team because they wanted me to help them improve the system. Looking back, I should have “jumped ship” to work on BOND. It was a high-profile, intriguing application about to leverage IBM’s knowledge management features. I might have retired from the Board instead of EPA if I had made that move.

In 2018, IBM sold Lotus Notes to HCL Technologies, a company headquartered in India. I have lost touch with my BOND contacts, so I don’t know what ultimately became of BOND.

CRAP – Court Reporting and Accounting Program

“CRAP” was a suggestion for the name of a new financial management and accounting system for the U.S. Courts. I note it here because it was very funny at the time it was suggested. We all got a big laugh out of it. I guess you had to have been there. The winning entry for this “name that new system” contest was FAS4T.

DW-SFTIES – Drinking Water State-Federal-Tribal Information Exchange System

DW-SFTIES (pronounced “DW Safeties”) is EPA’s Office of Ground Water and Drinking Water’s (OGWDW) fourth attempt at replacing the legacy SDWIS State application (described in the SDWIS Prime section below).

Don’t be fooled by the name because DW-SFTIES has very little to do with exchanging data between the states, federal government and tribes. And only one tribe (the Navajo Nation) has delegated enforcement responsibility from EPA for regulating drinking water suppliers under the federal rules. While the states are required to report data to EPA on a quarterly basis, that data exchange is rather sparse.

Furthermore, despite happily receiving significant funding from EPA to help with their delegated programs, many states are loath to report to EPA anything beyond the minimum required data specified in the regulations. Regarding data exchanges between states, the intention with DW-SFTIES is to partition data by state agency, which will impede, and not promote, data sharing between states.

Why the name DW-SFTIES? My guess is that it’s an attempt to further align SDWIS modernization with the goals of the EPA’s E-Enterprise for the Environment effort, perhaps with the hope of securing more funding from sources other than OGWDW.

OGWDW ended the third attempt at SDWIS modernization in 2019, after my time at EPA. Since then, OGWDW refreshed the alternatives and cost analysis. While the analysis did compare custom developed software with off the shelf products, it could have gone farther and included several different acquisition strategies. For example, creating a new grant and engaging with a university to build the system.

In 2009, the Office of Water (OW – the “parent” office of OGWDW) Project Management Office (PMO) produced an alternatives analysis for modernizing SDWIS State (check out my article Some Inconvenient Truths About SDWIS for more info). In addition to vastly underestimating the complexity of SDWIS State, there was also a real lack of imagination in selecting alternative system acquisition strategies on the part of the PMO. As a result, the analysis significantly underestimated the cost of developing the SDWIS State replacement.

In 2021, OGWDW “refreshed” the analysis and revalidated the technical approach that OGWDW developed in the years after the 2009 analysis. The new strategy is to custom build the replacement system, now named “DW-SFTIES”, using a “no code” development tool.

Hopefully OGWDW won’t repeat the experience of the first iteration of SDWIS modernization, which used a “low code” development tool. That project collapsed when the developers found themselves writing custom code to handle the security requirements supporting data compartmentalization by regulatory agency. Presumably the newer tools will work better. Some experimentation before committing to a development tool would be a wise move.

Apparently to ensure that DW-SFTIES doesn’t repeat the sins of SDWIS Prime, the project team has set a Business Requirements Document listing 104 summary requirements published in 2013 as the project baseline. These requirements describe the “regulatory life cycle” of a water supplier. The project team back in 2013 used this BRD to identify what “phases” of the water supplier life cycle are within the responsibilities of SDWIS NextGen versus state system responsibilities. Beyond that, the document was essentially useless to the project because it didn’t drill down into the detail needed for development.

In effect, the DW-SFTIES team is scrapping about six years and around twelve million dollars worth of requirements and design work. How could a project go so far off the rails for so long? And what is OGWDW doing differently now to prevent a repeat? The two big issues I kept bumping into when working on SDWIS modernization was that OGWDW and state stakeholders never shared the same vision for what DW-SFTIES/SDWIS Prime/SDWIS NextGen should be and there was a lack of push on the OGWDW side for ensuring whatever system we were developing met EPA’s requirements.

OGWDW (and OECA, the Office of Enforcement and Compliance Assurance) wanted the system to be fully auditable and able to report who did what in the system and when they did it. In addition, OGWDW wanted the system to be able to track every requirements the regulatory agencies placed on a water supplier regulated under the national drinking water rules. The state drinking water administrators said they agreed with EPA. However, many of the key state stakeholders working with the development team wanted us to make the system so flexible that it would undermine its audibility (and, probably down the line, their drinking water regulatory programs).

Have things really changed since 2009? Except for the disappearance of OW PMO involvement in the project and what appears to be recognition that SDWIS is and should be managed as a program, I don’t see any substantive changes in the structure and function of the governance around the project.

After ten years of work, what does EPA have to show for its SDWIS modernization efforts? It delivered a web portal where laboratories can submit samples data electronically (the Compliance Monitoring Data Portal), flowcharts showing decision logic for all the drinking water rules and new versions of the SDWIS State application for handling the latest drinking water rules. If I were OGWDW, I would save a lot of time and effort by upgrading SDWIS State (and making it capable of handling multiple primacy agencies) rather than building a new system. Unfortunately, that alternative wasn’t included in the original or in the latest SDWIS modernization alternatives analysis.


Elvis was the acronym for a desktop application developed by the Board of Governors of the Federal Reserve System used to support bank examinations. I heard about this system while working at the Board in the Banking Supervision Project Management Office. I never knew what “ELVIS” stood for, but the story about what became of ELVIS is more interesting than what ELVIS actually did.

It turns out that the estate of Elvis Presley found out about ELVIS and sent a cease and desist letter to the Federal Reserve lawyers. Not wanting to cause any further trouble, the Fed lawyers directed the ELVIS system owner to change the name. And with that Elvis became FRED – the Federal Reserve Examination Desktop. Later, FRED was joined by NED, the National Examination Desktop.

I have no idea if any of these systems are still in use today.

FAS4T – Financial Accounting System “4” Tomorrow

FAS4T was official winning name for the Financial Accounting System for Tomorrow, an effort by the Administrative Office of the US Courts (AOUSC – see ASAP II and CRAP above) to acquire a new financial accounting system. When the project started, AOUSC was supporting two “home grown” legacy financial systems in 54 of the 94 US court districts. Various other systems and tools (like LAFS and ASAP, among others) were used by the remaining District, Bankruptcy, and Courts of Appeals.

I include FAS4T here because the name was a source of derision by some of the stakeholders. Whenever the project team faced a challenge, the skeptics would say something about how “tomorrow never comes and neither will FAS4T”.

One thing the FAS4T project team did at the beginning of the project that I haven’t seen since is holding what I call “truth sessions” with the users to more fully understand their pain points with their legacy systems. Through weeks of facilitated user sessions, we identified a lot of pain points and frustration. We were able to direct that pain and suffering in a positive way by getting the users involved in the project.

Despite the delays the team faced (FAS4T came in late and over budget), the system did come, and so did the users (deployment started in 2003, if I recall correctly).

Was FAS4T successful? In the winter of 2015 I served on a jury at the Virginia Eastern District federal court. At the end of my service, I went to the financial office to pick up my parking and meals reimbursement check. I asked the clerk if they were using FAS4T and he said they were. I couldn’t help it, so I asked him if he liked the system, and he said he did and that he’s been using it for ten years. Last time I checked, (in 2021), FAS4T was still in service and being moved to the “cloud”. Fifteen years of use to me indicates success, even if it’s the system “for tomorrow”.

I learned more about IT projects (especially commercial off the shelf acquisition projects, managing user expectations, and organizational change management) in the three years I worked on FAS4T than in the remaining thirty-five years of my career in IT. Here’s a hearty shout-out to Phil McKinney, the then Chief Accounting Officer of AOUSC and FAS4T project sponsor.

LAFS – Los Angeles Financial System

The hilariously named Los Angeles Financial System (LAFS) was a financial management and accounting system used by the US District Court for the Central District of California, based in Los Angeles. The court paid its bills and jurors and tracked all the financial aspects (fees, fines, and such) of the cases it managed using LAFS. In 1997 when I saw LAFS, California Central (as we called it) was one of the top five largest Court Districts (in cases tried) in the country.

LAFS was no laughing matter. It was an effective system that, unfortunately, was reaching the end of its technical life. As AOUSC was pursuing a new financial management system (FAS4T, described above) for the entire federal judiciary (except for the Supreme Court), the LAFS staff knew that it made more sense to commit to FAS4T than to start developing a new system from scratch. The LAFS technical lead became a member of the FAS4T User Advisory Group and the District became a FAS4T user when that system became available.

RAMER – Reliability, Availability, Maintainability Evaluation Report

RAMER was the first system I supported as a professional programmer. It was built to support Developmental and Operation Testing and Evaluation (DT/OT T&E) of candidate US Marine Corps systems. RAMER was programmed in Hewlett-Packard BASIC using indexed files for data storage (instead of a database management system) and ran on a Hewlett-Packard 9800 series desktop computer system.

I didn’t write RAMER, but I was hired to help maintain it. Though my job title was “Programmer/Analyst”, I was really a maintenance programmer. There’s no better way to learn how to write code professionally than to maintain code written by someone else. It gives you a real appreciation for what makes code maintainable.

When I first joined the project, RAMER was setup to help the Marine Corp evaluate the RAM (reliability, availability, maintainability) of four vehicles competing to be the the High Mobility Multipurpose Wheeled Vehicle, or “HMVEE“, which would replace the M151 quarter ton utility truck.

DT/OT testing involved Marines driving the test vehicles through different scenarios until something broke. They would complete an RAMER incident report describing what broke and how it broke, what action was taken to fix the break, and how much time it took to apply the fix. At the end of DT/OT, the incident reports were entered into the RAMER system. Users could then generate reports detailing the RAM statistics of each vehicle type, including what the weak points, based on the RAMER incident reports. The Marines used this information to help select the candidate vehicle exhibiting the best combination of capability and reliability (RAM).

One thing I learned during these test is what the term “untrained personnel” meant. During one test of an amphibious tracked vehicle, an “untrained personnel” destroyed the transmission by mistakingly shifting into reverse while the vehicle was till moving forward. Turns out the “personnel” was a colonel who shouldn’t have been driving the vehicle in the first place.

There were several different tests RAMER was used on in my two years of working with the system. RAMER wasn’t very flexible, so for each test, I had to go in and tweak the source code. When MSDOS-based personal started to become prevalent (this was back in the early 1980s), my company decided to create a new version of RAMER for the PC.

Since RAMER was developed under a Marine Corps contract, the source code was US government property, so the company couldn’t just modify the code to work under MSDOS and sell it to other customers. The way around it was to setup a completely separate development team that would work develop the MSDOS version of RAMER without involving me. That way, the company could claim whatever it wrote as its own property and sell it to other organizations. If they were successful in this endeavor, it happened after I left the company.

SDWIS Prime – Safe Drinking Water Information System (SDWIS) Primacy Agency

“SDWIS Prime” was the name commonly used for the mouthful of a system name noted in the heading above. Earlier known as “SDWIS NextGen”, “SDWIS Prime” was consistent with the straightforward naming convention used for SDWIS IT systems. For example, SDWIS systems included Fed Rep (Federal Reporting), Fed Data Warehouse, Fed Reporting Services, and Lab (I wish, but it’s CMDP discussed earlier).

Over time, the name “SDWIS Prime” developed a sinister connotation. Several stakeholders related to me about how the name reminded them of a certain giant combat robot character popular with kids that could change into an automobile or a truck. I don’t think people were complaining about the name, but, instead, were expressing a dread that this new system would upend the way they did their work. Fairly typical user reactions when dealing with replacing a legacy system.

As I mentioned earlier, OGWDW pulled the plug on SDWIS Prime about a year after I retired. The reason given was that the SDWIS Prime database structure wasn’t designed properly designed. Management’s position was that it would be more technically and economically advantageous to scrap the project and start over instead of dedicating a couple of sprints to refactoring the database design.

And that’s what happened to SDWIS Prime.

TAPS – Time and Attendance Processing System

The unfortunately named Time and Attendance Reporting System (TAPS) was dead before the project charged with developing it started. Except the Project Management Office at the Federal Deposit Insurance Corporation (FDIC – the agency funding the project) didn’t know it. The idea behind the system wasn’t bad – to automate timesheets entered by FDIC staff and manage leave requests.

The problem was that time and attendance reporting is actually complicated, especially when you add features like leave requests and leave request approvals. Now you have to deal with approval workflows in addition to managing all the various accounting codes used for tracking labor expenses.

Since the only data originating from the time and attendance system is hours worked and leave taken, the system must interface with other systems of record (payroll, accounting, HR, etc.). Setting up these interfaces and processes to synchronize the data between systems adds yet another level of complexity.

Another complication that FDIC faced in developing TAPS was that the system had to be delivered through a web browser. Today, that’s not very complicated, but in 1998, when the TAPS development project was approved, it was a big deal.

At that time (and it may still be), FDIC was almost exclusively a Microsoft shop. Because of that constraint, the contractor (whom I worked for) charged with developing TAPS would have to use all Microsoft products.

In 1998, the year TAPS development launched, client/server architecture was still the rage. Momentum was shifting away from “heavy” client applications (usually native Microsoft windows applications communicating over the network with a server hosting a database management system) to web browser-based applications communicating to one or more web servers across the internet (or internal internet, in the case of TAPS).

But the tools for building these kinds of applications were few and far between and the ones that were available were not very mature. For example, Microsoft developed a messaging middleware component that FDIC specified for TAPS. Unfortunately, this messaging middleware was not ready for prime time; it was “betaware.”

Our developers could never get the messaging middleware to work correctly. Sure, there were other messaging products on the market, but they weren’t made by Microsoft, so using one of those products was out. And getting technical assistance from Microsoft was a lost cause because the messaging middleware was so new that maybe three people in Seattle knew how it worked.

Another nail in the TAPS coffin was that the browser side of the application depended upon a Microsoft Explorer browser technology called “Active-X,” which turned out to be a security nightmare.

So what happened? The FDIC Project Management Office took over TAPS development from the contractor to turn the project around. In a few weeks they realized how difficult it would be to build TAPS, especially using the not ready for primetime Microsoft components. The project was unceremoniously cancelled and most of the development staff laid off.

Did FDIC ever automate their time and attendance processes? I wish I could tell you, but I had moved on from FDIC when I left the contracting company saddled with TAPS and took a position with the Board of Governors of the Federal Reserve System. I would like to believe that cooler heads prevailed and FDIC bought a commercial off the shelf solution from their HR software provider. But that might be giving FDIC too much credit.

Final Thoughts

I’ve always enjoyed the challenge of coming up with a name that accurately describes the purpose of or reason for a system. It’s even better if you can come up with a good name that makes a catchy acronym. When done well, a system name can almost suffice as “elevator pitch” to help communicate and publicize the system to its stakeholders.

Sometimes plain names are good, too. For example, I really liked the naming conventions used for the Safe Drinking Water Information System (SDWIS) suite of IT products. Though rather boring, the names clearly describe the role that each system plays in the SDWIS IT program.

But you don’t want to get too cute. Obviously, a name like “CRAP” isn’t going to fly, but a least is served to lighten the mood and actually helped to bring people together.

One last thing. You may have noticed there is a secondary theme to this article having to do with “modernization”. When modernizing a system, whomever is the ultimate authority (usually the project sponsor) has to clearly state if the effort is to redo the old system and its way of working in new technology or to reengineer system and come up with a new, more efficient and effective way of doing things in new technology. Without that guidance, success is very difficult.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: