8 ms·

This is an example of administrative burden. In this case, it's due to bureaucratic incompetence, but it is often an intentional policy lever to limit access to

by js2 7y ago

This is an example of administrative burden. In this case, it's due to bureaucratic incompetence, but it is often an intentional policy lever to limit access to benefits: https://www.nytimes.com/interactive/2020/01/28/upshot/administrative-burden-quiz.html https://www.nytimes.com/interactive/2020/01/28/upshot/admini... https://www.nytimes.com/2018/01/18/upshot/medicaid-enrollment-obstacles-kentucky-work-requirement.html https://www.nytimes.com/2018/01/18/upshot/medicaid-enrollmen...

kurthr 7y ago
Exactly, and it’s not just in one state. Florida’s website was apparently designed to keep the reported unemployment rate low, by making it difficult or impossible to file. https://www.huffpost.com/entry/florida-unemployment-website_n_5e87b67ec5b6e7d76c63bcf7 https://www.huffpost.com/entry/florida-unemployment-website_...
wpietri 7y ago
And just as often, I'd add that it's more about systemic factors. Let me quickly tell the story of GetCalFresh: https://www.getcalfresh.org/ https://www.getcalfresh.org/ This was built by some friends of mine, my former colleagues at Code for America. Their basic notion was that applying for CalFresh (our version of food stamps) was too hard. So they applied classic Lean Startup techniques to solve the problem. They ran Google ads and directed assistance seekers to a simple Typeform that had barely enough information for the best case, and figured out how to get people benefits Then they iterated rapidly. You can read more of their story in this two-part article: https://leanstartup.co/part-1-from-root-hypothesis-to-functional-software-with-code-for-america/ https://leanstartup.co/part-1-from-root-hypothesis-to-functi... https://leanstartup.co/part-2-from-prototype-to-real-transactions-testing-with-code-for-america/ https://leanstartup.co/part-2-from-prototype-to-real-transac... From the stories I've heard from them over the years, the real problem was neither incompetence nor malice. It's that doing anything involving a lot of different people is really hard. The counties actually had online application for years. But those systems were built by large government contractors, and they focused on satisfying the law and the rules. They focused on completeness, on perfection, on conformance to spec. Like so much enterprise software, user experience just ended up being a low priority. There are lots of causes for that, but it's not like any single person is to blame. Everybody's just responding to their local incentives, trying to get by. Happily, a lot of the people in government I've met truly believe in public service. For me the moral of GetCalFresh is that almost everybody involved wanted things to be better. The trick is showing them how to make that happen in the context of the system they're in.
- mgkimsal 7y ago
  > But those systems were built by large government contractors, and they focused on satisfying the law and the rules. They focused on completeness, on perfection, on conformance to spec. Gets me to thinking about 'large enterprise' stuff in general. In the situations I've been on large enterprise projects, most of them were just modifying existing processes ('streamlining', etc), but there was no huge payoff at the end. In most cases, whether the end users could use the system at all, or 10% faster, or 50% faster, no one's job was going to be significantly changed. The 'enterprise' as a whole wouldn't change all that much. I worked on a different system - years ago - creating a web-based ordering system. Previously, the company had orders faxed or mailed in, then keyed in to a system. This process took 2-3 weeks per month to get all the orders 'in'. We put up a web system, and they had all their orders in, in electronic format, in 18 hours, with no need to bring in temp workers to key in orders. That was transformative, but... even though the new system is vital, there's not much more that can be done with it - reducing 18 hours down to, say, 9 hours, won't have any effect on the company's operations. Going from 3 weeks to 1 day was transformative - they could make different supply chain decisions, better scheduling for materials/staff/etc. At some point, many 'enterprise' system changes may not deliver transformative benefits, just incremental, and it may be harder to get anyone to care about incremental changes.
  - wpietri 7y ago
    I get that for sure. But one of the lessons I take away from Toyota's history is that continuous improvement can make a big difference if it's tackled systemically. There's a graph in one of Mike Rother's books, probably Toyota Kata that shows per-worker productivity of major automotive manufacturers. Toyota started behind; they were catching up from Japan's decimation in WWII. the US Big 3 eventually leveled off. Toyota caught up and then just kept going, allowing them to produce much better cars for much less. At some point a US automaker in trying to understand it ordered parts from a Japanese supplier. When they received the parts, they did their standard QA checks, measuring part size and variance. Except they couldn't measure the variance, because their instruments weren't precise enough. That high precision allowed downstream improvements: higher quality, lower cost. So sure, the local optimization of order entry from 3 weeks to 1 day removed a bottleneck, improving the whole flow of the system. But it's not like the system had no bottlenecks. As always, the bottleneck just goes somewhere else. And even when a given process isn't the bottleneck, removing waste is always beneficial. The problem isn't that the change isn't worthwhile. It's that a company's threshold for "significant" is too high.
