Lessons Observed: Going Too Digital in the DoD — Silicon Mountain
I desperately want to say “lessons learned” instead of “observed.” My doubts overwhelm me, though. In order to protect the innocent and even the guilty, I am changing the name of the most interesting offending tool I have personally seen in action. To learn from this lesson, we would need vulnerability, and acceptance perhaps of money poorly spent.
There are many problems faced by the bureaucratic U.S. Department of Defense. Often, this behemoth is operating an organization by the sheer power of will, maintaining the status quo, or sometimes even shaking things up and trying something innovative (not to be confused with inventive). There are many common problems, some of which we try to solve government-wide even, which is ambitious with personalities and capabilities that vary wildly within agencies, departments, branches, offices, etc. The common problems are the juiciest. Think of the career advancement for solving a DoD-wide or government-wide problem! Sure, it’s risky, but if you’re savvy enough you can even make a bad idea “successful” before your next PCS arrives.
Digital Solution Overload- Voldemort
The system that shall not be named, shall be named Voldemort. There are hundreds, maybe thousands of systems that rely on Excel, Access, Word, PowerPoint, or PDF files within the government. Some are approved as such in format, some are manual steps that inadvertently went live in an operational environment on a tool not designed for scalability or integration. Some require portability and deliverability via electronic mail because of a legacy approach that is, at this point, time-tested within the ranks and services.
Voldemort was one of these. The legacy solution was heavily dependent on email and Word documents. Many of the business activities performed happen in large systems that solve a fraction of a business function. In a recent ad hoc interview (we were learning about data sets available in Envision, an USAF Palantir installation of the Foundry product), I learned that there are more than a dozen applications required to get a 360-degree perspective on personnel alone.
Through our normal process of talking to end users of systems and those impacted by the data, we learn a lot about a variety of problems, within the business and within the mission activities at several layers of the operational hierarchy. We learned a lot about the problem Voldemort planned to solve and many similar problems that are government-wide. Voldemort’s processes are subject to scrutiny, are often late, and are often wrong and require multiple revisions and multiple approvers and stakeholders to contribute. The current solution did.
Going Too Digital in the DoD — What Went Wrong?
I assume that everyone’s intentions were solid. Taking big swings at large changes usually is… admirable. Revamping an age-old, relatively low-fidelity system that touches everyone is challenging. Converting of the capabilities into a constrained mold is a lot all at once, and doing so with a top-down directive and insufficient testing is likely a great opportunity for a lesson for all involved and all observing. Political will, frustration with the status quo, and sunk cost biases may prove an assumption wrong, but the whole project would likely benefit from a brief strangulation followed by a solemn prayer or two before being laid to rest.
The problems are almost endless and mostly user-driven. There are likely a series of very important people that needed to approve the project, and there is a certain culture of ‘value by contribution’ that happens in this industry and healthcare and several other high-value verticals. If you do not contribute your mark, or speak up, you must not be engaged. So, as an unintended consequence, you added in the most restrictive requirement. Whether it be character limits or some obscure line length that accounts for character widths in certain fonts — the system is now too constraining to meet the needs of a broad audience. It is a cardinal sin to create too many business rules on any text field, but I promise you it happened.
Now, on release, you start to hear feedback. No one expects a perfect release, well not anymore. Certainly not Microsoft — ever. Just watch the update screen happen on the Netflix Space Force show. It’s funny, but a little close to the mark. It also elicits a certain cringe response. Okay, good tangent, back to the feedback: it’s snowballing. It’s not just a typical, “We recognize a few bugs in the system, we will resolve them over the next month or quarter.” Instead, the feedback is about the core design of the system that cannot easily be resolved, and the top-down mandate at release has created a grinding halt to all progress in the solution space. You HAVE to use Voldemort, even if it won’t let you, won’t work, breaks, doesn’t allow you to make edits, showstoppers, and now you have to backpedal on the directive.
Going Too Digital in the DoD — What Can We Do Better?
A couple of things. One, the culture around software needs to change. Why would we not be building around design sprints and user-centric (not user-driven) design? Let the experts in their field do what they do best. Yes, this is foreign in a military that drills in hierarchy, initiative, and participation in the activity. After all, how will you get recognized for being the one in the room agreeing that we have a sufficient set of user inputs to generate a meaningful solution, and trust a professional design and development firm? (Trust but verify, it’s built into Agile.)
It’s not a simple thing to take on the big capabilities or big swing changes. Being cognizant of the change management factors involved in a change at the scale of DoD will be challenging. So why the big splash? Why not build, release, and use more of a continuous delivery methodology to slowly replace the current solution. It might cost more than the big splash, you might need to duplicate or make redundant processes along the way to create less of an impact than the top-down directive. However, you might actually get the feedback you need in relevant development stages rather than at the release point of a major product step. You might have engaged end-users instead of revolting masses. Big and scaled projects are hard, design is important. But if you built a submarine and needed a horse, you might find yourself in a pile of…
For now, Voldemort must die. There are simpler ways to improve the experience Voldemort targeted without excessively constraining the masses.
Author’s note: It’s been a while since I last wrote. I plan to get back to a rhythm of about monthly. I blame my one year-old twins.
Originally published at https://siliconmtn.com on April 5, 2023.
