In this post, I’m going to restate some ideas from my first post as a federal CIO. I’m going to suggest why California needs to get started now.
In Figure 1, above, the horizontal axis is time, and the vertical axis represents the advance of technology. The green curve is meant to represent the rate at which a Fortune 500 company adopts new technology. The blue curve represents the rate at which a government IT organization adopts technology. I expect there is little controversy about suggesting that these two curves are not overlapping. The whole push for government IT modernization is based on moving these lines closer together.
The red line shows the rate of adoption required to move the blue government curve to the green curve incrementally. Let’s be real. This incremental rate of change is not possible. The gold curve represents the rate of change of technology. The red curve requires a rate of change greater than the rate at which technology changes. It is just not possible. What is more, in the time required to work the red curve, the gold curve moves further away. This trend is what haunts the CIOs in the Fortune 500. Even for them, technology is moving faster than they are.
The best companies, lumped into the Silicon Valley label, do not try to move from their old systems to modern systems incrementally. They jump straight onto the gold curve and abandon their legacy software. In my opinion, this jump is the only path available to government IT at this point. What is more, the gap is only growing larger. The time to move is now.
Here is the reality in the state: If a team formed to start the Project Approval Lifecycle on March 1, it would take eight months to get approval to start development. However, since there is no budget, the first phases would be designed to acquire funding for the fiscal year that starts in July 2020. July 2020 would be the quickest possible start. In reality, a team starting on March 1 might get through the first three stages of the PAL process for an extensive program by January 2020. They would then start a lengthy procurement process, likely taking a year, and award in January 2021.
Taken together, this represents a very optimistic scenario. If the project were to adopt agile methods, there could be a Minimum Viable Product (MVP) in January 2022 at the earliest. It would be more likely to see an MVP in January 2023. Note that this one-year difference depends on how “minimum” the MVP is. If the state were to take a waterfall approach, it would take a year to detail requirements and specifications, and development would not start until January 2022 with delivery some number of years after that. (MVP is not a waterfall concept, but there is no reason it could not be adapted to that approach.)
The point here is that under the current constraints, it will be a stretch to deliver a big win for the DMV or Medi-Cal in Gov. Gavin Newsom's first term.
Here is a better approach: Allocate funding for 15 DMV subject matter experts, product owners, and a couple of vendor coaches to build a set of user stories for one aspect of the DMV, maybe vehicle registration, quickly. User stories are lightweight and require far less detail than requirements. Allocate funding for a 30-person digital services team consisting of both state and contractor development resources. Make it a 50-50 (back to my first post: It is time to invest in state IT resources). As soon as the gist of the user stories is complete — this might take two to four months — build a product plan for a first iteration and start development. If the product owners started on May 1, then the developers would have three months to get ready, and coding could begin by October 2019.
Since the code would be designed to change, per my previous posts, and since agile methods have a natural change-management capability built in, the methodology would allow the team to catch holes in the stories and adjust as they go. Our experience with large-scale agile at the Social Security Administration leads me to believe that an MVP that is substantially better than the current legacy, but minimum, not complete, could be released into production in 18 months, plus or minus six months.
This just-get-started-and-evolve approach works. What is more, the software can evolve as technology evolves. You do not end up at the end of the project building to specifications that are three to four years old.
I know that the state has tried large-scale agile with limited or no success. In my next post, I’ll talk about common mistakes in applying agile, how we managed around them at the SSA, and how they can be fixed in the state.