deleted 7y ago
[deleted]

by js2 7y ago

kurthr 7y ago

Exactly, and it’s not just in one state. Florida’s website was apparently designed to keep the reported unemployment rate low, by making it difficult or impossible to file. https://www.huffpost.com/entry/florida-unemployment-website_n_5e87b67ec5b6e7d76c63bcf7 https://www.huffpost.com/entry/florida-unemployment-website_...

wpietri 7y ago

And just as often, I'd add that it's more about systemic factors. Let me quickly tell the story of GetCalFresh: https://www.getcalfresh.org/ https://www.getcalfresh.org/ This was built by some friends of mine, my former colleagues at Code for America. Their basic notion was that applying for CalFresh (our version of food stamps) was too hard. So they applied classic Lean Startup techniques to solve the problem. They ran Google ads and directed assistance seekers to a simple Typeform that had barely enough information for the best case, and figured out how to get people benefits Then they iterated rapidly. You can read more of their story in this two-part article: https://leanstartup.co/part-1-from-root-hypothesis-to-functional-software-with-code-for-america/ https://leanstartup.co/part-1-from-root-hypothesis-to-functi... https://leanstartup.co/part-2-from-prototype-to-real-transactions-testing-with-code-for-america/ https://leanstartup.co/part-2-from-prototype-to-real-transac... From the stories I've heard from them over the years, the real problem was neither incompetence nor malice. It's that doing anything involving a lot of different people is really hard. The counties actually had online application for years. But those systems were built by large government contractors, and they focused on satisfying the law and the rules. They focused on completeness, on perfection, on conformance to spec. Like so much enterprise software, user experience just ended up being a low priority. There are lots of causes for that, but it's not like any single person is to blame. Everybody's just responding to their local incentives, trying to get by. Happily, a lot of the people in government I've met truly believe in public service. For me the moral of GetCalFresh is that almost everybody involved wanted things to be better. The trick is showing them how to make that happen in the context of the system they're in.

mgkimsal 7y ago
> But those systems were built by large government contractors, and they focused on satisfying the law and the rules. They focused on completeness, on perfection, on conformance to spec. Gets me to thinking about 'large enterprise' stuff in general. In the situations I've been on large enterprise projects, most of them were just modifying existing processes ('streamlining', etc), but there was no huge payoff at the end. In most cases, whether the end users could use the system at all, or 10% faster, or 50% faster, no one's job was going to be significantly changed. The 'enterprise' as a whole wouldn't change all that much. I worked on a different system - years ago - creating a web-based ordering system. Previously, the company had orders faxed or mailed in, then keyed in to a system. This process took 2-3 weeks per month to get all the orders 'in'. We put up a web system, and they had all their orders in, in electronic format, in 18 hours, with no need to bring in temp workers to key in orders. That was transformative, but... even though the new system is vital, there's not much more that can be done with it - reducing 18 hours down to, say, 9 hours, won't have any effect on the company's operations. Going from 3 weeks to 1 day was transformative - they could make different supply chain decisions, better scheduling for materials/staff/etc. At some point, many 'enterprise' system changes may not deliver transformative benefits, just incremental, and it may be harder to get anyone to care about incremental changes.
- wpietri 7y ago
  I get that for sure. But one of the lessons I take away from Toyota's history is that continuous improvement can make a big difference if it's tackled systemically. There's a graph in one of Mike Rother's books, probably Toyota Kata that shows per-worker productivity of major automotive manufacturers. Toyota started behind; they were catching up from Japan's decimation in WWII. the US Big 3 eventually leveled off. Toyota caught up and then just kept going, allowing them to produce much better cars for much less. At some point a US automaker in trying to understand it ordered parts from a Japanese supplier. When they received the parts, they did their standard QA checks, measuring part size and variance. Except they couldn't measure the variance, because their instruments weren't precise enough. That high precision allowed downstream improvements: higher quality, lower cost. So sure, the local optimization of order entry from 3 weeks to 1 day removed a bottleneck, improving the whole flow of the system. But it's not like the system had no bottlenecks. As always, the bottleneck just goes somewhere else. And even when a given process isn't the bottleneck, removing waste is always beneficial. The problem isn't that the change isn't worthwhile. It's that a company's threshold for "significant" is too high.

deleted 7y ago

[deleted]