<- previous index next ->
Lessons Learned from a recent Government procurement.
This is not the first government or industry software
procurement to have problems, and, it will not be the last.
You students can help prevent this in the future.
The dismal track record of the implementation of large-scale
information technology initiatives even in rigorous and focused
corporate environments points up their difficulty. Unexpected obstacles
arise, deadlines are missed and budgets are overrun. Maximizing the
prospect of success requires providing for slack in the schedule and the
budget, structuring projects with clear accountabilities and frequent
checkpoints, and assigning oversight responsibility to people with
extensive information technology experience rather than general managers
who have programmatic commitments. Success also requires some
trusting but more verifying. A homeowner who hires a general contractor
to build an addition, discusses the project and then goes away for six
months probably would be unhappy with the result. The same is true for
public managers who hire contractors to perform essential tasks but fail
to rigorously oversee every step.
Another requisite for success is steadiness and realism in the
face of difficulty. Once a project gets off track, there is an
overwhelming temptation for everyone involved to circle the wagons and
promise rapid repair so as to hold critics at bay. Yet the right
response to failure is to surface problems as rapidly as possible and to
move more deliberately and carefully, not more quickly. In football,
the best teams stick to their playbooks even when they fall behind. When
one has fallen behind on a project, it is important to mobilize new
resources and management but not to overpromise with respect to how soon
and how good a fix is possible. One instance of over-optimism will
ultimately be forgotten or forgiven. Repeated over-optimism should not
and will not be excused.
These are old truths that those responsible for implementing
ACA should have heeded. Yet fairness requires recognizing the
equally important, and in some ways more fundamental, factor behind the
problems implementing any government project, there may be
many individuals and elected officials against the project.
Large-scale information technology projects in the private
sector are hard enough without an organized constituency for failure.
It is no exaggeration to say that the failure of ACA has been the
prophecy and the hope of many of those responsible for funding
implementation of the ACA, confirming the appointments of those
who will do the job and overseeing the results. They have been
eager to seize on any problems and highlight any controversial
judgments. All serve to create an environment in which failure
becomes the expectation.
The formal process should be:
1) Government or company puts out a Request For Proposal, RFP.
This document covers the information we provided in our
Software Requirements Specification, SRS.
2) Contractors respond to the RFP with a proposal.
This document covers the information we provided in our
Software Design Document, SDD, plus a detailed schedule,
resume of people who will work on the job, detailed
cost estimate and total cost.
3) The Government evaluates the competing proposals,
it is poor choice of Government to allow a sole source bidder,
and selects the proposal that best meets the government
needs at the lowest price. Past history of the bidders
is taken into account. Bidders that have missed schedules
or had cost overruns get those factors added to their
proposed numbers for evaluation purposes.
4) The Government selects a proposal, writes a contract,
possibly with some changes in their RFP and the
proposal. The contractor may accept the contract or
negotiate changes in technical, schedule, cost, etc.
5) Upon receiving a signed contract, both parties stay
in contact. There may be informal and formal meetings.
Formal meetings typically start with a Preliminary
Design review, PDR. Then a final Design Review, DR.
6) Then progress reports and possible demonstrations.
A formal Test Requirements Review, TRR, takes place.
The last meeting would be the formal Acceptance Test,
AT, observation and evaluation.
7) Hopefully, product accepted and contractor paid.
Along the way, there is talk of changes by both
government and contractor. Changes are supposed to
be made official be a contract modification that
might schedule change and price change.
There is typically a fixed limit, in the law,
for how much the money can be spent.
For today's lesson:
March 23, 2010 ACA was signed into law.
Good points:
Coverage for children with pre-existing conditions
Coverage for children under 26
No lifetime limits on coverage
No arbitrary cancellations
Right to appeal health plan decisions
Consumer Assistance Program (included web pages)
Small business tax credit
Temporary coverage for people with pre-existing conditions
Community health centers
But, as usual, the law allowed government agencies,
not elected officials, to write "regulations" that
have the force of laws.
e.g. "You could keep your present insurance."
Until the regulations added "unless there was any
change to the policy after March 23, 2010, and
only if your current policy met the new regulation
guidelines."
As of 2013, about 1,000,000 policies have been
canceled.
It is common for a new law to take six months or so
to have a competitive RFP for contractor supplied
services, like web sites, application software, etc.
It is considered good efficient government to have
a contract signed within a year. Two years is not
unusual. Thus the ACA web site contract might have
started in March 2012.
Now Politics can play a roll in awarding contracts.
The most common ploy to avoid competitive bids, is
to just delay. Then, when the government can claim
the contract is time critical, they can issue a
sole-source contract to some company the Politicians
want to do the contract. 2013 award for ACA.
Thus, just another added to lessons already learned.
Homework 6 assigned
<- previous index next ->