Think big, start small — NOW!
(This story first appeared in FedScoop on February 16)
No one has more customers than government.
Its vital services including public safety, education and health care (to name a few) are relied on by hundreds of millions of people every day. The room for error is zero. Public servants get little in the way of compliments for doing their work well, but can make it to the front page, above the fold, if they make a mistake. As a result, changing a process that works, even if it is inefficient, anachronistic or opaque, is a hard case to make.
Over time, though, cost-pressure, citizen complaints or some sort of process failure can create energy to revisit the status quo. However, once the go-ahead is received, the tendency is to try to fix everything, all at once. This all-in approach is the result of a number of tendencies in government, or any large organization, and poses a number of key risks.
Tendency 1: Thinking Big
Anyone who has worked in government, or any large bureaucratic organization, knows that the acquisition function is convoluted and time-consuming. The difficulty of gaining support for budget and an acquisition approach, as well as the effort of writing up requirements documents and running a solicitation process, cannot be underestimated. Therefore, the tendency is for an agency to gravitate to the biggest, most comprehensive solution, even if there is no product that meets the requirement.
Tendency 2: Customization
Customization is the other tendency which grows both out of the acquisition complexity issue described above and a technology acquisition best practice developed over the last twenty years. This best-practice, known as waterfall development and implementation, is a semi-scientific approach to structuring technology purchasing starting with a highly developed description of requirements. (To understand more about the problems with this approach see the postI co-authored with my former GSA colleague, Greg Godbout.)
1 + 2 = Risks
Combined, these two tendencies drive agencies toward purpose-built, comprehensive systems. Most readers of this post will know that these are the very sorts of systems that generate the spectacular implementation failures that scare administrators away from exploring change unless they absolutely have to. In fact, continued problems with the management of IT acquisitions and operations have led the General Accountability Office to add the category to its High Risk List of Federal programs and activities.
Often it is fear of system development and implementation risk that keeps program managers from pursuing an IT upgrade, replacement or implementation. Once that approach proves untenable, then it is fear of implementation risk that drives a project manager to seek a comprehensive solution, purpose built and managed through a waterfall process.
But these efforts to avert taking risk may instead invite it.
In fact, research over the last five years has shown that an alternative development approach, agile development (and a related one, lean development), can dramatically improve the chances of a successful IT implementation. Agile throws out the highly specified requirements and finely honed (but “precisely wrong”) schedules of the waterfall method and substitutes sprints, user testing and “scrums” to develop, test and tweak a system while it is being built. (That post I mentioned earlier discusses the importance of prioritizing users as well.)
Mitigate Risk — Start Small
Therefore, the best way to reduce risk for the agency and its customers alike is to start small and use agile (and lean) development approaches to build iteratively toward the more comprehensive, final product.
These ideas were driven home for me when, earlier in my career, I was responsible for building complicated, expensive public infrastructure such as bridges and transit facilities for the Washington, D.C., District Department of Transportation. I learned from my engineer colleagues of MacCleamy’s curve — which relates the cost of changing a project to the level of its completion: The further you go, the more expensive it gets. Boehm’s curve describes a similar relationship for software (with some interesting observations by Beck explained here).
Therefore, the best way to tackle a big project is to break it down into smaller pieces that can be seen through in fast, user-tested development sprints. Better still, leverage commercially available products (gratuitous plug: such as SeamlessDocs) to to solve specific component parts of the larger problem, developing and testing interfaces to tie them together — a process dramatically simplified by modern APIs.
Start Now!
The biggest risk is delay. Allowing failing or underperforming systems to remain in place is the biggest risk a program can take. Letting analysis paralysis, appropriations cycles or waterfall methodology slow down progress on systems replacement or update jeopardizes the critical service delivery that customers expect and deserve.
Simple and focused implementations using commercially available products are the smartest and safest way to make big improvements fast, safely and cost-effectively.
