Great story and great article touching on many of the problems affecting the healthcare.gov website. I don't disagree with any of the details, but I can't really get behind the idea that NIH plays a significant role in the failures.
You can probably dig into the project and pick out thousands or tens of thousands of objective mistakes that someone somewhere is capable of diagnosing and proposing a better solution. And on the same token you can probably do that same for good decisions which someone somewhere thinks would have thought they knew better and attempted to fix what wasn't broken.
This is just the nature of large projects, and well understood in such literature as The Mythical Man Month. And I would submit that it's not technology projects per se, but rather the unforgiving literalness of computer systems that throws the overall systemic failure into stark relief.
As the scope and required knowledge of a project increases, the communication overhead increases non-linearly. Not only must thousands of leaders at every level have access to the right information and make good decisions, they in effect act as a distributed system to specify the technical implementation. It will be extremely difficult, if not impossible for all the subordinates to filter the information correctly such that the people at the very top have exactly the right information to make the best decisions.
The reason a couple college kids end up creating something more impressive is because they have the freedom to ignore intractable problems. If you threw Larry and Sergey at this type of problem they would be nobodies today because there's nothing you can do against that wall of legislation. The legal code is like computer code that is never subject to performance benchmarks, the people who touch it (legislators, judges, lawyers) are all well paid and have exactly zero incentive to make it efficient. It's tragic because there are no doubt places where 8-figures could be shaved off the budget if the implementers had channels to the legislators to raise issues that make the system intractable, but unfortunately the legal requirements are done in a too-big-to-fail waterfall fashion where the hopes of ever simplifying the system are slim to none.
I actually think its a really good reason why it often goes wrong in the sense that most governmental agencies always think they need to somehow customize to their unique needs.
I have seen this many many times when dealing with governmental contracts.
Another issue is the way these procurement offers are made. They are basically forcing the bidders to define their way out of every issue they might encounter just to make sure they don't suddenly get caught with having to do the work after some huge issue and no budget to do it with.
So instead a lot of the proposal is about defining the scope of the projects but in such a way that most of the budget is a buffer for when the project go wrong.
In most cases these systems already exist and could be much easier build with off the shelf based software. But because government think their needs are unique they end up building themselves.
In Sweden the police were able to implement a new system without many issues exactly because they used existing system rather than trying to invent their own.
In Denmark they thought they needed their own and are paying the price with a version they had to scrape.
"I actually think its a really good reason why it often goes wrong in the sense that most governmental agencies always think they need to somehow customize to their unique needs."
yup! and it's the agency needs, not the needs of the actual user that are unique and special and require customization.
a big reason that GDS in the UK is having success is that the user need always comes first.
Hm, very interesting. I don't have any response to this, but I just wanted to let you know that I find your comment compelling and I'm rethinking my position.
You can probably dig into the project and pick out thousands or tens of thousands of objective mistakes that someone somewhere is capable of diagnosing and proposing a better solution. And on the same token you can probably do that same for good decisions which someone somewhere thinks would have thought they knew better and attempted to fix what wasn't broken.
This is just the nature of large projects, and well understood in such literature as The Mythical Man Month. And I would submit that it's not technology projects per se, but rather the unforgiving literalness of computer systems that throws the overall systemic failure into stark relief.
As the scope and required knowledge of a project increases, the communication overhead increases non-linearly. Not only must thousands of leaders at every level have access to the right information and make good decisions, they in effect act as a distributed system to specify the technical implementation. It will be extremely difficult, if not impossible for all the subordinates to filter the information correctly such that the people at the very top have exactly the right information to make the best decisions.
The reason a couple college kids end up creating something more impressive is because they have the freedom to ignore intractable problems. If you threw Larry and Sergey at this type of problem they would be nobodies today because there's nothing you can do against that wall of legislation. The legal code is like computer code that is never subject to performance benchmarks, the people who touch it (legislators, judges, lawyers) are all well paid and have exactly zero incentive to make it efficient. It's tragic because there are no doubt places where 8-figures could be shaved off the budget if the implementers had channels to the legislators to raise issues that make the system intractable, but unfortunately the legal requirements are done in a too-big-to-fail waterfall fashion where the hopes of ever simplifying the system are slim to none.