Measuring Government Transactions

I have long been a proponent of flattening the federal government, a beast I consider to be overbearing and out of control.

I tend to see it more as an albatross around our necks impeding progress as opposed to expediting and simplifying our lives. I have written on this subject many times in the past, even offering some suggestions on how to flatten it, such as,"Enterprise Engineering the Federal Government," a methodology which compares the logical model of a business to its physical counterpart thereby providing a convenient means to identify overlapping work effort, excessive layers of management, and omissions in delivering work products.

There's another simple benchmark available for scrutinizing government productivity, something actually quite common and easy to use. As my background is in systems, I learned a long time ago one of the key elements in measuring work is in the area of processing transactions. All systems, whether performed manually or with computer assistance involves the processing of transactions. Let me be clear what I mean by this; a transaction is an event between two objects, from one to another, for example, in banking a deposit is a transaction, a withdrawal is a transaction, an inquiry on an account balance is a transaction. A purchase is a transaction; a query is a transaction; printing a document on the computer is a transaction, recording the manufacturing of a widget is a transaction, etc. Everything we do in business and government is based on the processing of transactions, either one at a time (as in an interactive application), or in groups (as in what is referred to as batch processing).

In order to determine the most suitable processing solution, system developers study the amount of time and costs involved with processing a volume of transactions. There may be tradeoffs between the two considerations; whereas a transaction may be processed quickly, it may be costly to do so based on the available manpower and technology at the time. Conversely, slower transaction processing may be less costly. The goal is to find the most cost effective solution, not necessarily what is most technically elegant. To illustrate, payroll is typically produced for groups of employees at one time (batch), as opposed to one employee at a time, primarily because it is more practical and economical to do so.

Let's consider how transaction processing affects the federal government. To do so, I'll use the Internal Revenue Service (IRS) as an example. According to available data on the Internet, the IRS operates with a budget of approximately $11 billion (with over 106,000 employees). Typically the IRS processes a total of 173 million tax returns (representing transactions). When we divide the number of transactions by the IRS operating budget, we arrive at a figure of approximately $63.58/transaction. The question then becomes, is this reasonable or does it suggest inefficiency? If the latter, we should endeavor to ascertain the reason and correct it. I realize this example is a gross simplification of how to calculate transaction processing, but the reader should be able to see what I'm driving at, that the various departments, agencies, and bureaus of the government can be effectively scrutinized simply by examining how they process transactions, which should be rather easy to do I might add.

It would be interesting to see a study of transaction processing of the entire federal government. Corporations do it, why not government? Some say the government is simply too massive to study. Baloney. That's a defeatist attitude. I contend we cannot afford not to do it. Are we afraid what we might find or that we might not have the stomach for correcting it? If you're too squeamish, give me the knife and I'll be glad to perform the surgery.

Keep the Faith!

Copyright © 2011 by Tim Bryce. All rights reserved.