Vivek Kundra On US Government Inefficiency
parkland writes "Federal CIO Vivek Kundra described some dismaying government inefficiencies in a speech on Thursday at the University of Washington's Evans School of Public Affairs in Seattle. It takes 160 days to process benefits for veterans, he said, 'because the Veteran's Administration is processing paperwork by passing manila folders from one desk to another.' Another example bound to make you grind your teeth is why it takes the Patent and Trademark Office 3 years to process a patent. 'One reason,' says Kundra, 'is because the USPTO receives these applications online, prints them out, and then someone manually rekeys the information into an antiquated system.'"
Is because there's no consequence for them doing a bad job, so they can take their own sweet time. You have to screw up pretty badly to get fired by the Federal government.
Taking guns away from the 99% gives the 1% 100% of the power.
I work in academia, which is in many ways culturally similar to working in government. I wonder how many of these inefficiencies persist in order to placate an aged workforce that refuses to embrace technology and learn to do anything in a new way.
I see a lot of people around here just sort of "running out the clock" - I can't imagine we're unique.
--saint
I'd rather the patent office simply put the applications in the trash and never approve of anything.
For every problem, there is at least one solution that is simple, neat, and wrong.
We're all thinking it, so I'll say it: "Hey, let's let our government handle healthcare to increase effeciency"
I bet the problem is budget.
"Well, we'd like to stop doing these stupid things, but we don't have money to deploy a new system."
And no one is willing to pony up the investment in modernization to save money in the long run. There are stupidities like this in every organization!
It is all about the local minimum energy state.
--PM
I see a lot of people around here just sort of "running out the clock" - I can't imagine we're unique.
Pfft. That's everywhere -- government, academia, and the private sector. The bit about not updating your technology to placate a stagnant workforce is more prominent in the former two than the latter where people are replaceable commodities (aka "human resources"), but running out the clock happens anywhere that people don't take a lot of pride in their work and just want to collect a paycheck and go home.
But even the private sector has legacy hardware to placate rather than update and replace. Why do you think COBOL and PL/I programmers did so well in the late 90s? Sometimes the pain of updating a process just can't be justified in the short term, and the private sector is even more focused on the quarterly/yearly budget than government & academia.
I'll bet the USPTO has been wanting to replace that process for years if not decades. It's not like OCR and mapping translation software hasn't been around for forever. It's probably some combination of "costs to much," "too afraid to let things get backlogged in the transition," and "if it isn't broke (enough), don't fix it."
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Government jobs, Federal, State and Local are almost treated like a jobs program. Everyone has heard the noise when tax receipts (I refuse to call it revenue) fall short and people have to be let go. The stimulus plan was the Federal government borrowing money to save the jobs of State and Local employees. In my town alone Police, Fire, Teachers and Construction have been hired with two years of stimulus funds. When the money runs out in a year, do we get a new Federal stimulus? The Feds don't have to be efficient, because they have no competition, and if you put 25% of government workers out, unemployment goes up another 5%. There is no reason to do things better if it reduces the number of workers.
This is exactly right. Each department would most certainly like to improve efficiencies by streamlining the workflow with IT. The problem is that implementing that IT costs money above and beyond what they've got right now. How to pay for it?
Incidentally, this would have been a great place for stimulus money. Inject money into the system right now (stimulus) in a way that lowers long term costs. Then, once it gets up and running (after months to years of defining, planning, implementing, and testing), you trim down those departments either through reassigning or through attrition.
Yeah yeah, I know around here the perception is that civil servants exist in this parallel twilight zone where they lean on shovels all day at best or interfere with individuals at worst, but that perception simply isn't reality. Some departments are better than others, often because of leadership and resource availability, just like in the private sector and the non-profit sector. Hopefully the CIO can identify opportunities and find the funding to implement savings.
On a side note, this does suggest a way to find those savings: check printing budgets over time. It seems that printing and then re-entering information may be common, and printing budgets may be helpful in identifying where these processes exist.
Support a few technologists in Washington.
There are all kinds of ideological explanations for why this *must* be so, but I don't think they hold water.
My first management job was at a largish non-profit where I inherited a three year IT request backlog. So I analyzed the backlog and discovered that most of it consisted of requests for software to speed moving decisions from what amounted to the user's in tray to the out tray, and pretty soon I realized all those in-out transformations formed a network. I charted out the network, and it was *obvious* that certain key information latencies could be reduced from 35 days to about half a day by rerouting the information through this network. In fact, most of the work in the network could be eliminated entirely, while providing better, But rather than spring this on people, I just laid out the charts and they figured everything out for themselves. That way I didn't have to persuade anyone.
Now the interesting question was how this kind of situation could happen. It's not because the people were stupid. They weren't. It wasn't because they were lazy or not dedicated. Quite the contrary. Lack of profit motive certainly played a part in the evolution of the problem, but it did not create the least barrier to addressing the problem.
What we had was two levels of people in the organization. People down in the ranks who cared about the mission of the organization and understood their local piece of the process. And people at the top who sometimes cared about the mission of the organization, but were mainly focused on shmoozing. But nobody had any idea what the *whole* process looked like. So the people in the ranks were largely left to guide themselves in solving problems. They were self-starters, they had initiative, what they lacked was a global understanding of how everything fit together. So they talked to their neighbors in the existing process about where they were under pressure, then they demanded the higher ups provide them with tools to reduce the pressure at individual points. The higher ups had no idea how to fix these things, so they just stuck the requests onto the back of a three year queue, and when things began to catch fire they'd demand the queue get resorted.
But the queue shouldn't have existed at all. When folks were done applying common sense to the big picture I provided, most of the dreaded request queue evaporated. My backlog went forty months down to under thirty days, and I didn't have a lick of code written.
What was missing was *leadership*. In my book leadership equals caring about the results plus understanding how the process works.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The Patent Office does not do that and hasn't for years, except of course for papers that are mailed or faxed in. The Patent Office's Electronic Filing System is an end-to-end electronic system for the most part.
Now, the EFS system does convert searchable PDFs to bitmap PDFs, which causes them to lose their searchability and greatly increases the file size, which is still incredibly backwards, but not quite as bad as printing things out and scanning them back in.
The government never makes money
Yes, they do. Fees? Penalties? Taxes? It's time for the "Government is the root of all inefficiency" to die.
My power company is owned by the city government, and it turns a profit. It also has the lowest rates in the state, and the most dependable electricity. Its customer service is stellar. If the customer service or dependability drops, or if rates rise too much, it's guaranteed to cost the Mayor the next election.
It doesn't hurt that Mr. Burns runs CWLP.
Free Martian Whores!
Yes, they do. Fees? Penalties? Taxes? It's time for the "Government is the root of all inefficiency" to die.
There's a difference between making money and taking money.
You could not be more wrong. In most large companies, what passes for efficiency is neither faster nor cheaper. Success is based mostly on being the loudest with the deepest pockets.
What passes for efficiency hardly matters. If a company wastes less money, it will have more money. It's logically impossible for it to be otherwise. And don't start on crap like "But some companies waste money and then their income goes up", if a company spending money causes its income to increase, it obviously wasn't a waste.
One source of the problem is that it takes time to do a replacement. And during that replacement either you run a doubled system for awhile, or you put up with LOTS of interruptions of service that last for unpredictable amounts of time.
Yes, when you're through with the process, your system is a lot better and less expensive. But the intermediate stage is more expensive, and can last for an unpredictable amount of time. (Yeah, predictions are always insisted upon. But that's a CYA move. Everyone either knows, or should know, that they are basically unpredictable.)
The obvious best answer is to run a doubled system while the new one is being put into place. Now justify this to the budget committee.
P.S.: The essential unpredictableness of the time to fix a system being developed is one reason most software projects fail. The normal answer is you take your best guess as to how long a part of the project will take, and double it. This often isn't enough, and doubling everywhere will make the project too expensive to do, so...
I think we've pushed this "anyone can grow up to be president" thing too far.