Comparing Federal IT Systems against Commercial Systems: JUST STOP IT!

Every week or so some pundit, politician, or professional writes an article about how the Federal government ought to acquire IT products or services like private industry does.  I believe that idea to be niaeve and irrational. It betrays these folks’ ignorance at best, or political and business motives at worst. There are too many differences between the private versus public purposes, environments and challenges to enumerate, but I’ll discuss some of them below.   

But first, these folks make the false assumption that private industry is more successful at IT projects than are the Feds.  One needs only to read the Standish Group’s annual Chaos Report http://www.csus.edu/indiv/v/veli...
It reports on IT project failure rates and problems in both the private and public sector.  But even this excellent source is dependent on the private sector to volunteer information about their failures.  The press, public and Congress don’t know how many private sector IT projects get strangled quietly in the crib, or buried without a eulogy.  No one knows how many private projects are late, over budget, under functioning or otherwise not meeting the original plan.  So these pundit types need to just stop blindly believing the propaganda and puffery from those who seek to profit from selling IT system development services to Federal agencies. The media pundits need to look for evidence supporting the claims of the ‘private-is-better’ notion.

But let’s explore that ‘private-is-better’ wonderland a bit.  Let’s assume that private industry develops their IT systems better, faster, cheaper than the Feds develop theirs.  What are these systems doing? I hear politicians mention what they apparently believe are comparable systems…. Google; Amazon; Facebook; iTunes; or … which ever.   ‘If Amazon can get your stuff to you in a few days, why can’t Obamacare let you ……blah..blah..’ 

Compared to the functions most Federal IT systems need to perform, these commercial transactions are trivial.  Not that they don’t perform their functions extraordinarily well, but they’re just trivial.  Most of their public-facing transactions are no more than some combination of: 
1.   sign in or sign up 
2.   browse or search
3.   choose from what’s listed
4.   type in a sentence or two (maybe)
5.   give credit card & address (maybe);
6.   Click DONE!  

They don’t really care who or where you REALLY are …… only that the credit card is good and a password/email pair is valid.  

If the ‘private-is-better’ crowd intends to compare private company internal IT systems (finance, HR, accounting, sales or other business functions) these systems are also trivial in comparison to the realities of (Federal) government systems.  Their systems can be built or rebuilt according to the company’s current needs and carry over whatever legacy functions they need to.  In other words, the company can redefine what it needs, jettison what it doesn’t and buy or build what they need. They can follow whatever ‘standards’ they desire (or none).  They can be as careful in handling data and security or as loose as they dare.  They can also roll out these functions at whatever pace is appropriate.  Of course they do, or don’t do these things at their own risk and peril.

In the (Federal) government sphere, agencies and program managers (PMs) have no such ‘freedoms’.  They operate under a totally different set of business rules, mostly driven by Congressionally developed and Presidentially signed legislation and the subsequent translation of the legislation into regulations and procedures… only after the public and commercial entities and lobbiests have provided their input and commentary.  

The agency PMs also operate under procurement rules wherein they can’t just PICK a contractor that the agency likes and trusts. There is a formal public process that governs advertising, specifying the need and giving the marketplace an opportunity to compete to fulfill the requirements.

Even though there are government regulations that constrain some private activities (e.g. various disclosure documents for publicly traded companies). Most private companies building systems do not have congressional actions that impinge on their technical direction and approach, nor do they typically have an unstable set of new/changing executive appointees to contend with.  Nor do they have complex rules and regulations created out of the legislative, rulemaking, legal and public input processes.

In most non-trivial transactions with the Federal government, there are many issues that private sector systems do not address, except in a limited way.  Using Social Security or Medicare or some other claims processing or tax system as a point of illustrating the unique complexities of government systems it becomes obvious that these systems are much more logic and data-centric, pulling from many different sources across organizational boundaries.  A sampling of the issues that the Fed IT world worries about that the private sector typically don’t ---are issues such as:
·      Are you who you say you are? - and how does the agency establish and verify that electronic identity with extremely high accuracy.  Or even when doing a transaction in person, depending on the size and nature of the transaction, great lengths are taken to ensure accuracy of government-known information compared to the in-person representations
·      If you are conducting a transaction for someone else, what is your relationship and legal authority to do so?
·      If you are applying for some kind of disability benefit, you need to provide medical, financial, educational, work history, and other evidence to enable the government to determine your eligibility for a benefit.  And …the government needs to be able to receive, track, validate and associate all of this information with a specific “case”/individual.
·      If you are applying for some kind of educational benefit, you need to supply statements and data about yours and your parents’ financial condition, history and income.

I’m not saying that private sector companies do not have sophisticated, complex systems.  What I’m saying is that those that do, are able to do their business OUT of the public eye (so we don’t know how successful they are), and those that don’t have sophisticated systems… even the ‘trivial’ retail systems have ties to inventory, accounting, buying and delivery systems…. But they are not typically operating across organizational boundaries.  Verizon has still not consolidated their various billing and account systems across ex-NyNEX and all of their acquisitions and business unit consolidations – and they are a ~$24 Billion enterprise  ($21B-wireless $3B-wireline revenue).

So the pundits, pols, prevaracators, just need to examine the reality of Federal IT systems…. And just STOP THE SILLY, ILL-INFORMED, HEADLINE-GRABBING RHETORIC.

Fixed Price Contracting for a Total System: An Attempt – Part I of 2 - Executing The Government’s Plan.

In the aftermath of the 'Obamacare' rollout problems, there has been renewed talk of using fixed price contracting as a solution to some of the Federal IT community's contracting woes. " Why can't the government just specify what they need, then let the contractor just build it without interference"?  "The government just needs to get out of the way of the experts".  Here's what happened when we tried it.

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. ¹

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.

¹ http://en.wikipedia.org/wiki/Program_Design_Language

Next: Part 2 of 2 - How The Plan Worked Out