“Yesterday’s adaptations are today’s routines”–Ronald A. Heifetz, The Practice of Adaptive Leadership
I opened an earlier article[1] published in this forum some time ago by setting up the following scenario, which concludes with a simple question:
Imagine yourself as the owner of a business domain within a government agency. Let’s say you’re the Deputy Administrator of entitlement programs in an organization that processes claims for benefits. No matter the type of benefit(s) or entitlement(s) your agency administers, whether loan guarantees, educational benefits, [or] disaster-recovery relief . . ., your business model – at some level of abstraction – is as simple as receiving applications (or claims) for benefits, qualifying them, and dispensing an appropriate response to each . . . of your applicants (or claimants).
Many a government entity, whether at the federal, state, or local level . . . does little more, or less, than that.
Yet, despite the similar nature of the government services they provide, many of those agencies – perhaps even yours – would not score very well on a customer satisfaction survey. Some are plagued by a huge backlog of unprocessed claim applications. Others take an inordinate amount of time to make eligibility determinations . . . Some agencies experience extended delays at virtually every step in the claims-processing chain of business activities, which can add up to agonizing months, sometimes even years, of frustration for their neediest customers.
When confronted with such challenges at your agency, you may have had more than one opportunity to ask yourself . . ., “Why is the processing of claims for government benefits so hard?”
There are, of course, a number of answers to this question. Many have to do with the fact that a lot of Government agencies have been automating their claims adjudication processes for the past ten years or more. While doing so, some have fallen into the proverbial trap of “paving over cow paths.”
Every time I tell this story, by the way, I’m reminded of the occasional trips I would take with my grandfather as a child, from his farm (in Kentucky) to the county seat some fifteen miles away. While I rode shotgun in his two tone ‘56 Ford – a snazzy car for a man of his age –, he would alwaysturn to me and say, while braking hard to safely round the sharpest of several hairpin curves: “they were really nice when they built this road.” To which I would respond, “Why do you say that?” He would then invariably drawl, “Well, they made sure to go past everybody’s house.” It must have taken three or more of those trips before it dawned on me that he’d been “pulling my leg” with that well-practiced routine.
Once I’d gotten it, however, I found myself drawing him into a discussion of why the state didn’t try to straighten out some of those dangerous curves when they improved roads through a region that still had lots of gravel roads back then. He allowed as how, “They just paved over the old cow paths, or horse-and-buggy trails, without thinking any more about it.”
Though I didn’t know it then, I’ve since learned many times over that people (and organizations) all around the world seem to have an innate predisposition to pave over their old cow paths, whenever the need for change compels them to do something different. Instead of realizing that change offers a perfect opportunity to rethink a whole new way of conveying people and goods from one place to another, or through a given area,much more efficiently and effectively – as was done with the launch of the Interstate Highway System in the 1950’s –, people tend to start hauling-off the surface dust and dirt, before topping-off their old, well-trodden pathways and byways with new concrete, tar, or asphalt.
Agencies need to Be More Innovative about Transforming Business Processes
In Government agencies, business automation initiatives almost always require new and different business processes, many of which would have been hardly conceivable prior to the automation effort (e.g., work flow automation, workload balancing, digital image processing – and more executable business rules)– enabled by more shared and reusable highways, if you will, of technology and other services. This is especially true when an Agency attempts to automate business processes that were entirely paper-based, and manually executed in the legacy environment.
Agencies do need to be more innovative about transforming their business operations. This is not always easy and, in many cases, a different approach is what’s really needed to stimulate innovation. With this in mind, apparently, many Agencies have started to use Agile-approaches, which can provide substantially more business value over more traditional methods. However, it’s not enough to simply decide that Agile-development and -implementation methods are the way to proceed. As has often been the case with traditional methods, many Agile-driven initiatives have not delivered as well as expected, perhaps because the use of any new approach does not lead to immediate success, due in part to a lack of institutional maturity at applying the innovative method.
Agile Methods Too, Can Lead to Paved Over Cow Paths
While the Agile precept of deliveringworking software to end-users sooner rather than later has led to huge benefits for many organizations, expert proponents of Agile methods have an expectation that a great deal of groundwork must be done in advance of launching Agile development projects. At a minimum, developers should have already completed a thorough analysis of the target-state business processes to achieve a holistic view of the emergent business model. Developers should also review the validated target-state processes, with a critical eye, to ensure that they have been adequately streamlined to better assure that that the automation of them is likely to result in a more efficient and effective operational environment. Upon such a well-grounded foundation, an Agile-development project can be safely launched.
The most critical aspect of those foundational activities, however, is the intensive focus on the “target state” – and not the “current state” – business processes.
If a team of Agile-developers launch a project by building requirements against legacy business processes – which happens more often than not in some Government agencies –, beginning at the micro level with individual stories, features, backlog items, or use cases – i.e., at an iteration and feature level –, it may be assuming that the project’s sponsor has the big picture. Since many Agile methods are very developer-user oriented; they can lead developers into the trap of overlooking the prerequisite, business process reengineering activities. If developers with no understanding of the target state business processes interact with users who only understand legacy business processes, and the “methodology” for requirements development doesn’t consider business context, business process flow, and business information needs within a wider framework, the project is doomed to fail from the outset.
A solution designed to satisfy requirements derived from current-state business processes is exactly what results in a paved-over cow path – and it is an outcome that may be easier to reach with Agile-development methods, than with more traditional ones, because of (what I have often called) “a natural human tendency to get to an answer before the ‘problem’ can be fully comprehended.”
In fact, reliance on well-developed target-state business processes is essential to the success of any attempt to develop IT-solutions (or, IT-services), regardless of the development methodology used. And I, for one, advise most of my Government customers to avoid the costs of developing current-state business processes altogether, if only to avoid the risk of a solution development contractor coming in afterwards, . . . to pave over the old cow paths.
To those who respond by suggesting that, “you can’t understand how to design the new processes without having first mapped out the old ones, I reply, “Do you think that America’s Interstate Highway system could only be designed following an exhaustive study of all the state and county roads in every locale?[2]
[1]“Without Metrics, Process Improvement Can Be Hazardous to Your Business Health,” Ken Mullins, Government Bulletin(2010)
[2]The Interstate Highway System gained a champion in President Dwight D. Eisenhower, who was influenced by his experiences as a young Army officer crossing the country in the 1919 Army Convoy on the Lincoln Highway, the first road across America. Eisenhower gained an appreciation of the Reich autobahn system, the first “national” implementation of modern Germany’s Autobahn network as a necessary component of a national defense system while he was serving as Supreme Commander of the Allied forces in Europe during World War II. He recognized that the proposed system would also provide key ground transport routes for military supplies and troop deployments in case of an emergency or foreign invasion.
