Tag Archives: government

Who’s overseeing the overseers?

The government provides oversight over projects and programs. Interestingly, this oversight often happens outside of the normal reporting structure of the government agencies. It is considered important for these overseers to be independent – not part of the organization that is sponsoring or administering the project. While this allows for some objectivity, it also means that the overseers have little “skin in the game” – they do not have to live with the consequences of their decisions. The team running the program does.

Now suppose – this is theoretical, of course, and would never happen in any situation I am familiar with, ahem – suppose that the oversight body imposed substantial burdens on the programs it oversaw. Suppose that it demanded extensive documentation that no one ever read, nit-picked on the format of the documentation, imposed supposed “best practices” that were not actually best practices, and frequently asked for data or status updates that distracted those managing the program. Suppose further that the overseers themselves were not always efficient; held up the programs while they tried to schedule review meetings, gave the programs contradictory direction, and argued amongst themselves or prepared inadequately for review meetings. The problem could be exacerbated if the overseers did not themselves have the experience of running programs, and therefore their understanding of best practices was at best theoretical, at worst superstitious.

If that – ahem – ever happened, then given the power oversight bodies have, they would essentially be ordering the programs to waste money. They might also add risk to programs. Since the job of the oversight body is ostensibly the opposite – to prevent waste and mismanagement – this could be a critical issue. What controls are in place to prevent this? Is the oversight body perhaps incentivized to make “corrections” to the programs to demonstrate its own usefulness?

Because the oversight bodies are not “inline” with the management structure over the program, they have no obligation to cultivate the program team as employees. They do not need to encourage program staff, deal with any issues of demoralization, provide positive feedback, make a comfortable work environment that will attract more great performers into program management. Oversight in such an environment runs the danger of focusing on negativity and control, rather than on successful execution.

How can we improve this? Oversight bodies must be measured by the success of the programs they oversee, not by their willingness to cancel failing programs. They must be composed of people who are experts – not in overseeing programs, but in executing them. They must work to optimize their processes and to minimize the waste they add to programs, and must solicit feedback from programs to understand what waste they are causing. What I am saying is that oversight must create value for programs, and only the programs can judge whether they do.

Paper Parity and Digital Services

The government needs to give up on the idea of parity between paper forms and electronic forms. This one concept alone is holding back Digital Services and public-centric offerings more than any other.

As I mentioned in my last post, The Government Paperwork Elimination Act (GPEA) of 1998 tried to establish electronic interactions as equivalent to paper. In 1998, this might have been forward-leaning, but in 2015 it just doesn’t go far enough. Because much of government policy has been based around paper forms, it requires a creative leap of the imagination to treat electronic forms and online interactions as something different and better. But the two channels have a major difference: electronic forms can be interactive, while paper forms can never be. Interactivity requires different ways of thinking. Instead, much of our government process, including the implementation of the Paperwork Reduction Act (PRA), effectively forces us to dispense with any interactivity, for the specious reason that it would make electronic interaction different from paper.

Let me give a few illustrations of how channel parity holds us back from what is considered normal customer service. Online forms generally validate user input as it is entered – they check for mistakes that would result in denied applications and database integrity issues. But validation is something that paper cannot do – the public can submit paper applications that have silly errors in them. So “parity thinking” requires that we allow them to make the same mistakes electronically. In fact, we could often go further than simple validation – if the user is applying for something that they are patently unqualified for, our online form could in some cases let them know immediately and save them the trouble and cost of applying. But paper applications do not do this, so it is disallowed or frowned upon.

There are cases where we could help the applicant fill out an application by providing data that we already know or can look up for them. For example, if they are applying to replace a green card, we could look up the information from their previous card, ask what has changed, ask for proof of those changes, and produce the card. Instead, we have them enter from scratch much of the information on the card, as they would on paper, then check to see if it matches what we already know.

I understand that there are legal and policy issues involved here. I’m just suggesting that those reflect an old way of thinking that no longer aligns with a world that has changed. We should be looking for ways to change those laws and policies. Perhaps a “Government Interactivity Preference Act”?

The legacy system modernization trap

Government agencies have often failed at efforts to modernize their legacy systems. Even when the effort is not labeled a failure, it is expensive, time-consuming, and risky. There is a good reason for this: we should not be doing legacy system modernization projects at all.

