Guiding questions for collaborating with tech
Here are some questions that can serve as a tool kit for government officials to keep themselves on track during the drafting, planning, requesting, and implementation process. These are far form all-inclusive and are based on my own experiences from the tech side of things.
Legislation drafting and rule making
What perspectives are represented in our baseline assumptions?
When drafting legislation that will interact with technology it’s important to start by explicitly spelling out what expertise is already at the table. Doing so will not only provide valuable context but will also highlight absent perspectives. For example, a technologist may have pushed against the hard deadlines for the implementation of healthcare.gov and could have asked for a framework that allowed for beta testing.
How is the balance between flexibility vs. specificity doing?
Agile companies and government agencies must recognize the drastically different perspectives and pressures they bring to the creation of requirements. In Agile, the fear is that requirements will be too specific and hamstring effective iteration. For the government, a lack of specificity invites misinterpretation and miscommunication. Consequently, both parties must continuously ask and answer this question for themselves and for each other to ensure a healthy working relationship.
Is Agile the best project management methodology for your project?
Hard deadlines and limited budgets (subject to political whims) are major obstacles to Agile’s success. Furthermore, requirements can be strict and esoteric due to backroom political bargains. For example, the ACA and AHCA both contain sections specifically dedicated to the taxation of tanning salons, likely a minor concession to secure a vote. Finally, prioritization — the lifeblood of Agile — is anathema to politicians. No politician wants to see their pet issue at a lower rank. Even without these obstacles and with champions on both sides, the RFP must be carefully designed to support Agile and allow for more flexibility and less specificity. Alternatively, RFPs could be written for every major sprint or milestone though this may have substantial overhead. With all of these obstacles, the choice between Agile and Waterfall may not be as clearcut as expected.
Are we asking for the right things in the right way?
Syntax doesn’t only convey the immediate meaning but can also carry significantly different implications. The drafters of the ACA felt that the unique identifier system could easily be added or changed at at any point in development while any data architect would pale at the idea. Likewise, technologists are less likely to understand the history and legislation that precludes the use of SSNs as unique identifiers.
What is the pool of potential partners like?
After years of Waterfall RFPs, the pool of vendors is dominated by large companies specialized in government work. Moving toward Agile requires technology partners willing and able to navigate the RFP process. Unfortunately the drawn out process and degree of required expertise often serve as a high barrier to entry for small but innovative firms. Regardless of the choice between Waterfall and Agile, it is important to consider which vendors are likely to respond to a RFP and how subtle changes in language can lead to major changes in the candidate pool.
Implementation and accountability
What important “blue rules” and “red rules” need to be considered?
During implementation, knowledge of what policies and processes are de facto (blue) and which are de jure (red) will make it easier to find solutions to unexpected obstacles. With approaching deadlines and political ramifications on the line, the difference between “we can’t do it” and “we’ve never done it that way” can make a pivotal difference.
Are the decision makers appropriately invested and empowered?
Correct distribution of decision making can make a huge difference in the success of a project. Creating new leadership structures within government agencies to handle the new challenge of working with technology is critical to facilitating swift response to questions and feedback. The development of healthcare.gov obviously failed in this regard as issues such as the name of the site propagated up to President Obama himself. Similarly in Oregon’s state exchange, the lack of an independent systems integrator allowed Oracle to run rampant with little feedback from the state.
What is the culture around failure? Can the junior engineer report issues and expect leadership to take them seriously?
As discussed by Bryan Sivak and many other sources, one of the fundamental issues with the development of healthcare.gov was a complete lack of willingness to point out significant issues — rather than confess their struggles to leadership, engineers printed slides to demo the site. In turn, leadership demanded that panicking engineers only think “happy thoughts.” As a result of the refusal to acknowledge, process, and adapt to these failures, the President of the United States promised healthcare.gov was operational and made a fool of himself. Success demands internal accountability both up and down the ladder.