This guy managed to achieve his mandate AND managed to entice groups to investigate updating their workflows after the fact. I agree it's not the way things SHOULD work, but he managed to find a way to make the most amount of progress and along the way some kingdoms were enticed to cycle back around and improve their workflows too.
IMO, the optimal strategy in such an environment is to get at least one powerful champion on your side who can give you political cover, and then to quietly construct a MVP while soliciting feedback from high performing rank and file in the departments of interest who you know (ie no other power brokers besides your champion(s)). If you can deploy a value adding MVP it becomes difficult for antagonists to intervene and kill the project without appearing petty, and then you can really get to work building the product you want.
What you are proposing most of the time will not because it would require an immense, truly Herculean, amount of political will and backing.
Redesigning processes clashes with the #1 rule of big systems: processes are ruled by people whose jobs depend on them. And they WILL fight tooth and nail to keep those jobs. The bigger the change, the more threatened they will feel, the more they will sabotage you.
And you know what the #2 rule of big systems is: no matter what "the boss" may say, if the officials are not on board it's just not going to happen.
If you have not, I suggest watching "Yes minister" :).
Years ago, I was at a very small company that used Exchange. We had some outages and it was just a lot of administrative overhead in a world in which Gmail was by then an option.
But one person in particular fought the change strongly because they were used to a business/sales process that used hierarchical folders to keep documents organized and Gmail, at the time, only had single level labels. The CEO mandated the change anyway but the other person never accepted that Gmail was suitable for our needs.
The author later brings up the questions you mentioned - what is a form, should these forms exist, etc, but instead of spending a long time trying to design an entire new system _when that wasn't even asked of them_ they decided to deliver results. Once they gained trust and got buy-in by the city, they could think bigger.
Sounds great. If you can do this in less than a week for each form (the author managed 100 forms in 2 years) then you're perfecting processes _and_ moving them online faster than the author.
But just in case you missed it, let me quote a couple of bits of the article:
"Getting city workers to accept online submissions rather than traditional paper ones is the bulk of this work. On average, it took me about 30 minutes to make a digital form and five weeks to meet with, earn the trust of, and get buy-in from the employees who would use it. Even if they were excited, the nitty gritty details took a lot of back and forth."
"Some departments had sort-of insane business processes for submissions. If I tried to change those, I would spend a whole year on a single department. By focusing on the priority, moving forms online and making it easier for the customer, I could make consistent progress rather than be consistently blocked."
My guess is that you're going to spend decades perfecting processes, only to find the world has changed (or the politicians in control of the City of Boston have changed the law that governs the processes!) by the time you're ready to begin digitize forms. You're letting perfect be the enemy of good.
> You should never just move things online. The web is different, and enables different business processes. Change the process first. Forms come later.
Sometimes "just moving things online" is a big improvement over the status quo. But the author agrees with you in at least one case. See the paragraph about what they are doing about death certificate requests.
In my field there's a very well-known example of a MRI manufacturer who has made very "smart" systems that end-users simply refuse to use. Technologists know how to operate a scanner, when a machine starts trying to help them it's very difficult for them to (1) understand what the machine is doing and how to work with it and (2) trust the machine, primarily because physicians yell at people, not machines. There are maybe 10-20% of the technologists that "get it" and want to tinker and learn how to use the new features. The rest still miss the way scanners worked 20 years ago--because they understood and trust them.
That's the thing with paper forms--people can understand what's happening, discover the process and figure out how to succeed and not to be yelled at. When it disappears into a machine it might as well be a blind and deaf new hire who keeps messing with your desk. It's a major issue of trust.
So the parent's "no it needs to be this giant reinvention when strangers who don't do the work come in and tell you that you need to do everything differently" attitude maybe works with management.
I honestly think the big problem here is that we don't seem to have systems that people can play with to build their own ideas anymore. Maybe sharepoint but my god I can't even figure out how to do anything on that. It really boggles my mind that we have things like iPads and iPhones but nothing like Hypercard.
Change is hard. Radical change, all at once inside a big organization is near impossible.
In this case, it’s a great first step to get all this info out of paper and wooden inboxes and into a more accessible form.
Doing so still leaves open the potential for reinventing high-priority forms and workflows. It also makes it easier, because now the team can easily ask questions like, “how many people use this?” And “how much time do we spend on this?” Etc.
In short, while you might be right wrt. producing innovation, sometimes the first step is to just put it on the internet.
I think Gov.UK was (and is) great, but it's entirely possible that doing a lift and shift of the paper based forms might have gotten more done in a shorter time.
When your process happens on paper, there's nothing forcing you to ensure it makes logical sense. You can draw whatever you want on a piece of paper, so a lot of the paper forms that people call "permits" are just messy reflections of the thought process of the person who originally conceived the process. Naturally, products that start by directly replicating a paper form are accommodating and perpetuating the lack of planning.
We've kind of taken a backwards approach where we don't accommodate direct translation of forms and instead provide tools that encourage people to think through the steps of their permitting processes to get them to make sense on a digital platform. More often than not, they discover glaring inefficiencies in the process which when fixed make everything work more smoothly even independent of the move to a digital platform.
Shameless plug: https://citygro.ws
Instead, we got endless bikeshedding about "the process" and during that, many unrealistic expectations were conjured into existence as each process was re-imagined into kind of ultimate, abstract form of near infinite configurability. Try to imagine sitting at a table as someone says, with complete seriousness, that people ought to be able to submit a multiple one terabyte (not mega or giga, tera) files with a particular webform. Not any other transfer protocol, either. And this is back around 2008 or so. It should just ... expand as necessary.
Nor was this the only time I encountered this kind of behavior. I have seen functionaries whose visions of process suddenly bloat like that "elephant's toothpaste" when presented with technological options. I would do the forms first, given the chance.
Is this picture a bad thing? https://i.redd.it/uj5ehfdxn5o31.jpg
(yes yes fun-police, it's actually a myth https://www.bostonmagazine.com/news/2018/03/06/boston-street... but the truth of it being a bunch of ad-hoc cities that coalesced into one entity isn't too far off from the truth. My favorite bit of Boston artwork is road silhouettes of all the Boston-area squares: http://andywoodruff.com/blog/boston-squared/ )
Real world space is (generally) 2 dimensional, and these cow paths are often very predictable and sensible. They're usually the result of architects thinking that sometimes people actually walk or bike, instead of always driving cars.
In the world of bureaucracy & information tech, the space can be very convoluted, and shortcuts aren't really the same kind of thing (queue XKCD comic on spacebar heating).
No use trying to optimise in a week using one brain something that found a local minima (or maxima) over years and multiple people.
Normally the change (and effort) to achieve a better minima (or maxima) has to made on a variable you just can't see or imagine.
Something on the line of Chesterton’s Fence.
Bottom up IT system reimplementations fail much more often than incremental ones.
Bottom up reimplementations of operating human systems that also involve big bang IT implementations are even worse, by comparison to incremental evolutions, mixing incremental automation with incremental process improvement.
And it usually only takes one high-profile failure of a big-bang implementation to derail a broad reimplementation process, whereas the occasional incremental setback on an incremental improvement process is rarely politically significant to the overall process.
So, no, I disagree with your recommendation that this should instead have been done with a more waterfall-style approach.
> Some departments had sort-of insane business processes for submissions. If I tried to change those, I would spend a whole year on a single department. By focusing on the priority, moving forms online and making it easier for the customer, I could make consistent progress rather than be consistently blocked.
Re: should they just be database entries? he did do this or make other changes when the department agreed.
Whereas moving existing forms online in the same structure can be done with minimal management agreement and provides a quick win.
Especially when you're talking about 344 forms. Redesigning all the back office processes for 344 forms would be a gargantuan task.
It is a technical way. "Do not mind people, just make tech to work". This way have its benefits, like it tends to make result to have better design, but what about people? They work and they think that their work is important and valued. But "hey, some engineer came and started to make it his way without any reverences to us". It is humiliating, and such engineer could face a resistance.
The author made a genius' move which I might expect from a psychologist or any other social oriented person, not from tech-savvy engineer: he started to make life of a people better. He asked their opinion on how they think it would be made better. He showed respect. He showed people that he sees them as people, not as gears in a clockwork mechanism. They reacted as people generally tend to react to this: they welcomed him. Probably it helped that it was government bureaucracy which likely treat people as gears in a clockwork, so his way of treating people contrasted nicely to the way they used to.
There are billion dollar programs that can be replaced by a Google Form. You’re always going to lose if you are too accommodating. Every one of these dopey workflows has a unit of FTEs on payroll in the backend!
Get High level sponsorship, hard deadline and most things will be doable within reasonable constraints. The stuff that isn’t doable is the hard work, which you will never discover until it’s forced.
The highlighted part about the fact that it takes 30 minutes to make a change, and FIVE WEEKS to get sign-off is spot on. I fucking hate bureaucracy. But you know what happens if you don't take the FIVE WEEKS to get sign-off? Nothing.
Yeah, nothing better then complete reorganization by someone who has no idea about the work being done, needs and pressures.
What will happen here is that they will quickly realize you dont know what you are doing but are threat, so whoever will have option will easily stall you.
In government that can easily mean the forms coming never.
Not said by any dairy farmer. If you believe this, you never shovelled cowshit. Believe me, dairy cow paths and pens are paved, for a reason.
Pave cow paths, but start at the dairy and work backwards.
There is a lot of value in the existing processes. That's what the business is built on. Proposing to drastically change how things work while promising that the result will be at least as good or better -- that's a tough sell for a lot of reasons. It also seems incredibly risky, projects like that are no easy feat.
I think a gradual, incremental approach would have a higher chance of adoption and eventual success. Small asks that produce tangible improvements, building towards a systemic changeover.
Do you have case studies for successful process reengineering efforts?
There's an old saying: don't pave cow paths. That's exactly what he was doing. He was putting a different front end on an existing process. You end up with a total nightmare.
Instead, this should be done department-by-department, app-by-app. Design the process from the bottom up. For example: a form to request some document. Start with the documents: how are they stored? Should they be stored differently? Are they in a database? Should we really even be storing documents, or should they just be database entries? For that matter, should the department that manages them even exist? (Here in Chicago, the answer was no. They merged the County Recorder of Deeds office with the County Clerk.)
You should never just move things online. The web is different, and enables different business processes. Change the process first. Forms come later.