ShadowGeek

Rich Jones posted a wonderful piece on gun.io on this horrible mobile application that the Occupational Safety and Health Administration (OSHA) created.  He estimated that he could have done it for about $600, so he submitted a Freedom of Information Act (FOIA) request to find out how much this piece of crap cost for the Taxpayers.  In total, the Android App, IOS App, and the Blackberry App (which was never released) cost slightly over $200,000.  That’s right, a $600 app for $200, 000.  On top of the $200,000 for the applications, the source code isn’t publicly available as it is considered a trade secret by the contractor Eastern Research Group.

Rich goes on asking how this could happen.  Well, I don’t have any inside information on how OSHA did this application but I can hypothesize how this happened.  Rich goes on how he’d like the system to work, and I applaud him for that vision.  Now, let me work through the likely steps that resulted in this piece of crap.

1. Somewhere near the top of OSHA a Senior Executive Service (SES) manager decided that OSHA “needed an App”.  Everyone in Government is doing Apps, and OSHA is not going to let everyone have one but themselves.
2. The poor manager assigned to this task has no technical or coding background.  He or She is a mid-level manager, just trying to put food on the table.  When he asks the Boss “What do you want the App to do?”, the answer is something like “I don’t care, just make an App and leave me alone about it.”  Here’s the first major problem… there is no actual reason for the App, and no one has thought this through.
3. The manager must now write a Request for Proposal (RFP) for the development of the App.  This process takes about six months if you are lucky, and you must go through multiple legal and contracting reviews.  Any creativity or vision will be stripped out of the RFP as too risky or unusual.  The RFP will have language such as “The Contractor shall produce an App that provides users information about OSHA”.  There won’t be any mock-ups, diagrams, or use-cases… it is all just words.
4. The RFP will be a Firm Fixed Price (FFP) contract which allows the Government from taking any risk, or requiring constant management of the contract to ensure that everything is going according to plan.  A FFP contract means that the Government provides the contractor (ERG in this case) a flat fee for the App.  If it costs ERG $600 to make the App, then the rest is profit.
5. The RFP “goes out on the street” for proposal.  The Government waits for about thirty or sixty days for responses.  Contractors will write a proposal and the proposal that is “technically acceptable, lowest costs” wins.  Now, there are two poison pills for new and smaller companies.  The first is that they are judged on “past performance”.  So, if you don’t have any, it counts against you.  In reality no past performance equals a neutral score, but you can’t take biases out of the people reviewing the proposals.  Secondly, the RFP contains a lot of boiler-plate requirements which are very costly to satisfy.  Only companies that have made it their business to get Government contracts get Government contracts.  It is just too difficult for others to break into the business, but occasionally it does happen.  Most often a company will leverage one type of contract for another.  So, if a company runs an IT Help Desk, they will suddenly consider them a software development house, with the often predicted bad results.
6. The contractor will take as much time to do the work as possible, even if they aren’t really working on it.  For  a FFP contract, you don’t want to deliver too early.  That would give the Government the chance to complain and force changes.  But if you wait until just before the end of the “period of performance”, there isn’t enough time for the Government to react, so they just accept what was delivered.
7. Finally, but the time the App is actually delivered the SES has moved on to another job, and the new SES’s response is “we have an App, why?, okay… might as well publish it”.

There you go, from poorly defined requirements to a somewhat functional App.  This is not how it can happen, but this is how the system is designed to work.  It could be redesigned and changed, but that requires an act of congress, and they haven’t really demonstrated their capabilities to pass well thought out and written laws lately.

Rich also goes into the inability to gain the source code.  The default data rights for such a contract are Government Purpose Rights (GPR).  GPR is kind of like open source, but only within Government channels.  This assumes there the mid-level manager understands something about data rights.  If not, the contractors will likely try to slip in even more restrictive data rights in their proposals.  If the manager is a rebel, they could push for “unlimited rights” which would all OSHA to release the code, but that really takes a lot of effort, and assumes that one of these companies is even willing to accept that contract clause.

Rich makes some good points in his rant.  Unfortunately, the established government contracting process has been established to maximize profit while minimizing productivity.  In many ways it is a works program.  Now, I’m sure that isn’t the true stated purpose of it, but is how it ends up.  I would like to see the system change, but I’m not sure writing my congressman will help in this case.