As a result of some mix-ups involving vacations, edits and deletions, my column on governmentwide acquisition contracts (GWACs) ["The Mayflower revisited," June 14] was unclear and, more importantly, diluted the message I wanted to convey. Federal Computer Week's editors suggested I expand on my views on this very important issue.
Festering problems with task orders awarded under GWACs have gotten increased attention due to controversies over Iraq contracting and problems shown in an Acquisition Solutions Inc. report on the General Services Administration's Federal Technology Service contracting. As a result, GWACs are under threat in provisions of the Defense Authorization bill.
It would be a shame for the government if GWACs disappeared. As I noted in my original column, GWACs have allowed information technology contracts to be awarded much faster. But that isn't their only advantage. The ease of entering into and breaking relationships with vendors is part of the reason for increased performance pressures on contractors, which have produced a dramatic increase in government customer satisfaction with IT vendors' performance. During the late 1980s, I found that the average satisfaction of government customers with vendor performance on their most recent major contracts was 6.9 on a scale of l to l0. Recent research by two of my Harvard students showed an average satisfaction of 9.4 with vendor performance on GSA IT services orders.
The ease of getting into contracts also promotes modular approaches to systems development, which is good.
In addition, it is good for government that customers have the option of using GWAC contracting officers to award contracts as an alternative to their own contracting shop. Partly, GWACs provide a cost-effective "surge capacity" for organizations with variable contracting needs, so they don't need to staff contracting shops at the higher level required to meet maximum needs. Competition from GWACs is also crucial because it keeps in-house contracting shops oriented toward program customers. Failure to be responsive can cause customers to go
At the same time, the customer orientation that is part of the virtue of GWACs also has been their bane in situations in which program managers want things that are not good from the government's long-term point of view, such as the noncompetitive or out-of-contract-scope orders that have come under scrutiny.
I say the "government's long-term point of view" consciously. We should not demonize program customers. Their choices have generally been due to a view -- typically based on good past performance -- that a particular vendor is very likely to meet their needs well, while the competitive process introduces more uncertainty about whether a good vendor will be selected and reduces the urgency to meet mission needs quickly.
That's why we need an enforcement of basic rules. Competition among contracting shops is good, but there must be constraints on what one is not allowed to do while competing. When I urged a Mayflower Compact in 1997, post-communist experiences in Russia were on my mind. Without rules about what competitors were not allowed to do, the competitive marketplace in post-communist Russia had been characterized by theft and corruption -- phenomena far more unsavory than problems with GWACs.
But these problems did not mean Russia should have returned to communism. They only suggested a need for constraints to establish the boundaries in which competition could occur. That lesson applies to what we should be doing with GWACs today.
Editor's note: Find a link to an unedited version of Kelman's June 14 column on the FCW.com Download's Data Call at www.fcw.com/download.
Sizing up coded message options
Your June 21 article "Sizing up coded message options" is useful in describing the value of securing e-mail, but the solutions discussed break many company/organization policies for antivirus, spam and document retention. There are far better solutions than Pretty Good Privacy, Secure Multipurpose Internet Mail Extensions and Secure Sockets Layer.