PART 2
The software development and systems integrator community took
interest in the agency’s procurement.
They attended the vendor day briefings, asked questions, reviewed
documents in the reading room, requested copies and otherwise showed interest
in bidding. One of the questions most
often asked had to do with the engineering change proposal process. The government made it clear that they did
not anticipate using a change process due to the limitation of funds on the
program. And made it clear that they understood that it was indeed tradition to
refine specifications during development, but would not add funds to the
contract or approve changes during the development process. The government made
it clear that any changes required would be made AFTER delivery of what was
specified, rather than DURING the development of the deliverable. The government acknowledged that the
conventional wisdom and experience was that catching and fixing logic and other
errors earlier were cheaper than fixing them AFTER completion.
The bidders bid, the proposal evaluation panel selected a winner
and made the announcement. There were no
protests. After award ceremonies and a
little partying on both sides, the government and the contractor held a series
of meetings at the highest levels, to discuss the projects goals, philosophy
and…. No changes! No technical spec
changes, no documentation requirements changes, no changes to the outlines of the
documents, no changes to anything.
The contractor’s team hunkered down in office space in Greenbelt
Maryland and got to work. The government
got office space nearby to cut the time required for meetings, status updates
and questions or issues that the contractor may have. The government was under orders to NEVER
authorize or even suggest that they WOULD authorize any changes to anything.
After a month or so, the contractor’s project manager began
submitting requests for changes. First
it was seemingly small things like changes to the outline of several
documents. Request denied? Then they
found several logic errors or inconsistencies in flows between screens and
processes. They argued that the cost of fixing the problem now would be orders
of magnitude cheaper now, rather than after all was coded. The government said: ‘implement it with that
error, and we’ll deal with it AFTER you delivery everything…with errors. NO CHANGES!
The honeymoon was officially over.
The PM made many other attempts to get the government to
authorize changes. The government
wouldn’t. The government had another
round of high-level meetings with executives, lawyers, contracting officers
from both sides. The PM was replaced,
with apologies from the contractor’s executives.
The contractor acquired and installed hardware and database
management software and other tools into the development facility. That kept the appearance of progress and optimism high.
At some point the contractor started missing key deliverable
dates, and the quality of deliverables slipped.
There were more high-level meetings, more apologies, and another project
manager.
It became clearer that whatever was happening inside the
contractor’s firm was working against the government’s interests, and against
the ability and will of the contractor to meet its contractual obligations. Clearly
their capture strategy was an underbid and ‘getting well’ on requirement
modifications. Memory tells me that they went through three or four project
managers before all was said and done.
I don’t remember exactly what event triggered the government’s
decision to terminate the contract, but the only remaining decision was to
terminate for default or to terminate for the convenience of the
government. The government’s project
office kept great records that could have supported a strong legal default
process (where the government could recover monies paid). But the decision from
the government’s legal shop was that they didn’t have the horsepower to engage
in a legal battle with the contractor. So the legal office pushed the program
to terminate the contract ‘for convenience’ (where the government would neither
recover monies paid nor seek money damages).
The deal that was eventually negotiated is that the government
took ownership of the hardware and some of the commercial software products, and the contractor
walked away with whatever revenue they had been paid in the form of progress/deliverables
payments.
The hardware was given to another program in the agency and the
program began a new attempt at a much more modest effort to automate using
internal IT staff. While the government
learned much about the inner workings of its program through the years of
analysis and design that it could leverage in it’s ongoing modernization
effort. This effort was a huge failure.
Years later, one of our team met one of the contractor’s deputy
project managers. He told the story of
how the legal department had advised the cognizant VP that the contract terms
and conditions were too tight and risky to bid on. And advised a no-bid. The VP decided to ignore that advice.
It is hard to imagine a more diligent government effort at
attempting a fixed price IT contract, and a contractors equally diligent effort
at attempting to weaken the terms and conditions of the contract to which they
were legally bound. But it is standard fare
for contractors to exploit or create weaknesses in contracts. In this case they didn’t succeed. Nor did the government get a system.
For most people, I guess this ONE program, ONE contractor, ONE
set of circumstances isn’t proof of anything about the viability of fixed price
contracting for IT solutions. But I think that it was a perfect experiment that
showed that the contracting community has problems of its own. These problems and practices do not get
enough exposure and discussion. If they
did, the dialog about ‘fixing’ federal IT contracting would be more analytical
about the IT contractor side of the federal-private sector equation. While governments' failures receive much public exposure, the failures of some of the best in the business receive very little exposure (or quickly fade).
More on comparing government IT failures to private IT failures in a future post.
EPILOG: The contractor
was Martin Marietta Data Systems (MMDS), which no longer exists as far as I can
tell. At the time they had a good reputation (so it wasn’t just some little
inexperienced company, it was part of a very large corporation). Looking at
public records now, it seems that it’s parent company was involved in defending
against a hostile takeover during the time of this effort.
It is not clear to me how independent the MMDS business unit was
from the other MM entities, or how, or if they were effected by the takeover
activities. But even when the government chooses a reputable firm, nothing
guarantees against negative effects of internal corporate issues, incentives,
and bad decisions.
Please post comments and ideas on this topic.
No comments:
Post a Comment