Comments added inline here. > The integrator in this case was the government (CMS is a division of HHS), there's no getting around them as a single point of fa

Comments added inline here. > The integrator in this case was the government (CMS is a division of HHS), there's no getting around them as a single point of failure. This makes it easy to identify where the roadblocks are, and to present that information to interested parties at the appropriate points in time. > 1. Having a basic idea of what the system will do is helpful, but in a system that has a lot of very specific business logic that has to be defined and HAS to be right in order to comply with the law, you're not going to get very far without good requirements. Without requirements, how would one expect very specific business logic? And what is so incredibly precise that it derails any possible planning for it? I'm not familiar with that type of problem. > 2. CGI may very well have raised multiple red flags, and CMS and HHS could have promptly ignored them. That is one of the maddening things about government IT. You can tell the decision makers that they are heading for disaster and they can simply ignore you. This is very true. Of course, with basic project management 101, these things are duly noted so that when you're hauled in front of Congress, you've documented the situation. Based on CGI's responses the other day, they surely didn't do that -- otherwise, they would have raised it. Unless government IT work of this nature is classified? > 3. Let's say you plan for every one of your dependencies to fail. What useful product could you deliver in that case? One that allows you to fix those problems independently, rather than tying the success of the entire project to the success of all integration. In a project where the requirements are constantly shifting, I'd say the "useful product" definition is dynamic and iterative. A strict all-or-nothing definition makes little sense in that environment. > 4. Again, you can elicit as hard as you want, if they don't give you the requirements because the law is still up in the air, or because the president might change his mind, or because someone wants to meet with all the stakeholders in the other agencies first, there is absolutely nothing you can do. I've been on projects where the stakeholder with the final say couldn't be bothered to give their input until the software was done. I've also been on projects where the decision maker prevented us from getting the input of the employees that would actually be using the application. Sometimes the people you're dealing with are not rational actors. I get it; I've worked with federal agencies as well. It all goes back to project management and documenting interactions. As for logistics, there is always someone else to go to when a stakeholder is a bottleneck. Here's something that I found that worked in my experience with some fed agencies: identify those who are considered a project dependency, and that project progress relies on specific people. When facts are presented simply, and project management details are documented...individuals get motivated to NOT see their name in lights. As always, your mileage may vary. > 5. Fixing the contract award process is certainly part of the solution. Normally many teams could submit a bid for the work, but due to the insane time scale it was skipped for healthcare.gov. I think having a proof of concept competition after some sort of initial proposal selection gate could be useful. It could sort of be like how the military has contractors build prototypes for weapons systems competitions. Absolutely. Basically, it's an iterative phased approach, and let multiple teams go for it.