This is a true story. And
I was a manager and technical contributor deeply involved in it from beginning to end.
A Federal agency wanted to evolve their claims processing from a
totally paper and mostly manual process one to an automated standardized one. While
there was some automated record keeping such as case tracking, the problems
with the existing capabilities and recordkeeping were many. There were district offices that processed
claims differently, some produced with much better speed and quality than
others. At the high level, neither
headquarters nor anyone else could ascertain the status of a claim without
finding the physical inbox and file folder of whichever claims examiner in whichever district office was responsible for the case. And there was much unjustifiable and legally unsustainable inconsistency in claims decision making. We were hired to analyze the problems and design
and specify an automated system in collaboration with the agency. The specification would be put out for
competitive bid.
Over several years, before everything was moving at ‘internet
speed’, we visited and assessed key district offices, documented and applied
the best practices and methods, noted the best practices that we found and thoroughly analyzed the
policies and procedures manuals, as well as the legislation, regulations and
other internal policies, manuals and memoranda. I don't remember the numbers from back then, but now the program has a nearly $3B budget, and processes millions of
claims each year. It was never a trivial program.
While one of our two teams developed extremely detailed
technical specifications, the other team worked with the government on creating
the other documents that specified the deliverables that would be required from
the winning contractor. In addition to
the request for proposal documents, we developed the specifications for
testing, training, user manuals, maintenance manuals, code documentation and
other technical documents. We specified
literally every document that the government wanted and required.
The governing philosophy was that we would specify ‘everything’
and the contractor would ‘only’ need to provide the hardware and write the
program code following the specifications. And complete all of the required
documentation following the government’s specifications. Behind this philosophy
was the program’s mandate that this effort needed to be a fixed price effort.
This would help protect the program’s funding for the system if the funds were
obligated through a fixed price contract rather than through a
cost-reimbursable type contract. The
contracting office (and others including me) were very resistant due to the
lack of a history of successful fixed price software development projects.
As a condition of approving the overall fixed price approach, the contracting officer mandated that we develop
‘liquidated damages’ (LDs) essentially for every deliverable to protect the
government against non-delivery, and to send the message to the contractor community that fixed price indeed meant FIXED PRICE. It was an attempt to dissuade bidders from
the usual behavior of underbidding then using a change process to earn back revenue. This ‘get well’ strategy was (and is) typical
in government contracting.
The resulting printed notebooks of technical specifications were
in boxes about four feet high and were written in a pseudo code called Program
Design Language (PDL).
Program
Design Language
(or PDL, for short) is a method for designing and documenting methods
and procedures in software. It is related to pseudocode, but unlike pseudocode, it is
written in plain language without any terms that could suggest the use of any
programming language or library. 1
The other specifications for documents were in a few more boxes,
and were closely in alignment with the standards being used by the Department
of Defense at that time. We considered
this a ‘best practice’ of its time.
The Request for Proposal document(s) were written and reviewed
over many months until all issues were resolved between the program managers,
contracts shop, legal folks, and executive leadership. A part of the contract document that received
much ‘design’ and review were the Liquidated Damages section of the RFP. We created a matrix where the rows contained
EVERY deliverable and the columns contained potential compliance faults (e.g.
unacceptable quality; non delivery; late delivery; and other fault scenarios). For each cell we developed legal
language and penalty formulas tied to the value of the deliverable (each of
which was to be priced by the bidders) and a formula for the damage that the
government would sustain if the deliverable was not received in accordance with
the government’s specification and the winning bidder’s proposed schedule.
The RFP was announced and published. All documents made available in a reading
room. Copies provided upon request. Briefing sessions were conducted
with all interested parties. All vendor
community questions were answered in writing.
Adequate time was allotted for vendor responses. Requests for an extension to the proposal due
date were granted.
We tried to limit the government’s risks of cost and ‘scope
creep’ while virtually eliminating the contractor’s unknowns.
1 http://en.wikipedia.org/wiki/Program_Design_Language
Next: Part 2 of 2 - How The Plan Worked Out
No comments:
Post a Comment