Why not? To begin with, “modernization” is not a business goal. It does not in itself represent a business outcome that adds value to the enterprise. As a result, its scope of activities can never be clear, the business cannot feel a sense of urgency (and as a result wants to hold off releasing until the system is perfect), and good prioritization and trade-off decisions cannot be made. It is a project that is all risk and no return: there is already a functioning system, so the agency is only risking failure. A modernization effort can never end, since being up-to-date is a goal that slips away as we approach it.

Legacy modernization also does not lend itself to an agile approach – that immediately should be a give-away that something is wrong. We cannot release the modernized product incrementally, beginning with a minimally viable product, because the business will not want to use something that does not at least match the functionality of the legacy system. This means that the scope of the first release is fixed and cannot be adjusted to fit within a time box. The legacy system must be replaced in a single release.

Yet there is a way to modernize a system. The first goal should be to bring contemporary technical practices to bear on the legacy system as is. And the first step in doing that is to bring the legacy system under automated test. A wonderful reference on doing so is Working Effectively with Legacy Code by Michael Feathers. Once the system is under automated test, regressions can be avoided and the code can be restructured and refactored at will. The second step is to re-architect (as little as possible) to make re-engineering pieces of the system efficient. In many cases this will involve creating elements of a service-oriented architecture – or at least finding ways to loosely couple different pieces of the system.

Now to the real point of the exercise. We need to work from real business needs – capabilities that the system does not have. For each capability we change the system to deliver it. We do so in an agile way, and we use our automated tests to feel comfortable that we are not breaking anything. Over time, the system becomes easier to change as components are replaced by more “modern” components. But we never do anything without a good business reason to do so.

In other words, we’ve modernized our system without doing any such thing.

Government as a low-trust environment

The US government is, deliberately and structurally, a low trust environment. Think about why we have a “system of checks and balances.” We have proudly created a government structure that is self-correcting and that incarnates our distrust of each branch of the government. Why is freedom of the press such an important value to us? Because we all want transparency into the government’s actions – not to celebrate its fine management practices, but to know when it is doing something wrong. Within the government, we have Inspectors General to investigate misbehavior, Ombudsmen to make sure we are serving the public, and a Government Accountability Office. To work in the government is to work in an environment where people are watching to make sure you do the right thing. It is a culture of mistrust.

That sounds horrible, and from the standpoint of classic agile software development thinking, it is unworkable. But take a step back – don’t we sort of like this about the government? “Distrust” has unpleasant connotations, but as a systematic way of setting up a government, there is a lot to be said for it. It is another way of saying that the government is accountable to the people. You could almost say – you might want to hold on to your chairs here, agile thinkers – that mistrust is actually a value in the government context. So where does that leave us if agile thinking wants us to deliver as much value as possible, but believes that agile approaches require trust?

It might sound academic, but I think solving this dilemma is critical to finding ways to bring agile thinking into the federal government. A typical IT project experiences this structural distrust over and over: in the reams of documentation it is required to produce, in the layers of oversight and reviews it must face, and in the constraints imposed on it.

I will argue that even in a low trust environment, agile approaches are still the best way to deliver IT systems. And that certain tools – borrowed primarily from DevOps – actually help us resolve the dilemma. Waterfall approaches fit well with mistrustful environments by holding out the promise of accountability and control – but they just don’t work. So how can we bring agile, lean, team-based processes into an environment that is structurally mistrustful, and realize our goal of a lean bureaucracy?

Optimize the whole

Let’s talk about how to reduce government IT cycle times (mission need to deployed capability). As the Lean principle urges, we need to “optimize the whole.” The “whole” in this case goes well beyond system development. We can implement Continuous Delivery practices but if we don’t address the other parts of the value chain, our impact will be tiny. And we’re shooting for a big impact, right?

To go from mission need to deployed capability, here are some of the steps we may need to pass through: gathering requirements into a monolithic “program,” documenting the program and its plan, satisfying oversight bodies, securing funding, executing one or more procurements (typically for development services, hardware, and software), onboarding contractors, developing and testing the product, having it retested by independent verification and validation (IV&V) partners, configuring production hardware and networks, receiving an Authority to Operate (ATO – verification that it is secure enough to release), passing it through a change control board, and deploying the system.

I’ve probably missed a few things here. But a few things should be clear. First, the “value add” development part is tiny compared to the whole (both in time and cost). Second, there are many opportunities for leaning out the process, even if we still need to execute each of these steps. Third – and most subtly – there are real “business” needs, in the government context, driving each of these steps. We really do need to ensure that the system meets FISMA security requirements. We really do need to secure funding through an appropriations process. And so on.

So the question for me is: how can we meet these “business needs” of the government through the leanest possible process?