Despite what you’ve heard on the news about the federal debt, many federal, state, and local government agency budgets have been flat or declining for several years. Add in inflation and other cost increases, and these agencies are constantly being asked to do more with less. For the IT departments, this surely means they’ve made the transition to lean, mean, Agile teams, right? Well, no. But there are some good reasons for that.
Responsible Spending and Risk-Aversion
Government organizations usually have budgets that are determined by politicians and other actors outside the agency itself. Unlike companies that can expand budgets through increased revenue and profitability, government agencies need to justify budget requests by showing they have a responsible track record deploying their budget to meet their mission.
Tax payers don’t want the government making reckless decisions with their money. As a result, government organizations routinely make decisions that can be justified as responsible, risk-averse, or “safe” – even if those decisions are not the most efficient or cost-effective. I’ve heard it said that nobody has ever fired a government employee for using Microsoft Project on an IT initiative. In an environment like that, a half-century old methodology like Waterfall – or a century old tool like Gantt charts – would be seen as preferable to newer methodologies that are not well understood to business or political stakeholders.
Delivery Dates vs. Sprint Cycles
Government IT solutions and systems are often the result of new laws or regulations, and have a defined time period in which they must be implemented after the new law is passed. Just like the adage, “requirements may be vague, but the software will be specific,” laws may be vague, but the regulations must be specific, and the software that implements them must be even more specific. Elements like complex business logic and multiple system interfaces cause managers and business stakeholders to ask for lots of documentation to prove that the system was built correctly.
When a new law mandates implementation by a specific date it creates an anchoring effect, that the system needs to be “done” by that date. Briefing senior government officials or even legislators on sprint velocity and burn rates is a much bigger challenge than providing dates and percentages. Even if, in the end, delivering the most valuable 80% of a solution on time should be preferable to delivering 100% of a system after a 1-2 year delay.
Software and Tools
Another reason no one in government ever got in trouble for managing an IT project with Microsoft Project is because it is already on the list of pre-approved software for use that nearly every agency maintains, in one form or another. Hardware and infrastructure requirements are a common consideration, as are licensing costs. But security concerns are an increasingly big reason why software on pre-approved lists keeps getting used instead of newer or better products being adopted.
Getting software tools approved for use at a federal agency means completing a thick stack of paperwork. It also requires a champion to spearhead the process, work with Help Desks on administration and conducting training. This means longer-term commitments to tools than in the private sector, and that larger companies with established products get used more often.
End User vs. Customer
Until recently, most end users of government IT systems were employees of that agency, so there was little conflict in seeing the end-user as an internal customer. As the internet has proliferated, more businesses and individuals are interacting directly with government IT systems: submitting applications and appeals, self-registering or updating information, or just searching for general information on a government website or portal. These external end users, or government customers, present a unique tension when designing systems for them.
While “the customer is always right” is a great motto for many private businesses, government agencies need to walk a fine line with that approach. They run the risk being too accommodating or “too cozy” with the people and businesses they regulate, and can erode trust that the government agency can regulate or monitor effectively.
Tight budgets, pre-defined timelines, and the need for some agencies to keep end users at arm’s length make it easy to de-emphasize agile principles like personas, end user demos, and usability sessions.
Contributing Author
David Pradko is a project manager and certified business analyst, who has worked with over a dozen government agencies to design and implement IT solutions. He as also appeared at the IIBADC’s Business Analysis Development Day and on Federal Tech Talk radio to discuss Agile in the federal government.
You can follow David on Twitter at @DPradko
[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]
