2 weeks for the director of each agency to delegate someone to be responsible for this. 2 weeks for said responsible person to figure out what an API is. 6 weeks for them to go around to everybody in the agency asking "are you doing any APIs yet?". 3 weeks to take the feedback and turn it into a semi-coherent report.
If anything, I think 3 months is optimistic.
Remember that this has to accommodate the agency in the worst situation. The alternative would be to give separate deadlines for each agency in the memo, but that may be hard to determine from the outside (after all, "what are you going to do, how, and when?" is the first thing he's asking for) and you still have to wait for the last one to have your "Hey, everyone, there's data! Have at!" press conference.
This is basically a conversation about project scope and management. Assuming this is more complex simply because it's a government agency is flawed thinking, though. I can certainly perceive complexity due to expectations or maybe the participants themselves (I've worked with some fed agencies), but that should have zero bearing on addressing the project itself.
But in reference to some of the specifics of how this is different (sensitive data, system load, system attacks, worst-case-scenario) -- this is begging for an iterative project approach as opposed to a waterfall basis. In spite of the fact that these aren't unique issues to government agencies, the context of addressing those issues might be (I have some idea of the technical capacities of our government.) I can accept there may be a learning curve in this project, but believing this project yields unique problems that haven't been dealt with elsewhere -- respectfully, that's just wrong.
If this is all very new to these federal agencies, that simply suggests a smaller initial scope that can grow after multiple iterations. Teams can learn about requirements, refine their APIs, shore up their operation, etc. Not to over-simplify, but this is basic project management.
Again, the context of the government's perview may be different than little-startup-dot-com, but the process of getting from A to B isn't really all that different.
- hire an entire department's worth of people
The worst approach I can imagine is to start this project by hiring new, dedicated people. This project only succeeds by incorporating it into the very fabric of an agency's operation. Remember, new work must go on even after this API is in place. Hiring a dedicated group that somehow has to reverse-out everything the agency does going forward for purposes of external API access is a recipe for failure. Separate teams will already be at odds with each other; better to leverage the existing teams, as their the ones in best position to understand the context of how external access to their operations should function. - wait for them to devise an API for your agency
I'm not sure if this refers to a lack of understanding the requirements, or to a lack of competency on the part of the team itself, but the presumed outcome is late delivery. If it's complex requirements, that simply suggests a basic, iterative project where scope is managed tightly and the duration is rather short (allows the team to learn as the project moves along.) If the suggestion is competency on the part of the team, hiring/contracting a few competent individuals to align with team leaders on the project has worked well for past projects. In either case, proper management of the project approach can address issues of timeline. - code it
This goes to team capability, but also to an understanding about integration. Again, solvable problem based on the team capacity. If this suggests a unique code stack that's not already available elsewhere, I'd need to understand the justification. Project management 101. - provision server space and servers
This implies the technical operations of our agency are fully-loaded, or can't address this in a reasonable timeframe, or purchasing requires some inordinate amount of lead time, or some other unknown reason. If the suggestion is that dependencies exist that threaten the timeline, those dependencies should be mitigated. Again, project management 101. - deploy
This is a physical step of pushing bits live, so automation tends to make this a quick step. In my project, we thought about deployment actions when we determined how to devise our API. At this point, deployment is an operational aspect -- not a how-do-we-do-this function. This project doesn't proceed without understanding this step.Disclaimer: I've actually done this type of project work for significant operations of size and complexity. I've also worked with a few federal agencies, so I have some familiarity with the lay of the land.
It's really not that daunting of a project. I would respectfully suggest that you re-consider your own presumptions, as there are a lot of ways to address this type of work.
3 months to get a "machine-readable" status report on implementing an API?
Then, complete the implementation in 12 months?
If it takes 3 months for an agency to get a status report up, how long will it take them to implement said API? Government work, sheesh....