3 Good Ideas From Government Software Projects

If you’ve read any of my articles, you know that the agile practices I advocate are rarely even tried in government projects. How can the guys who popularized the Gantt Chart and the PERT diagram help modern software projects? Oh, and don’t forget the folks behind Healthcare.gov.

Well, as somebody smarter than me once said, “Wisdom is the ability to learn from people who are dumber than you.” Here, then, are three software developments we can learn from the government.

Use Sunset Laws

The good government crowd advocates the automatic expiration of laws, particularly for civil and regulatory matters for which standards change over time. Without a sunset provision, inappropriate laws can only be removed via either an act of Congress or a Supreme Court decision. That’s why local, state and federal law books are full of stuff that’s obsolete and even silly.

The same thing happens in IT with nonperishable business rules and requirements lists. In any serious system rework, the good business analyst will find scads of business processes that are bloated, over-specified and designed to handle a situation that almost never occurs. These four-sigma events are better handled manually; automation will likely introduce more problems than it solves. A study by the Standish Group analyzing mainframe conversion projects nicely documented this phenomenon. Guess what? Ninety percent of the function points in the old code were no longer needed at all.

[ Research: Why Software Builds Fail ]

The lesson: For any significant software requirement, enforce an automatic expiration date that forces the users (or other enforcers) to start from scratch and re-justify the need. This is important because the only free lunch in software is avoiding the implementation of fake requirements.

If You Can’t Write a Test, It’s Not a Requirement

This lesson combines ideas that the Air Force Systems Command used (and may still use) to avoid wild-goose-chase requirements. In a waterfall world, it’s common to see expansive documents that are supposed to specify every detail of the deliverable module or system.

In these tomes, though, it’s easy for the authors to get lost in the writing and be blinded to ambiguities or even outright contradictions in the requirements. Forcing the requirements process to specify the exact conditions that constitute acceptability will reveal these problems.

Taken to the extreme, this discipline means that no executable code will be written until the test code is written and validated. This is practically the definition of the test-first or test-driven development method of extreme programming, but it can be applied equally to agile and the waterfall projects where it originated.

[ Related: How the FBI Proves Agile Works for Government Agencies ]

If you follow this lesson throughout the project, there’s essentially no purpose for a user acceptance test, as it’s really just a demo or training session. If the users weren’t willing to put the energy into specifying the tests that constitute acceptable behavior, they don’t get to veto things at the end of the project. (Of course, this assumes consistency and long-term memory that may be beyond the reach of your organization’s politics.)

If You Insist on Fixed Price, You’ve Got to Pay the Price

CFOs and waterfall enthusiasts just love fixed price projects. They’re easy to manage; all you do is write the checks and check the boxes as deliverables cross the UAT finish line.

In software, particularly when upgrading existing CRM systems, there’s a rat’s nest of costly unknowns: The details of business process, the data quality in existing stores, the existing bugs in executable and integration code and even the functional acceptance criteria. Any vendor willing to submit a fixed-price bid without a hugely detailed requirements document is either a fool or thinks he can issue endless change orders to cover the “unknown unknowns.”

[ More: Why CRM Financial Analysis Always Fails ]

There’s no question that it’s possible to create a sufficiently detailed requirements document to support a true fixed-price project. But are you willing to put in all that effort before accepting the project bids? Then the ultimate question stares you in the face: “How long will that requirements document stay accurate?” In the immortal words of Clint Eastwood’s Dirty Harry, “Do you feel lucky?”

The price for fixed-price projects is either a lot of homework on your part or a discovery project that you conduct with the integrator of your choice. In big government software projects, the time spent documenting requirements and justifying budgets may exceed the time involved spent delivering the project.

You won’t be surprised to hear me say that Agile avoids this problem by short-circuiting the “monolithic spec process.” The single, monolithic project is redefined as a series of small projects, each with its own mini-discovery. Before discovery is even over, prototyping begins. Within weeks the functionality is delivered. The requirements document is never really written, because it’s been embodied in the as-built project docs and system tests.