Tag Archives: government IT

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.

Cancel Successful Projects, Not Failing Ones

Government oversight bodies take great pride in canceling failing projects. They consider it a measure of success. What are oversight bodies for? Eliminating wasteful investments, of course. At first glance this might seem to be consistent with an agile mindset. Among the advantages of an agile approach are the transparency given to stakeholders and the ability to manage risk by working in increments. Only the current increment is at risk, since the project can be stopped before the next increment begins. Problems are exposed through transparency and oversight can take advantage of the incremental approach to stop a failing project.

This way of thinking is a mistake. The project was started because of a mission need. Canceling the project leaves that mission need unmet. Oversight has failed in two senses: (1) it failed to make the project successful, and (2) it did not allow a mission need to be met, one that was important enough to have invested in. If, in fact, the mission need is important, then a new project will have to be started to address that same need. The new project will have the overhead of starting up a new program, thereby wasting more money. Instead of canceling the program, the oversight body should shift the course of the current program to make it more successful.

But isn’t that throwing more money into a wasteful program? No – what has been spent so far is a sunk cost, and there may be some salvageable assets. Doesn’t the program’s failure to date mean that it is poorly managed? Not necessarily, but if it is, the oversight body should simply force the program management to change, not cancel the program. In many cases the problem is not management, but circumstances outside their control. The oversight body should help the program overcome those outside forces. Terminating the program is just a way to punish the program’s management, and adds waste for the government as a whole.

Why cancel a successful program? If a program has delivered substantial value to date, then the oversight body should consider whether the remaining work of the program is necessary. If the program’s work was appropriately prioritized, then there should be diminishing returns to continuing the program. Oversight should constantly reassess the value of the remaining work, and see if the agency’s needs have changed in a way that the remaining work is no longer worth the investment. If the oversight body decides that this is the case, it should cancel the remainder of the program and rejoice – for this it can legitimately claim an oversight success!

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.

The “business value” of government

Agile delivery approaches focus on maximizing business value rather than blindly adhering to pre-determined schedule and scope milestones. On the definition of “business value” the agile literature is appropriately vague, for business value is defined differently in different types of organizations. I would even argue that it is necessarily different in every organization – each company, for example, is trying to build a unique competitive advantage, and results that contribute to that advantage can be valuable (“net” value, of course, would have to consider other factors as well). A publicly held company needs to maximize shareholder value; a closely-held private company values … well, whatever the owners value. A nonprofit values mission accomplishment. What does the government value and how does it measure value?

The answer is not obvious. Mission accomplishment is certainly valued. But different agencies have different missions and for some agencies measuring mission accomplishment is difficult (James Q. Wilson’s book Bureaucracy is great reading on the topic of agency missions). If the Department of Homeland Security values keeping Americans safe, how can it measure how many Americans were not killed because of its actions? In an agile software development project, how can we weigh cost against that sort of negative value to determine which features are important to build?

To make matters more complicated, the government values many things besides mission accomplishment. Controlling costs, obviously. Transparency to the public and to oversight bodies. Implementation of social or economic goals (small business preferences, veterans preferences, etc.). Auditability – evidence that projects are following policies. Fairness to any business that wants to bid on a project. Security, which in the government IT context can extend to keeping the entire country safe. And through appointed political agency leadership, political goals can also be a source of value. Each of these values may add cost and effort to a project.

To maximize business value, we must consider all of these sources of value. If we limit ourselves to the value of particular features of our software, we are missing the point. Rather, as IT organizations in the government, we need to self-organize to deliver the most value possible, given all of these sources of value. The government context determines what is valuable. What we must do is find the leanest, most effective way to deliver this value. This is no different from the commercial sector – only the values are different.